А мир во фронтенд-разработке меняется достаточно быстро. Как скоро мы увидим конкурента Vite? Как скоро уйдём с ESBuild? Внедрит ли Bun новые абстракции и будет ли поддерживать старые? Или просто удалит их?

А если мы нашли проблема в JS Runtime — можем ли мы обновить рантайм, не потеряв инструменты, на версии которых мы завязались? О нет. Кажется нужно всё переписывать.

Что будет, например, когда запустят JavaScript Shadow Realms? Vitest уже ждёт их, готов использовать. Вот только Bun будет ждать, пока Shadow Realms прорастут в WebKit. Что будет в этот промежуток с совместимостью с Vitest? (Джаред забывает, что первая реализация Shadow Realms внедрена как раз в WebKit. Но пример достаточно корректный, так как позже имплементация была убрана за флаг, потому оставим тут).

Слишком много инструментов в одном. И, при этом, в обойме нет инструмента управляющего версиями этих кусочков.

• Если бы Bun вышел в 2012 году, в него был бы встроен Grunt.
• Если бы Bun вышел в 2014 году, в него был бы встроен Gulp.
• Если бы Bun вышел в 2016 году, в него был бы встроен Webpack.
• Если бы Bun вышел в 2018 году, в него был бы встроен Rollup.
• Если бы Bun вышел в 2020 году, в него был бы встроен ESBuild.
• Если бы Bun вышел в 2026 году, в него был бы встроен ...

Это не значит, что Bun отстой. Bun хорош. Но седые и строгие деды уже чуют запах будущих проблем. Прогноз Джареда, что Bun будет с нами лет 5, прежде чем все про него забудут. Ну а все проекты, которые Bun встроил в себя и ускорил — наверстают упущенное за год.

Смотрите, что подвезли в Телеграм Beta

```javanoscript
console.log('Hello world');
```

История про баг в Safari

Недавно решил поправить browserslist в проекте и оторвал правило Chrome >= 72 как явно для нас устаревшее. После релиза получаю всплеск жалоб от пользователей Safari 15 (их много!). Бегу проверять, вижу ошибку (самое смешное, что ошибка не проявляется при включенных девтулз), откатываюсь. Дальше мучительный поиск проблемы.

Прописываю Chrome >= 74 — бага есть. Chrome >= 73 — баги нет. Ясно, дело в полях классов. Начиная с Chrome 74 у нас есть полная поддержка публичных и статических полей классов, полифилл больше не нужен. Но в Safari 15 тоже полная поддержка! Can I Use врать не будет же. Где же баг и почему его не лечит правило Safari >= 15?

Долго ищу как запустить Safari 15. Проблемное место нахожу достаточно быстро — это описанные через static propTypes, в которые прилетает внешнее значение/ссылка. Вот это место

Ищу дальше. Да, в Safari 15 есть такой баг! https://bugs.webkit.org/show_bug.cgi?id=236843 Поля классов в нём поддерживаются, но иногда не работают.

Остаётся понять последнее, почему preset-env не помогает? Ищем дальше. А вот оно как, в Babel заведена ишью уже больше года как. В комментах и @valya_reads_issue отметился. Как же лечить? Вот, например, так, как сделали в Графане. Прописать @babel/plugin-transform-class-properties в плагины.

Мораль тут такая, что спецификации спецификациями, но тестировать надо на реальных браузерах.

Почитайте тоже https://news.1rj.ru/str/valya_reads_issue/329

TL;DR «Начиная с 7.22.6 в @babel/compat-data указано, что class properties поддерживаются в iOS 14.5, а до этого было указано что в iOS 15, т.е. с Safari 15 сдаунгрейдили поддержку до Safari 14.1. Напомню, без багов эта фича работает начиная с Safari/iOS 16. »

После раскрытия кода Даталенс весь ноябрь проходит в каком-то бесконечном девреле. В декабре финальное, расскажу на YaTalks докладик и, надеюсь, эту тему пока поставить на паузу. Хотя бы до января, снежок же выпал, склоны запустились, найти бы свободный выходной.

