Фронтенд 2024: тренды, CSS, доступность, браузерные API

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

https://youtu.be/9I1g06XSYZk

Typenoscript теперь и в Node.js?

В свежем выпуске мы затронули нашумевший PR. Что случилось то? А случилось такое, что в Node.js подвезли в экспериментальном режиме загрузчик для ts файлов. Работает он очень просто (правда просто). В ноду вшивается SWC в виде скомпиленного для WASM бинаря. TS файлы прогоняются через SWC и из них отстреливаются типы. Всё. Enum и namespace не работают (о счастье). Никакие транспиляции трансформации не производятся. Просто отстреливаются типы.

Есть ли проблемы? Конечно есть. Например, нужно писать расширение файлов в импортах. Потому что импорт так работает бай дизайн.

Почему это круто и важно? Потому что транспиляция раздражает. Потому что хочется всё иметь из коробки и без настроект. Накидать ts-файлик и запустить.

В общем, неожиданно и очень приятно.

Кастомное сообщение при подключении ESM через require

Если попытаться подключить ESM-пакет внутри CommonJS, Node.js выдаст вам ошибку. По ней, в принципе, достаточно понятно, что надо что-то поменять, но Зак Лезерман делится рецептом, как выдать кастомное сообщение, если ваш пакет уже не поддерживает CommonJS.

Для начала нужно попросить Node.js использовать разные файлы для разных способов импорта, внутри package.json пакета.

{
 "type": "module",
 "main": "./lib.js",
 "exports": {
  "import": "./lib.js",
  "require": "./libCommonJs.cjs"
 }
}

А затем внутри cjs-файла осознанно упасть.

try {
 module.exports = require("./lib.js");
} catch (e) {
 if(e.code === "ERR_REQUIRE_ESM") {
  throw new Error("Oops. It's not the module you are looking for.");
 }
 throw e;
}

Как верно замечает Зак, Node.js планирует скоро сделать так, чтобы внутри require можно было загружать и ESM-модули (с некоторыми ограничениями), так что лайфхак временный.

https://www.zachleat.com/web/future-friendly-esm/

Сборщик мусора и замыкания

Джейк Арчибальд делится интересным кейсом, в котором неожиданно в JavaScript утекает память.

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);

  (() => {
    console.log(bigArrayBuffer.byteLength);
  })();

  globalThis.innerFunc = () => {
    console.log('hello');
  };
}

demo();

Несмотря на то, что innerFunc никак не связана с bigArrayBuffer, bigArrayBuffer не удаляется из памяти посе выполнения этого кода.

Подробнее в статье.

https://jakearchibald.com/2024/garbage-collection-and-closures/

Причины, почему JavaScript может не работать

Иногда приходится доказывать другим людям, что полностью полагаться на работающий JavaScript на сайтах нельзя. Энди Белл собрал небольшой список, на который можно опираться для аргументации.

1. Браузерное расширение может сломать JS на сайте. Сам с таким сталкивался, когда блокировщики рекламы творили дичь.
2. Политики безопасности (например, в компании), которые тупо вырубают некоторые домены или расширения файлов.
3. Блокировка CDN, например, потому что РКН или другие «регуляторы».
4. Скрипт не загрузился, потому что пользователь в метро.
5. Банальная ошибка в JS-коде, которая всё ломает.
6. Opera Mini.
7. «Умный» инкогнито-режим в Safari, который иногда сам решает отключить некоторые скрипты.
8. У пользователя слабое устройство, которому не хватает памяти обработать ваш JS.
9. Пользователь осознанно выключил JS, чтобы за ним не следили.

Это не значит, что надо делать сайты, которые работают без JS полностью. В современной разработке такое скорее нереально, если это не простой лендинг. Но как минимум стоит продумать, как будет выглядеть ваш сайт, если JS не загрузится и не выполнится. Например, выводить какую-то плашку с инструкцией для пользователя, что делать в таком случае.

https://piccalil.li/blog/a-handful-of-reasons-javanoscript-wont-be-available/

MinskCSS Meetup #12

Сегодня вечером проводим очередной онлайн-митап для фронтендеров, где обсудим с классными спикерами всякое интересное:

- Алексей Назаренко объяснит особенности Shadow DOM, связанные с изоляцией и стилями.

- Глафира Жур расскажет, что есть полезного в мире AI для accessibility.

- Юлия Миоцен покажет, как моделировать и анимировать настоящего 3D-персонажа на CSS.

Программа митапа: https://telegra.ph/MinskCSS-Meetup-12-07-29
Трансляция на YouTube: https://www.youtube.com/watch?v=-s7s_IB2egc

Снова никакой регистрации. Просто приходите в 19:00 по минскому времени. Всех ждём 🙂

