Перед вами расшифровка 252 выпуска подкаста «Веб-стандарты», который вышел 19 октября 2020. Если вы хотите его именно послушать, то вы можете сделать это на Ютубе, Google Podcasts, Apple Podcasts, Яндекс.Музыке или на любой другой платформе, где можно слушать подкасты. Но если вам приятнее будет почитать — пожалуйста! А если вы вдруг найдёте опечатки или неточности, то да — мы будем рады пулреквесту.
ТемыСкопировать ссылку
- События
- Опрос MDN
- Открытые приоритеты Igalia
- Новинки Npm 7
- React vs WordPress
- Уже Webpack 5
- Что такое Rome
- Инструмент будущего
ИнтроСкопировать ссылку
Никита Дубко: Привет. С вами 252-й выпуск подкаста «Веб-стандарты» и его постоянные ведущие Никита Дубко из «Яндекса»…
Вадим Макеев: И Вадим Макеев из HTML Academy.
Никита Дубко: В этом подкасте мы обсуждаем главные новости фронтенда за прошедшую неделю. Читайте новости в Твиттере, во ВКонтакте, в Фейсбуке или в Телеграме. Если вам нравится, что мы делаем, поддержите нас на Patreon, все ссылки в описании. Сегодня у нас в гостях Антон Кастрицкий. Антон, привет. Расскажи немножко про себя.
Антон Кастрицкий: Всем привет. Да, меня зовут Антон, я работаю в партнерских интерфейсах Яндекс.Маркет, иногда даже выступаю с докладами, имея нездоровую любовь к инструментам разработки, бывает даже в Твиттер пишу микропакеты в npm без зависимостей, всячески топлю за веб и энтузиирую в Vim.
Вадим Макеев: На самом деле, этот выпуск родился, и Антон с нами сегодня, потому что я как-то прочитал его тредик про Rome в Твиттере, англоязычный, причем, и не так много разработчиков по-английски Твиттер ведут, можем об этом, кстати, поговорить потом, плюс еще тема свежая и интересная. Опять же, мало разработчиков интересуются вещами, которые в практике ежедневной пока еще не вошли. Может, у тебя уже во весь рост Rome используется. Тем не менее, мы сегодня поговорим про этот новый тулчейн, как они себя называют, немножко про вебпяку… Про вебпяку, господи…
Никита Дубко: Это мое любимое новое слово, спасибо, Вадим.
Антон Кастрицкий: Это очень мило.
Вадим Макеев: Немножко про Webpack, спасибо, ребят, за поддержку. Всякие новости недели и статьи. Давайте начнем с событий, как обычно.
СобытияСкопировать ссылку
Вадим Макеев: В прошлом выпуске мы коротко говорили про Next.js, мол, такая штука, все дела, и они неожиданно анонсировали конференцию, сегодня нам в календарь принесли, спасибо вам большое за это. Не думаю, что сами ребята, тем не менее. Next.js global user conference. Я подумал, что 27 октября размазано по нашей планете довольно-таки тонким слоем, потому что у кого-то еще 26-е, у кого-то уже 27-е, и он шагает по планете, и непонятно вообще, в какой момент эта конференция начнется. И планировать что-то… или просто в календарь добавить, к нам принесли в календарь, и нет города привязки конференции, и нет времени начала. Ты сидишь такой и думаешь — когда она будет? Вечером, утром, днем или круглые сутки будет идти?
Я написал об этом письмо, говорю: «Ребят, все, конечно, классно, но у вас глобальная конференция, вы не могли бы хотя бы намекнуть, когда она начинается?» Мне ответили, хохотнули, сказали: «Да, тайм-зоны, все дела». Короче, в 9 утра по PST, кажется, это Калифорния, кажется, это очень американская конференция, поэтому ожидайте, что она начнется, не знаю, вечером по российскому времени где-то.
Что еще? Ребята из Google анонсировали Chrome Dev Summit, он пройдет 9–10 декабря, и, к сожалению, к счастью, так вышло, опять же, в формате онлайн. Два дня конференция, которая посвящена исключительно тому, что делает Google Chrome, и это все около веба. Я на паре Chrome Dev Summit бывал, мероприятие крутейшее, там не только гуглеры, но еще и приглашают всяких ребят из компаний дружественных, чтобы они рассказали про собственные успехи, про собственные технологии, даже иногда про собственные браузеры. Поэтому я ожидаю там увидеть и Microsoft, может быть, даже Mozilla среди спикеров или, по крайней мере, где-нибудь рядышком.
Одна из фишек на этой конференции, что они устраивают office hours так называемые, я не знаю, есть ли по-русски адекватный перевод, офисные часы. Короче, это время, когда кто-то из команды, которая разрабатывает какие-то части Chrome, может с вами посидеть, поговорить и объяснить, что, как, ответить на ваши вопросы и все остальное.
В общем, ребята говорят, что конференции открыта для всех, она будет просто транслироваться на YouTube, но также можно спросить приглашение на то, что вы можете попасть на какие-то воркшопы, эти office hours и прочие всякие штуки дополнительные, в которых можно пообщаться с кем-то, а не просто молча посмотреть. Так что если вам интересно, если у вас какой-то минимальный уровень английского и возможность задавать вопросы, или интерес, или потребность задавать вопросы, регистрируйтесь, вот именно что регистрируйтесь, подавайте заявки, и радостно все посмотрим 9–10 декабря большую Google-конференцию.
Я не ожидаю там адских анонсов. Chrome разрабатывается сравнительно открыто, и все анонсы у них в этих шестинедельных релизах заранее известны, но какой-то набор интересных докладов и, может быть, каких-нибудь статей вокруг него обязательно будет, и мы, конечно же, будем обсуждать во время подкаста. В начале декабря, 9-10 числа.
Опрос MDNСкопировать ссылку
Вадим Макеев: К новостям. MDN DNA survey. Какие потребности у разработчиков, решила спросить Mozilla у разработчиков, и спросила. На мой взгляд, не очень удачно. Mozilla, точнее, не Mozilla, а MDN как таковой, организация, в которую входят многие участники, не только Mozilla, спросил у разработчиков уже во второй раз, как им вообще веб, что им мешает, что им помогает, что хорошего, что плохого, и куда дальше двигаться MDN как сайту с документацией и совместимости веба и браузером и около того организациям, библиотекам, фреймворкам и всему остальному.
Такая попытка сделать срез актуальный на 2020 год. Они одновременно с этим, рядышком с этим, опубликовали предыдущий репорт 2019 года, в PDF, я не видел ни одного человека, который прочитал этот PDF в живую, честно говоря. Ребят, вы прочитали PDF-репорт?
Никита Дубко: Я его открыл.
Вадим Макеев: А я его скачал, это близко к тому, чтобы его открыть, да. Он лежит у меня близко, я на него смотрю и думаю — ну, почему, почему?
В общем, там много вопросов, мне удалось чуть-чуть улучшить перевод официальный этого опросника, мне Крис Милс написал по старой памяти, он помнит, что я по-русски умею, и говорит: «Слушай, у нас выходит, два дня до выпуска, помоги». Я прочитал, у меня волосы дыбом встали, я сказал: «Крис, там все очень плохо». Он говорит: «Поздно». Я говорю: «Окей». Я поправил какие-то самые очевидные ужасные вещи, но, тем не менее, у нас в чате «Веб-стандартов», в Telegram, заходите, кстати, есть дискуссия на тему того, чего получилось, и практически все говорят: «Прошел десять шагов, прошел девять шагов, не понял этого вопроса вообще». Опрос такой, очень печальный.
Мне повезло, ребята, мне повезло, что буквально в утро, когда мы опубликовали эту новость, вечером этого же дня я поучаствовал в звонке GDE, Google Developer Experts очередном, на котором представили результаты репорта за предыдущий год и рассказали про новый репорт. Первым вопросом после этой презентации вышел я и сказал: «Ребята, почему же PDF, почему такое плохое качество перевода, почему такое плохое качество вопросов? Даже англоязычные вопросы, они очень сложные, «по шкале от 1 до 15 оцените, насколько вам нравятся свойства, не знаю, aspect ratio». У меня нет эмоций на эту тему вообще никаких. Они бы еще это, не знаю, пятна Роршаха показывали и спрашивали: «Что вы об этом думаете?» Вопросы такого типа. К сожалению, очень сложные и очень такие нерелевантные для типичного разработчика, сквозь них нужно продираться. В общем, я задал все эти неудобные вопросы, мне немножко неловко, но все-таки ответили на них. Мне кажется, я больше никогда не попаду на этот созвон, потому что я снова прихожу и критикую всех.
Тем не менее, ребята объяснили, что это все все-таки делается силами Mozilla, они нанимают какое-то агентство, которое не всегда адекватно и переводит, и результаты комбинирует потом в пэдээфник, такой типичный корпоративный вариант, который всех устроит. Блин, но мы же веб, я даже не знаю, что тут еще добавить.
Печально, что так получилось, я сказал ребятам, трижды повторил громко, чтобы все точно поняли, что «пожалуйста, в следующем году обращайтесь к сообществам, сообщества готовы участвовать, готовы помогать».
Буквально тоже на днях, скоро выходит опрос The State of CSS, меня тоже позвали повычитывать русскоязычный перевод, и там тоже есть сложности, но хотя бы чуть заранее позвали. Я предложил помощь русскоязычного сообщества для следующего года и собственную помощь для того, чтобы все это сделать, более адекватно вопросы подготовить, более адекватный перевод подготовить.
А пока, ребята, если вы реально хотите повлиять каким-то образом на то, как развивается браузер, платформа, документация MDN и всего около того, вам придется выстрадать этот опрос. Я пока его еще и сам не прошел, но я планирую, чего его и вам желаю. Какие у вас впечатления, ребята, от этого опроса, я даже не знаю, может быть, я просто пессимист?
Никита Дубко: Мне кажется, ты справедливо все, я начал его проходить и не закончил, потому что действительно продираешься сквозь некоторые вопросы, и уже такое впечатление сложилось в голове, что этот опрос составляли не технические люди по ТЗ от технических людей, оно прям чувствуется. Это, знаешь, как в книгах Лии Веру на русском, «забивка» которая padding, то есть что-то пошло не так. Так вот, тут такая же ситуация, эти вопросы, действительно, «оцените свои ощущения по непонятный шкале», это вообще из области психологии, не очень понятно, зачем. Действительно, есть тот же самый The State of CSS, этих ребяток обожаю, потому что они делают это красиво, эмоционально, «оцените с эмодзи это все», мне хочется в этом участвовать.
В общем, на самом деле, посыл хороший, что они это делают, потому что это важно, это действительно какое-то направление, когда ты не просто делаешь продукт в вакууме, и никого не спрашиваешь. Но действительно, нужно над чем-то поработать. У меня не было мотивации завершить этот опрос, там сразу пугают, что целых 25 минут это займет, и ты такой: «О, то есть мне надо где-то сейчас полчаса из жизни найти». Такие вещи уже умеют делать, посмотрите в сторону The State of JS, The State of CSS, они это делают весело, задорно опенсорсно к тому же, то есть им помогать можно это все делать хорошо. Тот же самый Web Almanac очень красиво все… У Web Almanac тоже же PDF, но у них в том числе есть и веб-версия, в которой можно удобно искать, и клевые статейки, и вообще. Моя любовь просто Web Almanac, за прошлый год это самое лучшее, по-моему, что случилось.
Но там не опросы, там про исследования.
Антон Кастрицкий: Мне очень понравилась сама идея, я даже… Раз уж мы пойдем по нарастающей, то есть Вадим еще, как я понял, не открывал, Никита попробовал, но не дошел до конца, а я все-таки закончил его вчера. Но это мне далось практически болью, потому что я это делал на телефоне.
Никита уже может догадываться, в какую сторону я клоню. У ребят есть такая очень практическая любовь к нативным селектам.
Вадим Макеев: Я видел, я видел, они не помещаются в длину.
Антон Кастрицкий: При этом каждый раз, когда ты что-то выбираешь, ты поворачиваешь этот телефон, чтобы попробовать прочитать — ну, хорошо, еще на два слова больше, я попробую догадаться, что же они хотели от меня узнать! Было сложно, честно. Там были странные вопросы, были места, где я прям задавался сам вопросами о том, что же они хотели здесь спросить, потому что это был очень креативный перевод, особенно что касалось accessibility, потому что это было очевидно не с первого раза. Но кажется, что основную идею моей боли в вебе мне довелось внести.
Вадим Макеев: В общем, главной моей проблемой с этим опросом было то, что на некоторые вопросы… Вы знаете, когда хочется отвечать на какой-то вопрос, но ты читаешь, и не понимаешь, зачем им нужен ответ, то есть ты не понимаешь, зачем они задают этот вопрос, и как им мой ответ может пригодиться. Если ты этого не понимаешь, ты не понимаешь, как на вопрос ответить, ты не понимаешь, зачем на него отвечать в принципе, и это мотивацию очень сильно понижает. Поэтому плохие формулировки, неудобный интерфейс и PDF-экспорт в итоге — это как сделать так, чтобы никто его не прошел и никто его не прочитал. В похожих выражениях я вчера ребятам все это рассказал. Я надеюсь, они сделают выводы из этого, не только исключив меня из программы GDE, но и, не знаю, пригласив в следующем году поучаствовать меня и сообщество, и кого угодно.
В общем, опрос важный, не проходите его с телефона, попробуйте пройти с десктопа, вдруг получится?
Открытые приоритеты IgaliaСкопировать ссылку
Вадим Макеев: Продолжая про сообщества. Есть такая штука, «Открытые приоритеты», Igalia запустила проект, мы уже про него говорили как-то, и есть отдельный большой выпуск подкаста The F-Word, в котором мы подробнее обсуждаем это с Брайаном Карделлом. Программа, в которой предлагает вам заплатить за то, чтобы Igalia внедрила какие-то фичи в WebKit. Я помню, как разработчики отреагировали: «Я должен платить за то, чтобы…» Нет, вы не должны платить. Если вы реально хотите, чтобы какие-то фичи появились, вы можете повлиять на это.
9 ноября, написала Igalia, проект подводит черту, и кажется, нужные деньги собирают две фичи: inert и focus-visible. Это очень круто, потому что это все про доступность, это все важно, это все появится в WebKitе благодаря усилиям Igalia. Но вы все еще можете успеть докинуть свои деньги и, что интересно, если вы докинете доллар, то придет AMP и скажет: «О, кто-то докинул доллар, мы тоже докинем доллар». Если вы покинете 10 долларов, придет AMP и скажет… Ну, в общем, вы поняли. У них есть бюджет 10 тысяч долларов, чтобы сматчить вашу попытку поддержать все это. Так что до 9 ноября у вас есть шанс вкинуть в два раза больше денег, чем вы сами готовы дать. Обязательно присоединяйтесь. У меня там по 100 баксов на каждой фиче есть. Я настолько их ценю и настолько их жду, что мне очень хочется, чтобы они стали кроссбраузерными, и поэтому вам тоже рекомендую.
Никита Дубко: У меня сразу вопрос такой меркантильный. Есть фичи, которые они соберут, судя по всему, и будут те, которые собрали, но не полностью. Куда эта денежка денется? Она же переведена уже.
Вадим Макеев: Нет, эти деньги не переведены. Написав 100 баксов, ты сказал… Я, написав 100 баксов, сказал: «Я готов заплатить». Они не заморозили деньги, они не сняли деньги, ничего, просто это было такое обещание поддержать. Еще нужно будет потом прийти и снять эти деньги. Это такая ставка, скорее, чем непосредственная оплата. Поэтому, когда какой-то проект собрал определенную ставку, их начинают снимать. Это как…
Антон Кастрицкий: Kickstarter.
Вадим Макеев: Да, Kickstarter, на самом деле, с тебя не снимают деньги до последнего момента.
Никита Дубко: Я сразу с этим не разобрался, просто если бы я знал, я бы, наверное, даже… Но я и задоначу, знаешь, что уж тут? Просто ситуация какая? Когда они это начинали, ты такой: «Ага, мне сходу нужно денежку отдать, и сейчас у меня, допустим, нет такой возможности». А оказывается, что это было бы в ноябре, и я в принципе мог бы… Как здорово, что еще есть время.
Вадим Макеев: На самом деле, это все можно было прочитать на сайте opencollective, на основе которого все это происходит, но туда еще нужно было добраться. Неважно, главное, что теперь все знают, бегите, голосуйте вашими деньгами, даже один доллар станет двумя долларами и поможет ребятам это все профинансировать. И не разориться, кстати, потому что если они недособерут, они наверняка махнут рукой и скажут: «А, окей», кому-то зарплату не заплатят, еще что-нибудь такое. Идеалисты там в Igalia работают, я пообщался с некоторыми людьми оттуда, они, конечно, прямо опенсорсеры, линуксоиды, все такие открытые и… В общем, хиппи 21-го века. Удивительный проект. У них там плоская структура, все получат одинаковое количество денег в компании. В общем, такая коммуна практически, удивительно, удивительно. Они помогают доставлять новые фичи в браузер: MathML в Chromium, accessibility фичи, WebKit и так далее. Классно.
Новинки Npm 7Скопировать ссылку
Никита Дубко: Тут это, npm 7 вышел, и он вроде как вкусный, да? Можно так говорить про инструменты, «вкусный»? Я слышал, что некоторые бесятся.
Вадим Макеев: Я пропущу вопрос.
Никита Дубко: Ладно. В общем, npm 7, что в нем появилось? На самом деле, кажется, у них такой анонс, он такой коротенький, но со ссылочками, они хитро сделали, они сделали такой, вроде быстренько, а когда проваливаешься в explainer, и ты такой — о-о, какая тут глубина.
Вадим Макеев: Это вам не релиз Webpack, но об этом еще поговорим.
Никита Дубко: Это правда. Так вот, они сделали три по факту фичи, и эти фичи, они такие, каждая заслуживает отдельного эксплейнера, что они и сделали. Первое — это то, чего, наверное, прям ждали, это клево, это workspace, это возможность тебе взять и объединить, действительно, под какое-то рабочее окружение объединить, условно, папочку или по маске как-то выделить. Ты можешь действительно какой-то уровень этого огромного развесистого дерева выделить в отдельное рабочее окружение, и там по-своему крутить чего хотеть, package lock свой настраивать и это все.
Почему это действительно сейчас такая штука актуальная? Потому что есть спрос на монорепозитории, и, причем, он растет, в том числе, и в больших, и в малых компаниях, и те же самые всякие open source проекты потихоньку на это переходят. Когда у тебя есть монорепозиторий, там действительно есть проблема это все разруливать, зависимости внутри, внутренние сборки, когда у тебя кусок монорепозитория является зависимостью второго куска монорепозитория. Это все — это огромная боль. Есть, конечно, специальные инструменты для этого, кто-то пишет свои костыли, кто-то лёрну, лерну, я ее «лёрна» называю почему-то, не знаю, кто-то ее эксплуатирует.
Антон Кастрицкий: Приведем еще пару примеров, чтобы, возможно, кому-то было это более очевидно. Например, если пойти на GitHub и, например, зайти на тот же самый Babel, можно заметить, что у них есть папочка packages, внутри которого есть очень много отдельных пакетов, и это собственно и представляет собой монорепозиторий, в котором уже хранится большое количество npm-пакетов. Так исторически сложилось, что npm этой фичей не владел, и сообщество стало пилить свои инструменты для того, чтобы как-то разруливать подобные ситуации. Есть Lerna, которую изначально делал Джейми Кайл, потом он также сделал Bolt, что уже больше относят к проджект-менеджменту, но, тем не менее. Я могу ошибаться, но, по-моему, в какой-то момент даже yarn начал поддерживать workspace, этой фичей я не пользовался, поэтому тут я прокомментировать не могу.
Вадим Макеев: Получается, что workspace делают Lerna ненужной, или дополняют, или как?
Антон Кастрицкий: Кажется, что от Lerna можно будет отказаться. Но я еще не игрался с этой фичей, но мне очень интересно.
Никита Дубко: Кажется, еще пока нет, потому что это только началось, и так сходу все это переписать… Плюс, у Lerna есть еще кое-какие особенности и свои… В общем, проект не просто так создавался. Но действительно, спрос есть, у yarn действительно есть работа с workspace, это мы как раз обсуждали в одном из выпусков, и это такая фича, которая тогда… «О, классно, надо на yarn переходить». А вот не надо, npm тоже теперь так умеет. Я помню, мы обсуждали, чем ответит npm, чем ответит node, это все. Ответили, пожалуйста.
Антон Кастрицкий: Самое смешное то, что здесь еще третьим пунктом есть еще одна причина, почему можно больше не переходить на yarn.
Никита Дубко: Именно, это поддержка yarn.lock. Если вы живете на два мира… Я просто видел даже репозитории, где для того, чтобы и тем, и тем пользоваться, люди синхронизирует yarn.lock и package-lock.json этот вот. Это может быть полезно как раз таки, когда ты хочешь фичи из обоих миров использовать. Но синхронизировать это все — это тоже отдельная боль. Теперь не надо, теперь… Если yarn изначально делался так, что он в принципе может работать с package.json, как, он с ним работает, но создает свое какое-то такое дополнительное описание, чего ему там нужно, в этом yarn.lock, теперь npm тоже умеет смотреть в yarn.lock, и тут непонятно, это такая интересная конкуренция, минивойна, не знаю, за аудиторию. Но вы теперь можете при помощи npm работать с теми репозиториями, в которых вы работали раньше yarn. Не знаю, как на это реагировать, но, скорее всего, этого позитивная новость в плане того, что действительно стала совместимость, то есть те фичи, которые были в yarn, видимо, npm теперь их понимает, он умеет парсить и у себя тоже их обрабатывать. Кажется, оба инструмента в итоге выиграли от этого.
Вадим Макеев: Круто, а вторая фича? Я периодически сталкивался… Я не профессиональный пользователь npm, я бы так сказал, то есть я всячески, много его используют для разных задач, понятное дело, но прям чего-то сложного и тем более монорепозиториев в руках держать и поиспользовать, настраивать не приходилось. Я помню, что какое-то время для меня периодически болью становятся эти peer dependencies, которые нужно как-то отдельно ставить, управлять и вообще врубаться, что случилось с моим репозиторием, почему ничего не работает. Кажется, проблема сейчас решается, и я правильно понял эту новую фичу?
Антон Кастрицкий: Да, про фичу заключается в том, что теперь автоматически будут стамбливаться пир-зависимости. Как многие знают, в npm в package.json есть четыре зависимости, это dependencies, dev dependencies, peer dependencies, и есть еще optional dependencies, которыми по моим ощущениям вообще никто не пользуется. Первые будут всегда устанавливаться, обычные dependencies, вторые будут устанавливаться только когда вы прогоняете npm install внутри вашего пакета, то есть если ваш пакет кто-то устанавливает, вместе с ним приедут только его основные dependencies, и peer dependencies — это пакеты, которые должны будут предоставить потребители вашего пакета. Давайте приведем пример. Я написал какую-то библиотеку для React, для потребителей, которые живут в экосистеме React, и я не хочу в своей библиотеке хардкодить версию React, потому что к потребителям тогда приедет две версии React, и вместе с ними разруливать это не очень весело. Я указываю React в peer dependencies, и люди, которые будут уже пользоваться моим пакетом, должны будут убедиться, что внутри их пакета у них в зависимостях есть React, и он будет использоваться. Но в целом так сложилось, что такие общие пакеты должны жить в пирах, но эти пиры, peer dependencies, они автоматом не устанавливаются, поэтому в большинстве таких пакетов, когда вы пытаетесь первый раз их развернуть, можно ставить такой скрипт, как npm rank bootstrap, внутри которого устанавливаются эти пиры и еще несколько полезных утилит. Если когда-то вы пытались развернуть чужой проект, и спотыкались о то, что, блин, здесь же есть еще какой-то скрипт, который нужно прогнать для того, чтобы можно было начать развернуть примеры уже в нем, покопаться и исправить это багу, скорее всего, это было именно это. Я очень рад, что эту вещь наконец-то решили.
Вадим Макеев: Это было решение, которое не сработало, именно такой механизм работы с пирами, и теперь они его немножко меняют для того, чтобы проблем было меньше, скриптов, и не нужно было костыли писать.
Антон Кастрицкий: Именно так, да.
Вадим Макеев: Хороший набор изменений, когда я смогу начать их использовать?
Антон Кастрицкий: Как я понял, эта штука уже включена в 15-ю Node, но обновиться на нее можно и находясь на 14-й или более ранних версиях.
Вадим Макеев: Вопрос, грубо говоря, я сейчас сижу, условно, у меня 14-я Node стоит, и я захочу использовать фичи npm 7, я просто обновляю свой npm, и у меня все работает или нет? Я видел, люди постили скриншоты, потому что у них далеко не все работает.
Антон Кастрицкий: Так происходит всегда, когда пытаешься жить на gliding edge, то есть нужно быть готовым стать первопроходцем. Мне кажется, в этом нет ничего страшного, если вдруг есть опасения, то можно немножко подождать до 16-й Node, поскольку 15-я — это не… Как сказать? Я боюсь использовать слово «стабильный релиз», это не «стабильный», есть какое-то другое слово, я надеюсь, вы поняли, что я имею в виду. Это не тот релиз, который уйдет в LTS, то есть в поддержку на долгое время, поэтому за время существования 15-й Node его полноценно обкатают, и уже к 16-й, я думаю, можно будет спокойно считать это production ready решением.
Вадим Макеев: Я для себя это называю так. 15-я Node –это следующая версия, а 16-я Node — это следующий релиз.
Никита Дубко: На самом деле, у них же написано в документации, что по умолчанию тебе нужно четенько указать, вместе с latest у тебя npm не приедет 7-й, у тебя будет приезжать предыдущая все еще версия, а если ты ставишь себе 15-ю, тогда приедет уже 7-й. это они, видимо, тоже понимают, что там есть какие-то нюансы, и четко про это даже предупреждают в релизе.
Антон Кастрицкий: Нет, на самом деле, я думаю, можно ведь, грубо говоря, если какой-то команде страшно нужно жить на 14-й Node, потому что с 15-й пакеты несовместимы, например, но хочется использовать фичи 7-го npm, можно же как-то разрулить на уровне конфигов, на уровне package.json версия npm прописывается. Хотя, будет ли она автоматически переключаться? Тоже вряд ли. NVM, по-моему, не умеет переключать версию npm, он только версию Node умеет переключать, да?
Вадим Макеев: Просто интересно, что обычно же в package.json не указывается npm как зависимость и версия npm как зависимость.
Антон Кастрицкий: В package.json можно указать vengeance-версию Node или range этих версий.
Вадим Макеев: Да.
Антон Кастрицкий: А про npm, мне кажется, там тоже есть поле для npm, но я им ни разу не пользовался.
Никита Дубко: Мне казалось, там же vengeance пишется прям, то есть там же.
Вадим Макеев: Круто, потому что иногда бывает, что нужно Node постарее, npm поновее. Надо разобраться, действительно, если кто-то хочет с воркспейсами начать работать именно в npm, кажется, вариант.
Антон Кастрицкий: Тут есть еще один пункт, про который я хочу сказать пару слов. Тут ребята помечают то, что они не то, чтобы помечают npx как деприкейтнутую версию, но они его полностью переписали, чтобы он работал поверх npm-exec команды, и он теперь будет кидать ворнинг, если вы пытаетесь прогнать какой-то пакет, который не был установлен. Раньше, до того, как у нас был npx, мы писали путь node_modules/.bin и команду, которую мы хотим выполнить, а теперь мы уже можем просто запускать его как npx-команда. Но у этой штуки также была дополнительная фича, то, что мы могли с ее помощью прогонять команды, которые вообще не были установлены ни в рамках нашего проекта, ни на нашей операционной системе, вообще. Если у вас не установлен JS, но вы находитесь в проекте, в котором написаны JS-тесты, вы можете сделать npx jest, и у вас начнут прогоняться ваши тесты, то есть он скачает этот пакет, локально его установит ради этого одного прогона, и затем быстренько спрячет куда-нибудь в кэше обратно. Я не очень понял пока, как они будут разруливать такие моменты, но это что-то, с чем нужно поиграться. Звучит интересно.
Вадим Макеев: Я слышал, что там есть большая проблема с безопасностью, потому что любая фигня, ты опечатался, ты написал не jst, а jsst, и там какой-то левый пакет с npm тебе тут же скачался и исполнился. Это, конечно, так, нервно немножко. В общем, npm, дивный новый мир, что-то нам такое новое несет, если у вас есть причины прям бежать и включать себе, разберитесь, как, чтобы у вас все остальное не поломалось тоже.
React vs WordPressСкопировать ссылку
Вадим Макеев: Я перестал считать Энди Белла, хотя он мне симпатичен, но перестал. Он такой немножко… Он немножко интернет-тролль, он любит шитпостить в Твиттере, факт, неоспоримый факт, я думаю, он не обидится, если вдруг ему кто-нибудь переведет. Просто удалось встретиться в прошлом году на фронтенд-конфе в Москве, пообщаться, он смешной чувак. Есть с ним отдельная запись «Веб-стандартов», так что послушайте, если интересно.
Он написал пост про ужасно громкое меньшинство, и ужасно громким меньшинством он называет JS-разработчиков, точнее, не совсем JS-разработчиков, а разработчиков, которые пишут на каком-нибудь single page стейке. В чем проблема? А проблема в том, что когда вы идете в Твиттер, вы слышите: каскад — это плохо, CSS уже не работает для веба, HTML — это глупый язык, давайте что-нибудь переизобретем, переделаем, еще что-то такое. И вы думаете — в Твиттере ерунды не скажут. Нет, даже по-другому, вы слышите эту реплику один раз, второй раз, третий раз, четвертый, пятый раз и думаете — блин, все так говорят, все так думают. Ты идешь с друзьями пообщаться о чем-нибудь таком, и плюс-минус фронтендерские темы всплывают, и ты понимаешь, что все мои друзья пишут на React, все мои друзья пишут на MacBook, все мои друзья, не знаю, у всех в кармане дорогой телефон, все-все-все… И ты понимаешь, что весь мир, ты экстраполируешь свой ближайший круг, естественно, на весь мир, на весь город, на всю страну, и в конечном счете на все фронтендерское сообщество, и думаешь — ну, все же так делают, все, кого я знаю, пишут на Single Page, все, кого я знаю, не любят cascade CSS и так далее.
А если посмотреть на статистику, получается совсем другое. У статистики, естественно, есть свои проблемы, и Энди Белл пытается нащупать вообще, а кому это не нравится, тем, кто громче кричит, тем кто пишет 1% веба, как он посчитал, тем не нравится современный веб, те хотят все переизобрести и писать на условных Single Page. Получается очень такая неловкая ситуация, в которой люди, которые громче всего говорят, убеждают нас в том, что они правы, и мы начинаем на основе этого принимать собственные решения и выставлять собственные приоритеты. Как вам такой вброс, ребят?
Никита Дубко: Забавно, но, кстати я хочу Энди назвать как раз таки таким громким человеком, потому что у этой статистики есть один подвох — все сайты в интернете, это не значит, что это все активные сайты, которые прямо сейчас разрабатываются, это сайты, которые, черт побери, с 1993 года существуют, WordPress позже появился. Их много, и их много тех, которые работают просто… как они, летят, потому что когда-то их сделали более-менее стабильными, и они работают. Там не нужен React, все отлично работает.
Есть современные требования у разработчиков, есть необходимость, бизнес-необходимость делать быстро, делать хорошо, делать качественно за счет переиспользования компонентов.
Здесь, скорее, мне кажется, это extremely loud minority — это спикеры, которые ездят по конференциям, а не люди, которые любят рассказывать про хорошие практики, и про Vanilla, и все такое. Чего уж тут, я сам такой, не знаю, в этом чатике есть еще такие люди. Это люди, которые рассказывают best practices, но по факту, чтобы делать это широко, они рассказывают это про такие технологии как Cube CSS, который придумал Энди. Скорее всего, у меня подозрение, что его бомбит из-за того, что на этот Cube CSS точно прибежали люди, которые… «Да что вы там в своем CSS постоянно придумываете, как изолировать ваши стили? Столько лет прошло, а вы все придумываете и придумываете. Вот, смотрите, в React, и вот тебе два пакета, которые решают одну проблему, три пакета — четвертую проблему». Это все… Да, оно как-то разделяет сообщество, потому что есть люди, которые: «Я хочу быстро и в принципе неплохо», а есть люди которые: «Я хочу разбираться в вебе, и ваш React не вечен, он когда-нибудь закончится». Очень сложно объективно эту статью комментировать, потому что, да, есть статистика, но мне кажется, если разбить ее по годам, и если еще MDN этот опрос проанализировать… Статистика The State of JS как раз таки говорит о том, что React популярен.
Вадим Макеев: Но проблема в том, что те, кто прошел опрос, они уже крутятся в сообществе, они уже трендовые, они уже интересуются технологиями, и тут, естественно, есть перекос в сторону… Как сказать? То, что какой-нибудь The State of JS — 98% мужчин и 2% женщин, это не говорит о том, что такова система, что таково соотношение, допустим, полов внутри разработки, нет. Просто прикол в том, что именно активная часть сообщества, те, кто хотят рассказать, поинтересоваться или, не знаю, высказать свое мнение погромче, там такой перекос. Я просто что в случае с Энди, что в случае со The State of JS не вижу нормальной репрезентативной картины. Но Энди дает повод усомниться, Энди дает повод посмотреть по-другому на эту картину. Мне именно этим его вброс нравится, он по-прежнему немножко тролльский, он по-прежнему некорректный во многих смыслах, но он говорит: «Ребята, посмотрите чуть-чуть шире, чем ваш ближайший круг, посмотрите на то, чем занимаются люди». Опять же, в наш чатик «Веб-стандартов» в Telegram периодически приходят люди и говорят: «Я не могу использовать эти технологии, потому что у меня такая браузерная совместимость». А другие говорят: «А у меня на проекте, я пришел на проект, новый, клевый, а там jQuery». Или «я пришел на проект, а там такая-то CMS». Какой там React, туда даже Vue не воткнуть адекватно, если уж хочется чего-то подобного. А проекты живут, работают, приносят деньги, я не знаю, все интерфейсы, все сайты «Академии» не переписаны на React, потому что мы можем. К нас только, не знаю, чаты, дээмки и какие-то еще прямо совсем интерактивные интерфейсы, которые прям совсем веб-приложения стопроцентном смысле, они написаны на React, все остальное… Да нет, работает и без этого всего развесистого. Не потому, что это новый дефолт, а потому что это решает для нас какие-то конкретные задачи, и мы живем с этим прекрасно. Для всех остальных задач они и не нужны.
Антон Кастрицкий: Примерно года три своей карьеры потратил именно на работу с WordPress. Мне кажется, я тут могу поделиться. А именно, у меня сложилось такое впечатление, что в этом островке индустрии… Я полностью вообще согласен с автором, что это уже не minority, это очень большое количество людей, но при этом я также согласен с Никитой про то, что это сайты, которые могли сделать 10 лет назад, они все еще работают. Ну и что, что на них заходит два человека в год? Это же сайт, его может точно так же сравнить, например, с Яндекс.Маркетом, в котором я работаю, куда заходит значительно больше людей. Это совсем не громкие люди, это не те, кто будут ходить по митапам и рассказывать: «Ой, представляете, я такой плагин себе установил». Большинство, с кем я сталкивался, кто работал или до сих пор работает в этой индустрии, это люди кто может вообще даже не думать, что значит система сборки в проекте.
Я написал, и оно уже все, по ftp залилось, и работает. Я ни в коем случае не пытаюсь как-то принизить эту часть индустрии. Я встречал большое количество людей, кто, имея по пять лет опыта, совсем не пользуется системами контроля версий, использует какие-то внутренние тулзы этой WordPress-индустрии, который за вас просто раз в день будет делать бэкапик, и вы сами в любой момент можете откатиться.
Мне кажется, это две такие довольно разные парадигмы. В целом это, наверное, нормально, то, что кто-то из них громкие, потому что они тусуются в Твиттере, и Твиттер сам располагает к тому, чтобы быть более вызывающим, оттащить людей на диалог.
Вадим Макеев: Это проклятие современных соцсетей, они, пытаясь доставить тебе интересный для тебя контент, в итоге изолируют тебя в таком ecochamber, ты слышишь то, что ты хочешь слышать.
Антон Кастрицкий: Bubble.
Вадим Макеев: Да, да, да.
Уже Webpack 5Скопировать ссылку
Никита Дубко: Тут релизы короче за релизами. Webpack 5. Представляете? У меня так такая же реакция была, как в чатике «Веб-стандартов», типа, мы тут на 4-й переехать не успели, остановитесь, какой 5-й, что происходит, мы еще на втором сидим, как так-то? А вот, все, раньше надо было… Вебпяка, мне понравилось слово, простите. Webpack 5, короче, зарелизился, и этот тот случай, когда релиз-ноуты очень подробны, и это даже, наверное, в минус, потому что я очень долго читал, чего они сделали, и пока дочитал, забыл что они делали в начале.
Но если коротко, у них там есть как и breaking changes, так и по большей части оптимизация производительности, то, что я увидел. Они покопали в сторону, во-первых, tree shaking, который все развивается и развивается, и прямо уже как стандарт уже, что ли, во всех этих сборочках, без него никуда. Улучшили всякие алгоритмы, начали использовать более крутые для кодогенерации. В общем-то, да, все идет к тому, что работают про перформанс, то есть это перформанс самой сборки, они его тоже подтюнили нормально, то есть ваша сборка будет не пять минут, а четыре минуты, вы сможете заварить меньше кофе. Tree shaking — это меньше на клиент приходит ненужного, как раз они очень много расписали, каким образом это все ненужное убирается, то есть это, в том числе, поддержка того, что уже можно не поддерживать. Они выпилили No JS полифилы, где эти No JS полифилы, например, не нужны. Они сейчас взяли ориентирование на клиент. А дело в том, что, я думаю, те, кто работает с Webpack, понимают, что можно как и на клиент, так и на сервер это все, это просто инструмент, который одни файлики в другие превращает, а где вы их запускаете, это уже ваши трудности. Но у них ориентирование теперь идет на фронтенд, на веб-платформу, то есть больше поддержка реалий, я бы так сказал, есть браузеры, в браузерах уже, например, работают динамические импорты больше, чем раньше, значит, можно с этим поиграться. Можно этот самый tree shaking как-то так сделать хитро, чтобы еще меньше приходило на клиент ненужного, можно прямо на ходу какие-то вещи анализировать, что нужно прямо сейчас, что не нужно. Опять же, есть фреймворки, популярные сейчас у фронтенд фреймворкм, например, React, и можно сделать какие-то штуки, которые именно под этот React заточены, потому что есть спрос.
В общем, я не знаю, через весь этот список продраться — это прям сложно. Антон, я понимаю, что ты в Webpack ковырялся. Что ты можешь выделить здесь такого прям сочного?
Антон Кастрицкий: Мои, пожалуй, три самые любимые, и они в начале этого списка, поэтому мне легко их вынести, первое — это изменение, как ребята начали работать с кэшами, это такая небольшая боль моя, в том числе, была, что очень влияло на скорость сборки, что особенно критично в момент самой работы над проектом. То, что у ребят появился long term cashing, это также ранее анонсировалось как улучшенный persistent cache, то есть что-то, ради чего вы раньше могли использовать AutoDllPlugin, HardSourcePlugin, то есть что-то, что в момент сборки кэшировало все, что у вас едет в ваши бандлы из node_modules, чтобы повторно не обрабатывать эти файлы. Теперь это уже должно работать из коробки, то есть вы сможете выкинуть эти самые плагины, оно у вас должно работать автоматом уже, гораздо быстрее.
Также ребята выкинули очень много всего, что было в четвертом Webpack, то есть если вдруг вы сейчас живете с 4 Webpack, и у вас есть какие-то в консоли вординги, есть деприкейтнутые штуки, скорее всего, вам нужно будет сначала пофиксить их до того, как обновляться.
Последняя и самая большая фича, которая прям, мне кажется, киллер-фича вообще этой версии, это мой modules federation, это что-то, что может позволить вам в рамках своего проекта начать обращаться к чужому чанку, который был сделан из чужой сборки, то есть переиспользовать какие-то виджеты между сборками с разными проектами. Такая фича, с которой нам пришлось поиграться внутри партнерских интерфейсов, они у нас не единственные из В2В-кабинетов в Яндекс.Маркете, но у нас была необходимость показывать переиспользуемые виджеты между несколькими кабинетами.
Для этого мы пробовали тыкаться еще в пятую альфу, нам понравилось, то есть все работает. Я ранее уже сегодня приводил пример с React, то есть если у вас две версии React на одной странице, не всегда их можно подружить между собой, можно наступить на разные костылики. Мне самому очень нравится эта фича. Мне кажется, у нее есть очень большой потенциал, который еще совсем не раскрыт. Тут же можно докинуть несколько базвордов, как микрофронтенды и подобное.
Вадим Макеев: Слушай, а можешь еще раз объяснить про этот федерейшн?
Антон Кастрицкий: Давай представим, что ты сидишь в одной команде, я не знаю, вообще в другом здании, работаешь над своим продуктом, я в другом офисе работаю над своим продуктом, и внезапно я понимаю, что мне нужен этот кусочек, один конкретный кусочек твоего приложения отрисовать на своей странице, чтобы он умел ходить в твои эндпойнты. Я могу только лишь сославшись на него, вообще не зная про то, как собралось, когда последний раз собиралось твое приложение, загрузить его на свою страницу, он уже будет использовать мою версию React, которая у меня используется, и он правильно отрисуется, и может быть, будет какая-то формочка, человек может ее засабмитить. Он, как сказать, окажется first class citizen внутри моей страницы.
Вадим Макеев: А это требует каких-то дополнительных телодвижений от разработчика, подготовить все к этому, или оно все само?
Антон Кастрицкий: Оно все не само, определенно, документацию придется почитать. Но мне кажется, это того стоит. Я почти уверен, что за ближайший год выйдет отнюдь не одна статья про то, как правильно это готовить, что значительно понизит порог входа, и это будет здорово.
Вадим Макеев: У нас кто-то в соцсетях сказал, что главная фича — это modules federation, но никто не попытался объяснить, почему это важно и почему это хорошо. Сейчас я услышал эту версию. Она звучит интересно, но опять же, фича, кажется, узкая, в смысле, она нужна, когда у тебя что-то совсем уж развесистое, но она звучит очень ценно для такой ситуации, конечно.
Антон Кастрицкий: В целом, пока мы находимся на этой странице, про Webpack, я хотел бы еще пару вещей отметить. Никита начал с того, что кто-то еще не успел переехать даже на 4-й. 4-й Webpack вышел уже два с половиной года назад, то етсь это отнюдь не то, что они клепают мажорные версии, первая альфа вышла еще полтора года назад, я помню, я тогда как раз читал свой доклад про Webpack, как настроить энтерпрайз-сборку так, чтобы она не тормозила. Эти полтора года мы ждали этого мажорного релиза, и наконец-то он случился, уже, мне кажется, даже 5.1, с патчами, тоже вышел. Можно начинать играться.
Самая последняя основная идея, в целом я не считаю, что Webpack нужен всем. Мне кажется, это довольно сложная штука, которая подходит в тех местах, когда вам действительно нужна эта гибкость сборки. Гораздо чаще и большему количеству людей может подойти тот же Parcel.
Никита Дубко: Я думал, ты скажешь Gulp, и я тебе поаплодирую
Вадим Макеев: А я надеялся, что это Rollup, потому что если вам просто JS собирать.
Антон Кастрицкий: А мне кажется, Rollup все равно нужно уметь настраивать, а Parcel за тебя уже может попробовать увидеть: «О, я у тебя нашел.babelrc, дай-ка я тебе еще Babel сейчас установлю, и кажется, у тебя здесь sas-файлы, ты их импортируешь, я тебе SAS тоже притащу». Он прямо совсем beginner friendly.
Вадим Макеев: Я не люблю слишком магические пакеты. Я просто к тому, что если нужно, допустим, как-то JS пособирать, то Rollup более чем достаточно, а если уж нужно что-то прямо совсем сложное делать… Хотя и для Rollup можно плагинов насобирать, у них в последнее время развивается хорошо. Но я к тому, что есть альтернативы. Да, это не единственный, если вам больно пользоваться Webpack, возможно, вам он не нужен.
Что такое RomeСкопировать ссылку
Вадим Макеев: Антон, ты тут тредик написал, я тебя позвал по его мотивам сюда. Можешь как-то коротко запичить, что это такое, и почему это может стать для кого-то интересным, этот Rome Frontend Toolchain?
Антон Кастрицкий: Rome собой представляет такой очень большой инструмент, в котором есть очень много всего. Бо́льшая часть этого уже работает с собственными внутренностями, наружу торчит только линтер, если мы говорим про сегодня, но в обозримом будущем у него есть очень такие большие планы, он хочет захватить весь мир, а именно, он хочет собой, одним только собой, Rome, заменить и Babel, и ESLint, и Webpack, и Prettier и Jest, много-много всего другого. Та же Lerna, про которую мы ранее говорили, у них есть и на это планы.
Я могу больше рассказать про то, как он работает изнутри, почему меня он так сильно заинтересовал. Мне кажется, нужно обязательно рассказать про самого автора, поскольку он был написан очень известным человеком, Себастьяном Маккензи, это автор Babel, он долгое время работал в Facebook, в инфре он также приложил руку над самим yarn, про который мы тоже уже сегодня говорили.
Тут можно сделать такой gist, это не кто-то, кто только что пришел, а кто-то, у кого уже есть большая экспертиза в таких инструментах, которые должны будут работать на комьюнити очень разносторонние.
Вадим Макеев: И большая экспертиза в open source, потому что мало написать код, нужно и заставить его не просто понравится всем остальным, а еще и чтобы люди приходили, помогали, развивали и заинтересовывались. Я гляжу на проект Rome на GitHub, и там уже open governance, там уже и сайт, и логотип, и одно, другое, третье, это, по-моему, все достаточно рано появилось. Он с самого начала появился не просто как проект выходного дня, а как как проект с заявкой на что-то большое. Судя по тем целям, которые ты описал, амбиции у него не фиговые, и для этих амбиции у него соответствующий фундамент уже есть.
Антон Кастрицкий: Я думаю, тут даже можно рассказать немножко про историю. Те, кто подписан на Себастьяна в Твиттере, последние несколько лет могли наблюдать, он любил тизить разработчиков разными скриншотами о фичах, которые будут использованы в Rome, как это выглядит, как это удобно, как это здорово и просто даже задумавшийся о контрасте, как сегодня работает ESLint, как сегодня работает Babel или какие-то схожие инструменты, уже, не знаю, чесались руки, блин, когда же это можно будет потрогать уже, очень-очень хочется.
Примерно полгода назад Rome вышел полностью в open source, то есть раньше он разрабатывался исключительно под нужды Facebook, потому что Себастьян-то работал в Facebook, сейчас он уже там не работает, он ушел в Discord вместе с еще несколькими очень известными людьми, и также внутри самого Rome произошло несколько интересных изменений. Он внезапно был переписан с Flow на TypeScript.
Вадим Макеев: Видимо, если ты работаешь ли уже не в Facebook, то нет смысла писать на Flow, да?
Антон Кастрицкий: Да. На сегодняшний день TypeScript определенно победил со своим комьюнити. Вместе с этим также появился открытый вебсайт, на котором превосходная документация, мне очень нравится правильный фундамент, который был вложен в Rome. Ребята отлично расписали, какие у них есть цели, как они хотят их добиваться, что они делают в первую очередь, чем они будут заниматься далее. Об этом мы тоже уже поговорим. В Rome уже внутри есть и свой линтер, чем они сам Rome и винтят, это что-то, чем вы уже можете пользоваться сегодня. Последняя версия, которая доступна в npm, она сейчас вам позволит это сделать только с помощью табов, но следующая версия, которую опубликуют, там уже будут пробелы.
В целом, Rome, его можно назвать такой, как opinionated tool, он очень хочет за вас сразу предоставить все дефолтные настройки, и в каком-то плане он очень похож на Prettier в том плане, что очень мало чего вам получится настроить, по крайней мере, сегодня. Как мне кажется, это большой плюс. Rome также уже умеет парсить, у него есть разные парсеры, не только для JavaScript, для TypeScript, Markdown, TOML, PCSS…
Вадим Макеев: HTML даже. Я тут читаю issue, тут написано 8 августа: «Я внедрил довольно ужасный HTML Parcer, который не то, что несовместим со спекой, даже близко несовместим, но мы будем его потихонечку итерировать на основе этого».
Антон Кастрицкий: Эти вещи еще не торчат наружу, то есть они могут использоваться внутри для генерации документации, поэтому не стоит пугаться. Также, мне кажется, можно сказать, что если вы будете слушать этот подкаст, как он выйдет, а сегодня у нас октябрь 2020 года, и если вы откроете GitHub и увидите, что последние пару месяцев очень мало чего произошло в Rome, то не пугайтесь, пожалуйста. Себастьян переезжал, и поэтому у него меньше времени хватало на Rome, но помимо GitHub, кстати, есть сервер в Discord, где тоже ребята общаются, бывает, я там могу задавать какие-то вопросы. Не знаю, мне кажется, у меня приняли на сегодняшний день, может, всего парочку pull requests туда, но у меня есть еще идеи, что там можно исправить и сделать лучше, о чем мы еще поговорим.
Могу рассказать про несколько вещей, которые меня, например, удивили. Rome написал свой собственный компилятор для того же TypeScript, сам Rome полностью написан на TypeScript. Давай еще сделаем шаг назад, в первую очередь, у Rome нет никаких зависимостей. Если ты откроешь GitHub, откроешь их package.json, посмотришь на dependencies, они будут пустые, а сверху будет комментарий о том, «смотри, как круто, можешь так же?»
Вадим Макеев: Это какой-то спорт, или в этом есть ценность?
Антон Кастрицкий: Мне кажется, в этом есть ценность, поскольку ты можешь полностью управлять всем, что ты используешь.
Никита Дубко: Как сейчас Вадим на спортсменов-то набросил.
Вадим Макеев: В смысле, спорт ради того, чтобы показать, что ты можешь, в этом смысле.
Антон Кастрицкий: Мне кажется, это не странный флекс, а именно нарочно принятое решение, когда ты можешь полностью управлять всеми движущимися частями, на которых ты стоишь, ты можешь стоять с гораздо большей уверенностью.
Вадим Макеев: Если сможешь встать, потому что тебе нужно сначала написать весь скелет, все мышцы и всю обвязку.
Антон Кастрицкий: Да, то есть тут уже у нас, конечно, получится эта знаменитая проблема про бананы, гориллу и джунгли. Но, по моим ощущениям, у Rome это уже получилось, и бо́льшая часть джунглей уже выросла.
Никита Дубко: Можно, я все-таки понабрасываю? Ты сказал, что большой плюс — это то, что он все делает сам из коробки. Меня корежит это все. Мы в свое время тут с Вадимом холиварили про Prettier, и в целом мне Prettier норм, но при этом я четко понимаю, что для каких-то проектов Prettier абсолютно не подходит, потому что, условно, тебе нужно в команде по-другому немножко, у вас есть какие-то особенности, проект большой, проект с legacy, еще что-то, и его ты не можешь взять его, на него натянуть это свежее, клевое. Я так понимаю, что Rome, он для старта каких-то проектов, наверное, норм. Но ведь новый проект — это не такая частая история. Не знаю, убеди меня, пожалуйста, почему это хорошо, и почему все говорят, что это клево, когда всего за тебя решают.
Антон Кастрицкий: Хорошо, давай, тут есть два пункта. Первое, я не считаю, что Rome сегодня production ready, и тебе нужно завтра уже бежать переписывать и выкидывать весь свой…
Вадим Макеев: Нет, подожди завтра мы перепишем все на Webpack, послезавтра мы перепишем на Rome.
Антон Кастрицкий: Черт побери, ты прав. А второй пункт — это про Prettier, если ты помнишь, когда он впервые вышел, у него вообще не было никаких опций, и эти опции долго спорами, с кровью и потом доказывались, что «ребята, пока не появится такой опции, мы совсем никак не можем его использовать», и только после того, как там, не знаю, десятки, если не сотни людей отписали то, что «нам очень нравится этот инструмент, пожалуйста, пожалуйста, добавьте этот флажок, чтобы мы могли стащить его себе». Таким же подходом, мне кажется, будет все работать и с Rome. Сегодня и в Discord, и в issues ребята жаловались, что «как же так, у вас только пабы, и все, как мне жить? Я пробелы люблю, да еще и не 2, а 4». И было принято решение — да, хорошо, давайте поддержим такую штуку. Кстати, для такого рода настроек не нужно будет лезть в сам файл Rome, он при инициализации добавит вам EditorConfig, который уже очень распространен в индустрии, мне кажется, это стандарт, который используется не только в фронтенде, но и в других сферах.
А основная фича того, что Rome все делает сам, это отнюдь не про линтинг, как мне кажется, а, скорее, про то, как эти разные инструменты, то есть и компилятор, и бандлер, и линтер, и test runner могут взаимодействовать.
А расскажи мне, пожалуйста, какие проблемы у тебя были, Никита, с Prettier, чтобы я мог еще немножко раскрыть эту тему.
Никита Дубко: Нет, давай ты лучше у Вадима спроси, у меня как раз таки с Prettier… Мы с ним подружились в итоге.
Вадим Макеев: Я могу рассказать про свои проблемы с Prettier. Я хочу, чтобы вся эта связка — линтинг, тестирование, автофикс, еще и плагины мои в моем редакторе были, во-первых, адекватно интегрированы, а во-вторых, чтобы я мог себе накидать EditorConfig, чтобы я мог накидать себе какой-нибудь Stylelint какой-нибудь config, .stylelintrc, и чтобы инструмент по умолчанию работал, как он работает, со своими внутренними дефолтами, но как только он увидит в моем окружении конфиги, которые я для себя написал, то он, не задавая вопросов, начинал работать по моим настройками. Это как EditorConfig работает — ты кидаешь его в корень проекта, и редактор не говорит: «У меня здесь другие правила», нет, он просто видит config, говорит: «А, окей, все, меняю свои настройки». Какой-то подобной, во-первых, интеграции нескольких решений — HTML, JS, CSS, линтинг, автофикс и все остальное на основе моих настроек. Чего-то подобного я не видел, и мои попытки настроить в VS Code какую-то интеграцию, чтобы Prettier работал по ESLint-конфигу, они приводили к какой-то катастрофе, мне приходилось сносить все эти плагины, и выключать, и говорить: «Господи, нет, никогда больше». Чего-то подобного не хватает, и, как ты уже, наверное, понял, мне некомфортно в дефолтах Prettier. Для меня это тоже абсолютный стоппер. Если у меня нет возможности настроить, вкинуть свои конфиги, то я не могу пользоваться этим инструментом. Такой вот я старомодный, или такой вот я сам, человек с мнениями. Rome совсем идет по пути Prettier, или все-таки брезжит надежда на то, что конфиги будет уважать?
Антон Кастрицкий: На сегодняшний день это прям совсем Prettier, то есть там есть даже некоторые вещи, которые ты можешь указать в EditorConfig, но они будут успешно проигнорированы Rome, что меня очень смутило, когда я его первый раз попробовал развернуть в одном из своих пет-проджектов. Но, тем не менее, я уверен, что в ближайшие те же полгодика там добавится разных флажков, которые он начнет поддерживать, как я уже говорил, уже есть смердженный pull request от Себастьяна, где поддержались те же самые пробелы, которые… конечно, комьюнити не может договориться о том, что же использовать.
Вадим Макеев: Rome не поддерживал пробелы, только табы?
Антон Кастрицкий: Да.
Вадим Макеев: Вау, я уже люблю Rome. Я был любителем табов, пока не столкнулся с open source, и мне пришлось сломать свои привычки об колено.
Антон Кастрицкий: Мы сейчас не будем об этом спорить, потому что нам тогда еще несколько выпусков придется выпустить.
Никита Дубко: Тогда давай про точку с запятой, надо ее вставить в конце строчки или нет.
Вадим Макеев: Что Rome думает? Ставит?
Антон Кастрицкий: Да. Rome ставит точку с запятой.
Никита Дубко: О, тогда мне тоже Rome нравится.
Вадим Макеев: Все, переписываю все на Rome.
Инструмент будущегоСкопировать ссылку
Антон Кастрицкий: Теперь, я думаю, можно даже попробовать рассказать, как все эти инструменты дружат между собой. Вадим, как ты сказал, подружить тот же Prettier с ESLint, по сути, элементарно, но почему-то этого не происходит. Prettier отвечает за formatting и совсем не отлавливает никакие ошибки, ESLint пытается сесть на, простите, два стула, и как форматировать ваш код с автофиксами, так и находить ошибки, неиспользуемые переменные и тому подобные вещи, что звучит почти идеально, но когда они оказываются вместе, ты добавляешь плагин от Prettier в свой и ESLint config, и он начинает уже использовать и его, но порой какие-то правила начинают коллизить между собой, и становится грустно. Ты начинаешь вспоминать, как правильно игнорить Prettier-правила для ESLint, как игнорить какие-то ESLint-правила, расстраиваешься, закрываешь ноутбук, и это.
Вадим Макеев: Пишешь заявление, и уходишь к чертовой матери из этой профессии, потому что невозможно.
Антон Кастрицкий: С Rome такого быть не может, потому что все эти… На самом деле, один минус, который я сегодня в нем вижу, я понимаю, что это будет пофикшено, но в нем нету флагельной системы, то есть если мне очень нравится линтер, но у меня в компании есть какие-то общие договоренности, которые сегодня зафиксированы парой десятков кастомных ESLint-правил, я не могу то же самое сегодня применить к Rome, что чуть-чуть обидно.
Вадим Макеев: Если тебя послушать, получается, что у них на roadmap есть все.
Антон Кастрицкий: Да. Как я уже говорил, ребята хотят захватить мир, и я искренне верю, что это прям инструмент будущего. Я еще даже не попробовал раскрыть эту тему.
Вадим Макеев: Хорошо, давай теперь про будущее. Что мы выкинем из нашего нынешнего тулчейна, и что заменит Rome. У нас зависимости наши, dev-зависимости, что оттуда исчезнет, и что станет Rome, даже если не сегодня, а, допустим, через несколько лет, когда весь этот roadmap или большая его часть исполнится?
Антон Кастрицкий: Мне искренне хочется верить, что мы сможем полностью забыть про линтинг, то есть мы просто сможем отдать это Rome, и все. Следующими шагами будут компиляторы и бандлеры, поскольку на них уже будут построены остальные части Rome, если я не ошибаюсь, следующее, что должно выйти после линтера, это бандлер, поскольку без него не получится запустить тот же test runner, потому что если сравнить с тем, как работает Jest, который может индивидуально все тесты запускать, Rome сначала их бандлит, а потом уже запускает балком, то есть это не значит, что они все будут синхронно выполняться, они все равно параллелятся, но ему все равно сначала нужно их сбандлить.
Почему я считаю, что это можно назвать так громко, как «инструменты будущего»? Мне очень нравится, что ты никогда не столкнешься с такой проблемой, что «ой, а у Rome это линт-правило не работает с этим». Rome очень красиво, когда ты пытаешься линтить, покажет тебе, где ты ошибся, как это починить, «если хочешь, я починю это за тебя», и это приятно.
Вадим Макеев: Там хороший DX, получается или даже UI как таковой, этого, ошибки, он хороший.
Вадим Макеев: Да, при этом эти все инструменты… Сегодня я могу говорить о том, как это устроено с самим Rome, потому что последние пару месяцев по воскресеньям два-три часа я мог в этом поковыряться, и мне было интересно. Поэтому я могу представить то, что вот, наверное, через годик, а может, через полтора примерно такого же DX можно будет ожидать в своем проекте, внедрив туда Rome. О чем я говорю? Если сравнить с тем же с ESLint, Jest плюс Webpack, или вставь сюда любой другой бандлер, есть одна прямо такая фундаментальная разница того, как это устроено.
Инструменты, которыми мы пользуемся сейчас, они живут сами по себе, и развиваются довольно-таки отдельно друг от друга. Тот же из ESLint использует свой собственный парсер для JS, если вы пользуетесь Webpack, он использует Acorn, но, скорее всего, вы туда все равно подключите Babel. Есть какие-то такие, как слои работы, которые не дружат между собой, для этих инструментов, не говоря уже о том, что какой-то из них может обновиться, а теперь он будет использовать что-то другое, что будет уже не совсем полностью совместимо с соседним инструментом, с которым… с ним придется работать. Когда я, например, у нас на работе обновлял Webpack с третьей на четвертую версию, я потратил довольно-таки большое количество времени, чтобы подружить все эти плагины между собой, и там были определенного рода дорогие сложности, связанные с этим.
Вадим Макеев: Получается, что каждый из этих инструментов отдельно парсит, отдельно свое дерево создает, отдельно… Кроме того, что это неэффективно, в смысле, они это делают каждый раз заново, они не шарят это это дерево между собой, они еще это делают по-разному, соответственно, могут всякие артефакты вылезать.
Антон Кастрицкий: Да. У меня есть некоторая проблема с тем, что они это делают отдельно друг от друга. Давай представим, что я в своем проекте что-то поделал, внес какие-то изменения, и теперь хочу их закомитить. У нас есть несколько прекомит-хуков, которые проверяют типы, которые проверяют то, что измененные файлы были написаны по нашему стайлгайду, которые проверяют то, что измененные файлы и тесты для них, а также тесты для других файлов, которые могли быть задеты моими измененными, проходят. Довольно-таки стандартный набор. Я нажимаю git commit, и мне нужно подождать какое-то время, скажем, 10 секунд, пока JS задетектит, а что же все-таки поменялось, потому что пока я был в своем редакторе, и изменял эти файлы, на лету я мог видеть ошибки от ESLint и от типов, я уже заранее мог применить автофикс или поправить что-то руками, если это не автофиксится, и все хорошо. А в случае с Jest я… Я очень ленивый человек, я не буду, конечно же, руками прогонять эти юнит-тесты, поэтому я подожду, пока JS сам все это за детектит, прогонит эти юнит-тесты, и скажет мне, что не так. Но эти 10 секунд, которые я буду ждать, пока Jest поймет, «изменились эти файлы, значит, на эти файлы есть здесь юнит-тесты, а также эти файлы еще затрагивают еще с десяток других файлов, на которые есть здесь юнит-тесты, а теперь нам нужно их всех поднять, нам нужно поднять наш пул воркеров для Jest, теперь мы можем распараллелить прогон этих юнит-тестов, давайте их запустим, теперь они гоняются»… Я хочу сделать git commit, и сразу увидеть: «Друг, у тебя здесь есть ошибка».
Вадим Макеев: И как Rome здесь поможет?
Антон Кастрицкий: А вот я хочу рассказать. У него есть фундаментальное отличие, это то, что у него есть свой собственный сервер. Тот пример, который я привел, если ты будешь прогонять юнит-тесты или ESLint, смотря в своем редакторе, или из консоли, это два несвязанных между собой процесса, то есть там равно есть какая-то цена на boot up этой программы, тот же ESLint, это все равно нод-процесс, его нужно поднять, нужно запарсить все эти javascript-файлики.
В случае с Rome это работает иначе. Тот же плагин для VS Code, тот же плагин… для Vim есть плагин, но мне он не понравился, поэтому, может быть, придется написать свой, или SLA API, на самом деле, любое API, которое будет работать с Rome, первый раз, когда ты его запустишь, у тебя потратится примерно 4-5 секунд на то, чтобы поднять сервер, LSP-сервер. Language Server Protocol — технология, которая изначально развивалась Microsoft для VS Code, но потом вышла как общий стандарт общения между серверами конкретных языков программирования под редакторы или IDE. У вас в самом начале поднимается этот сервер, и тут неважно, как именно вы его поднимите. Допустим, вы придете утром на работу, вы просто откроете свой редактор, и у вас автоматом он поднимется, когда вы самый первый файл откроете в своем проекте или вы запустите что-то из консоли. На всем протяжении вашей работы у вас в фоне будет работать этот сервер. Вы что-то меняете, каждый раз это общение с этим сервером, он уже знает про весь ваш проект, он уже знает, как что распарсить, он уже шарит кэши между кэшами, обычными файлами, банддером и так далее. Это прям значительно сокращает работу.
Я приведу пример. У меня есть мой pet project, Swagger Lint, это линьер для Swagger и Open API схем. Он довольно-таки маленький, и мне кажется, там тысяча строк кода, можно его измерить. Но если я в нем прогоню ESLint сегодня, то это занимает порядка 10 плюс секунд, на весь проект. Если я в нем попробую прогнать Rome с уже запущенным сервером, это занимает менее одной секунды.
Это великолепно. У меня просто, я не знаю, бабочки в животе, когда я вижу что-то подобное. Я очень люблю хороший DX, я всячески стараюсь прилагать усилия к тому, чтобы сделать жизнь разработчиков легче, будь это у нас в работе или в каком-то open source, поэтому, мне кажется, я был предрасположен к тому, чтобы полюбить Rome.
Вадим Макеев: У меня есть вопрос, которым я хочу немножко закруглить уже нас. Представим, что у меня pet project, представим, что я страшно рисковый, и я хочу прямо сейчас взять, и начать использовать Rome. Это имеет хоть какой-либо смысл? Если я не энтузиаст, который хочет репортить баги и присылать pull requests, который хочет просто, чтобы заработало. Имеет смысл вообще использовать, кроме как в исследовательских целях?
Антон Кастрицкий: Мне кажется, в этом году в этом еще нет большого смысла, за исключением тех случаев, как ты сказал, если ты энтузиаст, и хочешь просто поэкспериментировать с этим.
Вадим Макеев: Можно ли себе на roadmap своего проекта на 2021 год добавить — поисследовать, вдруг Rome уже готов?
Антон Кастрицкий: Я уверен, что в 2021 году уже линтер будет полностью готов прям к широкому использованию, для него наконец-то появятся открытые API для внешних плагинов, что было бы очень, очень и очень здорово. А про остальные части я еще не могу говорить, поскольку я пока даже не могу представить, в каком обозримом будущем планируется выпустить бандлер, после которого уже смогут приходить все остальные инструменты.
Вадим Макеев: Мне кажется, линтер в этом плане — это отличная отправная точка, это что-то, что позволит тебе так опустить ножки в воду, а там, глядишь, уже и самому спрыгнуть хочется.
Никита Дубко: С вами был 252-й выпуск подкаста «Веб-стандарты» и его постоянные ведущие Никита Дубко из «Яндекса»…
Вадим Макеев: И Вадим Макеев из HTML Academy.
Никита Дубко: Сегодня у нас в гостях был Антон Кастрицкий. Антон, спасибо, что просветил нас, что такое Rome, и с чем его едят.
Антон Кастрицкий: Ребят, спасибо большое, что пригласили. Мне было очень интересно. Если вдруг у кого-то еще остались вопросы ко мне, меня можно найти в Твиттере, antonk52, а если вдруг вам по воскресеньям нечего делать, так бывает, что часиков в пять вечера я начинаю стримить на Twitch такой же хэндлер, поэтому заходите, будем ковыряться в Rome вместе.
Никита Дубко: Все, теперь придется на тебя подписаться.
Слушайте нас в любом приложении для подкастов — на YouTube, во «ВКонтакте», и не забывайте ставить оценки и писать отзывы. Это помогает нам продолжать.
Если вам нравится, что мы делаем, поддержите нас на Patreon, все ссылки в описании. Услышимся на следующей неделе. Пока.
Вадим Макеев: Пока.
Антон Кастрицкий: Пока.