Хочется и продуктовых задач уже поделать, фичей для юзеров позапиливать, хотя вопросов о взаимодействии с внешними контрибьюторами местами всё так же больше, чем ответов.

Не лезь туда, оно тебя сожрёт! Но тебе даже понравится.

Про билд-секреты в докере

Давно хотел написать. Вот есть задача закинуть секреты в docker build. Это не рантайм-секреты, это секреты необходимые только на этапе билда. В итоговом образе они светиться не должны (как и любые секреты).

Как тут правильно поступить? --build-arg (ARG в Dockerfile) не подходит для передачи секретов, запомните это. Достаточно docker history --no-trunc <img> и вот они, секреты, как на ладони. Значит, какие у нас варианты:

1 Вытягивать секреты из секретницы в самом билде — не всегда возможно;
2 Multi-stage билд — может существенно замедлить сборку;
3 Закинуть секреты через встроенный механизм докера!

Как оно работает. Создаём файл с секретами. Например, .secrets. Обычный текстовый файл, куда мы закинем секреты строчка за строчкой.

cat <<EOT > .secrets
SUPER_SECRET_1=$SUPER_SECRET_1
SUPER_SECRET_2=$SUPER_SECRET_2
EOT

Включаем BuildKit через env DOCKER_BUILDKIT=1. Если у ваc Docker >= 23.0 то BuildKit включен по умолчанию.

Скармливаем файл с секретами:

DOCKER_BUILDKIT=1 docker build --secret id=secrets,src=.secrets .

В Dockerfile монтируем секреты в RUN и загоняем их в env

RUN --mount=type=secret,required=true,id=secret,target=./.secrets \
    export $(cat .secrets) > /dev/null && \
    npm run build

Можно не только через файл, но и через ENV но это мне кажется наименее удобным.

Приходите в субботу 16 декабря в 12:00 (UTC+3) на стрим подсмотреть как мы записываем 400-й эпизод Веб-стандартов вживую и обсуждаем новости фронтенда за неделю. Обычный эпизод, ничего такого 🤓

https://youtube.com/live/-QyzkZ0sHRA

Я как-то уже писал, что полностью перешёл на разработку на удалённой linux-машине. В VSCode работает прекрасно, позволяет бесшовно жить на два ноута (офисный 16" и домашний/дорожный 14"). Но вот ещё что важно, мои ноутбуки на M1. А это, помимо всех плюсов, и минусы:

- относительно тормозной Докер (ещё и платный, в случае Docker Desktop/OrbStack)
- проблемы с нативными биндингами node.js

Второй момент проявляется так. Запускаем приложение и ловим какой-нибудь dyld[42703]: missing symbol called. Дальше два варианта: забить и переустановить все зависимости с --target_arch=x64 или найти виновника, и понять, что делать дальше: поднимать версию, выкидывать и менять на другую реализацию, форкать, поднимать транзитивные через override и т.д. Не самое приятное развлечение.

Из хорошего то, что таких случаев всё меньше и меньше, да и Rosetta 2 получилась удивительно хорошей. Но всё же тонкие клиенты — это кайф. Пока не сядешь в поезд.

Пока ещё пишу итоги (ну ждёте же?). Прервался на запись просто огромного новогоднего выпуска Веб-стандартов. С видео. Как вы любите.

Как Вадим будет это всё монтировать — даже не знаю. Пошлите ему лучиков поддержки.

Итоги 2023

Жизнь и около

Закопался в работе по самые уши. Перегрузка делами помогает удерживать кукуху на месте. Но отпуск брал, тут я немного молодец в этом году.

Почти не пропускал подкаст. 35 эпизодов по 2 часа + ~1.5 часа подготовки. 122,5 часа получается. Нехило. Хорошо, что монтирует Вадим.

Примерно 140 часов провёл в дороге. Обычно работал. Перевёл домашний 14” ноутбук в режим рабочего. В дороге-то самое оно.

По спорту всё слабенько. На велосипеде даже традиционной соточки не сделал, максимально на 75 км выкатывался и то разок. Ну и суммарный пробег за сезон совсем небольшой.

Много плавал, регулярный бассейн для спасения спины. Купил сап, штука ленивая, но приятная. В гидрашке даже в сентябре хорошо.