Подкаст «Гости из IT». Олимпиадное программирование

Сходил в гости в подкаст с Антоном Комоловым «Гости из IT», где вместе с тренером чемпионов мира ICPC Михаилом Густокашиным обсудили с ведущими подкаста, что такое олимпиадное программирование, полезно ли оно в работе, даёт ли это какие-то преимущества в трудоустройстве и может ли ИИ победить чемпиона мира по программированию.

Мало кто знает, но в школе я занимался олимпиадным программированием, доходил до областного этапа олимпиады по информатике, постоянно брал там дипломы II степени. А в университете мне повезло быть в рабочей группе организаторов первых чемпионатов по программированию BSUIR Open, который до сих пор пользуется уважением в олимпиадном сообществе. Ну а сейчас я руковожу сервисами, которые помогают проводить контесты и соревнования. Было приятно поностальгировать.

https://podcast.ru/e/599XsTl4qNW

Официальная поддержка Firefox в Puppeteer

Для автоматизации тестирования в браузере всё чаще вместо Selenium используют Playwright или Puppeteer. Удобно, когда можно поднять реальный браузер в «безголовом» режиме и тестировать страницу ровно такую, какую «видит» пользователь.

Чисто субъективно мне всегда по функциям и обилию API больше нравился Puppeteer. В нём как минимум есть классная возможность генерировать PDF с большим количеством настроек. Но при этом по сути Puppeteer всегда был под капотом Chrome. А мне важна кроссбраузерность. У пользователей Firefox сайт тоже должен работать.

Начиная с Puppeteer 23 тестировать кроссбраузерно станет проще, там появляется официальная поддержка Firefox. Не все API работают, список можно посмотреть в статье, но большую часть потребностей закрывает.

https://hacks.mozilla.org/2024/08/puppeteer-support-for-firefox/

Как Google обрабатывает JavaScript во время индексации

Есть несколько мифов по поводу того, как Google индексирует SPA-приложения. Например, что боты-краулеры не умеют в JavaScript совсем. Или что для обхода сайтов Google использует древние версии Chrome. И другие.

Беда в том, что у Google нет ни одной полной странички с документацией, как именно поисковик обходит сайты и как краулеры эти самые сайты загружают, обрабатывают и индексируют. И даже та документация, что есть, не даёт полного понимания, что сделать, чтобы бот точно всё распарсил правильно. Оно и понятно: зная точную механику, можно стать повелителем SEO.

Vercel вместе с MERJ провели эксперимент, обложив 100000 запросов от гуглобота разными замерами. Как именно они это сделали, лучше посмотреть в статье, есть даже примеры кода. И получили они такие знания:

1. Googlebot отлично справляется с любым JavaScript. Синхронным, асинхронным, из фреймворков.

2. Рендерит он только страницы с HTTP-кодами 200 и 304. Остальные коды не рендерит в принципе. Поэтому не забывайте отправлять корректные коды ошибок на страницы, это влияет на позиции в выдаче.

3. Googlebot умеет находить ссылки внутри JavaScript, не только в HTML. Причём смотрит он именно на готовые ссылки, не encoded URL.

4. Наличие sitemap.xml значительно ускоряет обработку ботом, что изменилось на сайте. То есть если вы боретесь за актуальность ссылок в поисковой выдаче, на sitemap.xml надо обратить внимание в первую очередь.

5. Метатег noindex работает. Но только если он пришёл в HTML, а не вставился при помощи JavaScript уже на клиенте. Если вы прячете странички от индексации уже на клиенте — это не работает, нужно уносить логику на сервер.

6. Тяжёлые страницы с большим количеством JavaScript краулятся медленнее, могут долго висеть в очереди. Поэтому перфоманс страницы всё-таки влияет на SEO.

7. Если в robots.txt запретить нечаянно доступ к папкам со скриптами и другими ассетами, они не загрузятся. Проверьте свой robots.txt, нет ли там чего-нибудь лишнего.

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

https://vercel.com/blog/how-google-handles-javanoscript-throughout-the-indexing-process

Генератор пружинистого изинга

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

Анимации сделаны на функции linear(), так что не забудьте убедиться, что ваша браузерная поддержка в проекте позволяет ими пользоваться.

https://www.kvin.me/css-springs

Браузерное расширение Resource Override для фронтендеров

Иногда возникает нужда переопределить какой-то ресурс для дебага. Например, сервер возвращает сломанный JSON, а хочется протестировать починенный, не делая релиз. Или вы сделали фикс библиотеки, которая лежит на CDN, и хотите посмотреть, как она себя ведёт в проекте.

В Chrome и Safari есть возможность подменять файлы на уровне DevTools. Но динамику так не протестировать, к тому же каждый отдельный файл подменять, когда хочется подменить целую папку, муторно.

