У меня есть ежегодная традиция делать короткие (30-60 секунд) новогодние видосы в After Effects. Видосы довольно кринжовые, но мне кажется, хорошо создают новогоднее настроение. :)

Видос на этот новый год уже готов и дожидается премьеры, а пока можете посмотреть видосы прошлых лет, которые я собрал в плейлист, а также запись вышеупомянутого доклада про Motion-дизайн с Frontend Conf, который в том числе посвящён After Effects.

В поисках рантайма для Typescript

В подавляющем большинстве случаев я стараюсь держать любой код в проекте поддерживаемым и документированным, поэтому даже всякие утилитарные скрипты для сборки или кодогенерации пишу на Typescript.

Долгое время для запуска таких скриптов я использовал ts-node, который считал стандартом де-факто для решения этой задачи, но недавно наткнулся на утилиту tsx.

На поиск нового решения меня сподвигла кривая поддержка ESM в ts-node (в Node.js 18 у меня не завелось). С tsx тот же самый код запустился без лишних танцев с бубном. В качестве приятного бонуса я получил watch-mode из коробки.

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

Автор tsx также сделал репозиторий со сравнением различных инструментов для запуска Typescript-кода.

Приходится ли вам запускать Typescript-код без бандлера? Какие инструменты вы для этого используете?

8 июня расскажу на Я ❤️ Фронтенд об инструменте, который используется в нашей компании для сборки микрофронтендов.

В программе:
- ткнём палкой в давным давно мёртвый Create React App
- проследим мотивацию, историю создания, развития и внедрения на ~60 проектов нашего инструментария для сборки
- переймём лучший опыт похожих проектов
- конечно же не забудем проявить заботу к коллегам

Во время моего выступления на Я 💛 Фронтенд с презентацией произошли небольшие проблемки (абсолютно всё, что в ней могло сломаться, сломалось), но, полагаю, ценность доклада от этого не убавилась. Хочу сказать всем спасибо за обратную связь и действительно хорошие и интересные вопросы.

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

Если у вас остались неотвеченные вопросы, с радостью отвечу на них в комментариях😉

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

Пришлось покостылить даже тут)

В бете Safari 18 заявлена долгожданная (по крайней мере мной) поддержка View Transitions API, который уже довольно давно поддерживается в Chromium-based бразуерах и по такому поводу я решил сделать небольшой редизайн главной страницы своего блога.

На мой взгляд эта фича вносит огромный вклад в то, чтобы Web-приложения ощущались как нативные и при этом не требует особых вложений с точки зрения разработки (особенно при использовании Astro).

Если у вас есть классные примеры использования этого API, кидайте в комментарии)

Для полноты картины упомяну ещё одну проблему, которая мешает полноценному использованию View Transitions — задваивание анимаций перехода при свайпе в Safari на iOs.

С этой проблемой пытались бороться решениями разной степени костыльности ещё во времена актуальности React Transition Group, но с приходом View Transitions эта проблема заиграла новыми красками и я очень надеюсь, что в ближайших релизах Safari с ней что-нибудь сделают.

Эволюция микрофронтендов

На недавнем Frontend Conf я рассказывал о текущем состоянии микрофронтов. Постарался рассказать максимально доступным языком, при этом не теряя важных концептуальных деталей, и проиллюстрировать наглядными схемами, поэтому на мой взгляд доклад будет полезен даже тем, кто уже посмотрел множество других докладов про микрофронты.

Системы эффектов

Недавно послушал выпуск Подлодки про "Системы эффектов в языках программирования" и решил поделиться некоторыми рандомными рассуждениями на эту тему.

"Окраска" функций

"Окраской" функций называется некоторая декларация эффектов, содержащихся в функции.

В JavaScript есть 2 варианта "окраски" функций:

- async — обозначает, что функция асинхронная и позволяет использовать внутри неё оператор await
- * — обозначает, что функция является генератором и позволяет использовать внутри неё оператор yield

Fun fact: эти 2 варианта можно скомбинировать, чтобы получить AsyncIterator, который можно перебирать оператором for await...of.

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

Обработка исключений

В Java есть оператор throws, позволяющий "окрасить" функцию эффектом выброса определённого типа исключения и на этапе сборки удостовериться, что эти исключения обработаны.

JavaScript/TypeScript не позволяет типизировать исключения (разве что задокументировать их с помощью JSDoc или TSDoc), но теоретически эту проблему можно решить знаменитой монадой Either.

Чистота функций

Бандлеры используют аннотацию /*#__PURE__*/, которая обозначает отсутствие побочных эффектов в функции, для более эффективного тришейкинга (упомянал об этом в своём докладе).

В самом JavaScript нет языкового средства для выражения чистоты функции — то есть отсутствия в ней эффектов, хотя было бы классно использовать это знание, например, для исполнения кода во время сборки (как, например, c babel-plugin-macros).

Пранк, который вышел из под контроля

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

В процессе исследования проблемы выяснилось, что @vitejs/plugin-legacy инлайнит CSS в JS-бандл с легаси сборкой, что приводит к тому, что шрифты гарантированно будут загружены после JS и скачок неизбежен.

Отказываться от plugin-legacy или возиться со сборкой было лень, поэтому я начал раздумывать над каким-то надёжным решением кроме инлайна шрифтов в base64 (чтобы они загружались синхронно).

По дороге из офиса домой я по традиции решил послушать выпуск веб-стандартов. Мне сразу показался подозрительным состав ведущих в этом выпуске, но я не придал этому особого значения. По счастливой случайности одной из обсуждаемых тем была загрузка шрифтов: обсуждали тот самый вариант с инлайном в base64, а так же некий новый Font Face API (почему-то я самостоятельно не догадался загуглить его), который ещё мало где поддерживается.

Придя домой, я наконец обратил внимание на дату публикации выпуска: он был датирован 1 апреля...

Это был выпуск веб-стандартов 10-лентней давности, а значит тот самый Font Face API уже давным давно "Baseline Widely Awailable" и ничто не мешает мне его использовать, чтобы управлять последовательностью загрузки ресурсов приложения:

const font = new FontFace(
 "my-font", "url(my-font.woff)",
 {
  style: "normal",
  weight: "400",
  stretch: "condensed",
 }
);

Promise.all([
 import("./app.js"),
 font.load(),
]).then(([app]) => {
 document.fonts.add(font);
 app.init();
});

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

Таким образом выпуск веб-стандартов прошёл проверку временем и внезапно оказался полезен даже спустя 10 лет после выхода.