На сноуборде катался до середины марта и открыл сезон с первых чисел декабря. В конце прошлого сезона обновил доску (прошлой уже лет 15 минимум было. Ох ты ж). Сменил крепы Flow на классику, сначала чуть не плакал, но сейчас уже привык.

Программирование

Вернулся в ШРИ, сделал лекцию по node.js. Одной лекции явно недостаточно, весь материал не запихнуть, добивал внезапным мастер-классом, но всё равно. Надо что-то сделать тут.

По работе — много ковырял node.js, девопсил. Мало трогал UI, в основном чинил баги. Всё как люблю. Плакал от багов gRPC. Настраивал Webpack, выравнивал зависимости. Будни фронтендера.

Полностью поменял воркфлоу. Слез с Idea/WebStorm и полюбил VSCode. vim конечно никуда не делся, когда надо поковырять файлики. Вообще, уменя ощущение, что сейчас мы видим начало конца традиционных больших IDE, вместо них снова приходят текстовые редакторы, но дополненные LSP, LLM-моделями и плагинами.

Перешёл на разработку на удалённой машине (отчасти следствие перехода на arm-процессоры, работать локально на маке стало больней). Разрабатывать прямо в linux со всеми сетевыми доступами — счастье. Перестал носить с собой ноут каждый день.

Разочарование года — декораторы в TypeScript. Ждали, ждали, они вышли и что? Будем ждать нативных.

Боль года — ESM. Очень больно. Ну вы и сами знаете.

Техника и гаджеты

Традиционно раз в три года обновил телефон. Дождался падения цен на iPhone 15 (не про) и взял. Ожидаемо ничего нового, но type-c, хорошая камера и dynamic island дают радость новизны. Type-c вообще провоцирует на эксперименты «а если я в тебя вот это воткну, то что получится?». Докупил кошелёк — подставку от Moft. Удобно! Лучший недорогой гаджет в этом году.

Андроид обновлять не стал. Pixel 5A в целом справляется с задачей поглядеть на приложения, а как основную OS для жизни я Андроид рассматривать всё ещё не могу. Хотя уже близко.

Основной клавиатурой в этом году стала NuPhy Air 75. Так как работаю в основном в офисе, то взял на красных. Сойдёт. Хотя отсутствие на ней F5-F6 без Fn — огромный недостаток.

Самая бесполезная покупка года — iPad mini. Продал. Обычный iPad Pro 11 так же пылится в шкафу. Не буду говорить, что планшеты это тупиковая ветвь развития, многим они заходят. Мне пока никак.

RØDECaster Duo. Это король. Запись подкастов уже не будет прежней.

Shure SM7B — перешёл на классику. Окончательно понял, что проблема не в микрофонах, а в моём голосе. Но всё равно приятно. Такой у меня и у Майкла Джексона (был).

В рюкзаках перешёл на роллтопы. Раньше посматривал на них с сомнением (где же мои 50 кармашков), но понял, что кроме ноутбука ношу только продукты. Зато если нужно, то влазит и куртка и вообще всё влазит. Взял для города Lefrik Roll и для поездок Pinqponq Block Medium.

Интернет

Интернет для меня схлопнулся до Телеграма, Гитхаба и инди-блогов. Спасибо каналам в Телеге, что вернули ощущение тёплой ламповости того, олдскульного веба. Хотя это конечно не веб, надо это понимать 🙂 Зато в Телеге не так стыдно не уметь писать.

Книги
Читал катастрофически мало. Ну очередной Пелевин, конечно, как без него. «Бронепароходы» Иванова не дочитаны (хотя очень хочется дочитать). Очередной занудный графоманский Стивенсон («Падение, или Додж в Аду») не дочитан. «Однажды в Голливуде» Тарантино — не дочитана. Что-то с этим надо делать.

Фильмы
Запомнил только «Всё, везде и сразу».

Ну вот вроде и всё. Прощай 2023, скучать не буду.

Напомню, что Storage Access API появилось только в Chrome 119. Ну и кто тут новый IE?
https://news.1rj.ru/str/mefody_dev/99