Марио Хаманн делится браузерным расширением, которое работает как прокси. Если вам нужно подменить обращения к каким-нибудь ресурсам по маске, оно умеет подменять на другие ресурсы с сохранением этой самой маски.

А ещё при помощи этого расширения можно «патчить» чужие сайты в Интернете.

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

https://mariohamann.com/resource-override-for-frontend-development

Видео с альфа-прозрачностью на веб-страницах

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

- AVIF не подходит. Он умеет в анимации и прозрачность, под капотом использует видеокодек AV1, но Safari прозрачность не поддерживает, а использовать img для воспроизведения видео в принципе не самый правильный подход, потому что браузеры обрабатывают анимации по-другому.

- VP9 и HEVC уже лучше. Но на момент написания статьи в Chrome для Android был баг с прозрачностью, а в Firefox на Android часто останавливается воспроизведение.

- Собрать видео двойной высоты, где верхняя половина — видео, а нижняя половина — маска для видео, а потом при помощи WebGL маскировать одно другим. Вот такой подход у Джейка сработал везде, где нужно.

Чтобы вам не писать шейдеры самостоятельно, Джейк собрал веб-компонент, который берёт рендеринг на себя. И в статье приложил инструкцию, какие настройки применять в ffmpeg для каждого из форматов.

https://jakearchibald.com/2024/video-with-transparency/

Project manager, program manager и product manager — зоны ответственности, навыки и образование

Видео выходного дня. Юлия Белозёрова объясняет, чем отличается Project Manager от Program Manager и Product Manager, и делится советами, на что стоит сделать упор, если хотите делать карьеру в одной из веток.

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

https://www.youtube.com/watch?v=HapZUWiWvWA

State of CSS 2024

У меня в планах на вечер сегодня пройти опрос State of CSS. Стараюсь делать это каждый год, чтобы своим мнением влиять на приоритеты браузеров. А браузерные деврелы результаты этих опросов точно используют, официально про это упоминают. И разработчики спецификаций на результаты смотрят. Так что всё не зря.

Для тех, кто никогда не участвовал в State of CSS: это такой опрос, где много вопросов про то, какие фичи вы знаете, какие нравятся, чего не хватает в CSS, какие фреймворки помогают или мешают работать и так далее.

Присоединяйтесь.

https://survey.devographics.com/en-US/survey/state-of-css/2024

Частые заблуждения про оптимизацию LCP

Если вы работаете с оптимизацией перфоманса страниц, то метрика LCP (Largest Contentful Paint) точно попадалась вам на глаза. Это время от начала загрузки страницы до отрисовки самого большого блока во вьюпорте. Таким блоком может быть и текст, но часто это какая-то картинка, привлекающая внимание. И так как LCP является важной составляющей Core Web Vitals, приходится эту метрику оптимизировать.

В статье Брендана Кенни разбирается миф о том, что для оптимизации LCP достаточно сделать картинки меньше по размеру: использовать современные форматы изображений, сжимать картинки.

На самом деле до отрисовки картинки есть ещё несколько этапов, которые можно посчитать в секундах: время до первого байта, время на задержку запроса за ресурсом, время загрузки ресурса и время рендеринга. И, как показывает статистика, на 75-м перцентиле исследованных сайтов с высокими значениями LCP время на загрузку составляет меньше 10% от всего времени LCP. Да, эти 10% тоже важно оптимизировать, но как будто стоит обратить внимание на остальные этапы.

Брендан советует обращать внимание на следующие этапы:
- Оптимизировать TTFB, время до первого байта. Если у вас нет CDN, а у пользователя слабая сеть, то на TTFB может уходить около 2.5 секунд (на исследованных сайтах), а это очень много.
- Сделать так, чтобы важный ресурс запрашивался заранее. Подсказать браузеру через <link rel="preload">, например. И пока парсер реально дойдёт до картинки в коде и дождётся выполнения всех синхронных JS-операций, за это время часть полезной работы уже будет проделана.
- Исследовать задержки рендеринга. Возможно, где-то у вас есть кусок JS, который тормозит запрос за картинкой или отрисовку во вьюпорте. Этот совет в том числе и другие метрики улучшит.

Больше полезных чисел — по ссылке.

https://web.dev/blog/common-misconceptions-lcp

Есть ли будущее у Node.js? / Андрей Мелихов и Кирилл Мокевнин

Видео выходного дня. Андрей и Кирилл рассуждают, какое место у Node.js в разработческих задачах, почему какие-то фреймворки взлетают, а какие-то умирают, зачем Node.js-разработчики каждые пару лет радостно бегут всё переписывать, помогает ли TypeScript и какое у этого всего будущее.

https://youtu.be/98qu3CqRNb8

Базовые комбинации клавиш для ссылок с фокусом

Эрик Бейли столкнулся с необходимостью создания синтетических ссылок: ведут себя как нативные ссылки, но нативными ссылками не являются. И много усилий потратил на то, чтобы исследовать, как реагируют сфокусированные ссылки на разные комбинации клавиш: Shift + Enter, Function + Enter, Control + Enter, Option + Enter, Alt + Enter, Command + Enter.

Важные выводы:
- Cmd и Ctrl — не одно и то же. Alt и Option — тоже. Потому что разные операционные системы воспринимают их по-разному, чаще игнорируя кнопки от конкурирующих производителей. В коде их нужно разделять.
- На мобильных ОС браузеры верят в существование клавиатур, поэтому поддерживают сокращения тоже. На мобилке можно подключать внешнюю клавиатуру.
- Такие сокращения — важные пользовательские привычки. Поэтому если уж делаете синтетические ссылки, постарайтесь не сломать нативное поведение.
- Нативное поведение проще всего реализовать, используя нативные элементы.

https://ericwbailey.website/published/basic-keyboard-shortcut-support-for-focused-links/

Как быстро конвертировать Chrome-расширение в Safari-расширение

Нина Торгунакова показывает, как из готового расширения для Chrome реализовать расширение для Safari. Про подготовку расширения для Chrome было здесь. Большую часть работы берёт на себя встроенный в XCode конвертер, но так как Safari не умеет многих вещей, которые работают в расширениях для Chrome, местами нужно пописать код на Swift.

Бонусом есть инструкция, как подготовить расширение для публикации в App Store.

https://evilmartians.com/chronicles/how-to-quickly-and-weightlessly-convert-chrome-extensions-to-safari

Пробелы в HTML сломаны

Дуглас Паркер решил разобраться, как работают пробелы в HTML. Да, вам не показалось. Он исследовал поведение одного символа в документах. Если быть честнее, то двух, ещё неразрывный   исследовал.

Если вы не знали, то в HTML действительно есть механизм схлопывания пробельных символов, в котором много разных нюансов. Например, пробелы бывают значимыми и незначимыми. Если пробел незначимый, то есть высокий шанс, что в отрендеренном варианте его не станет. Например, если вы вставите пробел в самое начало содержимого тега, то он исчезнет. А вот пробел в конце тега, когда после тега есть ещё какой-нибудь текст, уже значение имеет, поэтому можно часто встретить в интернете ссылки с подчёркиванием пробела в конце.

А ещё при помощи CSS можно сделать так, чтобы пробелы начали либо учитываться все сразу, либо только переносы строк, либо ещё как-то.

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

Дуглас подсветил интересную проблему. По сути у нас сейчас нет способа задать неубираемый пробел явно спецсимволом. Мы можем задать между словами обычный пробел — но его судьба очень шаткая, сильно зависит от того, блочный или инлайновый контекст, что написано в CSS, есть ли вокруг флекс-контейнер и так далее. У нас есть неразрывный пробел &nbsp, который одновременно не даёт пробел убрать (потому что это особенный пробел), но при этом ещё и не даёт разделить слова между собой. Но если мы хотим дать возможность переносить слова, но не давать их слепить браузеру, когда перенос не нужен — такого символа нет. При этом в статье есть примеры вроде CMS и прочих мест, где такие пробелы вставить иногда нужно.

Ещё одна интересная мысль: prettier и прочие форматтеры могут ломать вёрстку. Просто потому, что наличие или отсутствие пробела — это не прихоть для форматирования кода, а вполне себе необходимость для корректной вёрстки. У prettier есть настройка для уважительного отношения к пробелам от автора, но по умолчанию она включена в нестрогий режим, а силу дефолта не стоит недооценивать. Теперь хоть буду понимать, почему иногда ломается вёрстка, а не просто убирать пробел и радоваться, что каким-то чудом заработало.

В конце автор предлагает совсем уж безумную идею: переписать формат HTML, чтобы как в языках программирования появилась сущность «строка», то есть использовать тройные кавычки или ещё какие-то отделители от другой разметки, которые бы давали парсеру понять, что эту строку надо обрабатывать по-особенному. Но тут я немножко выпал в осадок, идея кажется слишком безумной, чтобы когда-нибудь такое появилось в реальности. Но кто знает. У нас же не просто так существует doctype у документов, теоретически такой режим возможен.

https://blog.dwac.dev/posts/html-whitespace/

Насколько мой фронтенд плох?

Видео выходного дня. Семён Левенсон объясняет разницу между рефакторингом и реинжинирингом, предлагает плохометры для оценки качества кодовой базы (на основе идеи Ильи Климова) и показывает несколько примеров, как такие плохометры автоматически собирать.

https://youtube.com/watch?v=T43jrG1ewTc