Притча про монорепы

Приходит молодой программист к седому опытному гуру и жалуется: «О умнейший из фронтендеров, у меня такая тяжелая жизнь, у меня 10 проектов, все связаны зависимостями, постоянно всё разъезжается везде... кошмар...»
Седой и строгий отвечает: «Собери все проекты в монорепу»
Программист: «Какую монорепу? Зачем? Как я ее в гитхаб положу!!!???»
Опытный: «Сделай монорепу»

Программист подумал-подумал, прикинул плюсы и минусы, пошел и сделал монорепу.
Через неделю приходит к опытному, тот его спрашивает «Ну, как жизнь»? Программист заламывает руки, кричит : «Еще хуже стало, эта монорепа чёртова, тулинг ужасный, все PR и ишью вперемешку, все тесты ломаются на каждый чих, всё тормозит... ужас!»
Умный почесал бороду и говорит: «Удали монорепу»
Программист страшно удивляется: «Что??? Зачем же я ее делал???"»
Опытный продолжает напирать: «Удали монорепу»
Программист подумал, подумал, пошел и удалил монорепу.

Через неделю возвращается программист к высокогрейдовому гуру и чуть не плачет от счастья: «Боже, друг, как же мне хорошо...»

А я напомню, что таких долгоживущих веток делать конечно же не надо. Хорошая ветка живёт день-два и уезжает в main (ну или в версию, если у вас одновременно несколько веток живёт).

И не забываем ребейзить и сквошить.

https://news.1rj.ru/str/mefody_dev/119

Хорошее замечание, что при таком подходе можно перегрузить QA. Ответ тут в том, что QA не должны быть узким местом. Разбираем монолиты на библиотеки и микросервисы, покрываем всё автотестами, подключаем ручное QA только в критичных местах, либо на релизную ветку.

Цель CI в том, чтобы код постоянно вливался и шарился между всеми. Чем раньше мы упрёмся в проблему, тем менее она болезненна. К сожалению, это не особо совместимо с ручным QA, либо придётся приставить по одному QA к каждому разработчику. И что должен этот QA делать с неготовой задачей, закрытой флагом от прода? Только проводить регрессы и смоуки. А с этим автоматика отлично справляется.

Прохладная история про LCP и SPA

Есть такая метрика в Core Web Vitals — Largest Contentful Paint (LCP). Устроена она достаточно банально — просто показывает время от старта запроса до рендера самого большого элемента на странице. В Яндексе измерение метрик скорости построено так, что мы не просто смотрим на каждую метрику в отдельности, у нас есть специальный индекс скорости, который высчитывается из совокупности Web Vitals.

И вот, на новогодних праздниках мы наблюдаем неплохой такой прирост этого индекса. А после праздников — падение назад. Казалось бы, логично, упала нагрузка, всё побежало быстрее. Но нет, рост рейтинга скорости начинается за неделю до нового года и падает он назад ровно через неделю после окончания праздников.

Начинаем вспоминать и понимаем, что включали на праздники новогоднюю анимацию в меню. Тааак. Вот оно! Наши страницы в сервисе — это чистые SPA, серверный рендер приносит только менюшку. Дальше включается лоадер, который тянет конфиги с бэка и рисует контент. И в нормальных условиях LCP возникает после ответа бэка. А когда мы добавили картинку в меню, то получили новый Большой Элемент, который начал рисоваться значительно раньше. LCP подросло и подтянуло за собой общую метрику.

Получается, что сделав чуть хуже для пользователя (контента стало больше), мы значительно выиграли в метриках. Вот такая мораль, не смотрите в голые цифры, внимательно ищите причины аномалий.

А мы будем думать, как добавить немного хорошего быстрого SSR.

Случайно наткнулся на относительно живой форк request в котором хотя бы латают уязвимости — @cypress/request

Хотя, конечно, пожелал бы команде сайпреса слазить уже с request и, тем более, request-promise, который вообще на bluebird.

Но если вам временно нужна затычка вместо оригинального request, то, наверное, сойдёт.

Как-то совсем без большого хайпа ребята запустились. Не то, что Bun, где из каждого утюга кричали.