LanguageTool

Подсмотрел в твиттере у Андрея Ситника, что он пользуется для проверки текстов сервисом LanguageTool. Сам пользуюсь пару недель, решил тоже с вами поделиться.

Что нравится:
- Проверяет на грамматические ошибки и частично пунктуацию текст на разных языках. В постах в этот блог опечатки мне помогал находить, пару запятых расставил за меня.
- Умеет в разные версии одного языка. То есть британский и американский английский исправляет по-разному, проверял.
- Говорят, что ничего не хранят на серверах, если пользоваться браузерным расширением или клавиатурой. Проверить не могу, конечно, но заботу о приватности моих данных ценю.
- Бесплатного аккаунта для моих нужд хватает выше крыши.
- Есть функция перефразирования текста с помощью AI 3 раза в день. Работает, но проверить, круче ли, чем ChatGPT, не смог, потому что всего 3 раза в день.

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

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

https://languagetool.org/

Корректная конфигурация для preconnect

В HTML можно добавлять различные подсказки браузеру, чтобы помогать ему доставлять ресурсы пользователю более эффективно. Одной из таких подсказок является следующая строчка:

<link rel=preconnect href=https://fonts.googleapis.com>

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

Гарри Робертс разбирает пример, когда неправильная настройка таких подсказок только вредит. На сайте BBC находит 4 такие подсказки, которые не работают, и объясняет, почему. Рекомендую прочитать вдумчиво, в статье нужно смотреть в графики. Но несколько коротких советов можно выделить:

1. preconnect к ресурсам, которые на самом деле не нужны в первые 5 секунд загрузки приложения, вредят. Chrome держит соединение всего 10 секунд, при этом количество соединений ограничено.

2. Домены в href нужно писать с протоколом. Если https, то https://. Незачем давать браузеру думать, искать редиректы и применять эвристики.

3. Атрибут crossorigin может быть не нужен. Проверить можно в DevTools, подсмотреть у запроса за ресурсом заголовок Sec-Fetch-Mode. Если там стоит значение cors, то тогда атрибут crossorigin можно и добавить.

4. Если на одном и том же домене нужны ресурсы и с CORS, и без, то нужно прописать два отдельных <link rel=preconnect>, один с crossorigin, второй без. Этот атрибут влияет на куки, то есть заголовки запроса, поэтому по сути получается два разных запроса.

5. При переносе статики на другие домены-поддомены не забывайте про <link rel=preconnect>. Скорее всего у вас есть какая-нибудь функция-хелпер, в которую редко смотрят, потому есть вероятность просыпать домены при рефакторинге. Выносите домены в общий конфиг либо собирайте самое нужное непосредственно при сборке приложения, помечая как-то критические ресурсы в исходном коде по месту их загрузки.

https://csswizardry.com/2023/12/correctly-configure-preconnections/

Видео с MinskCSS Meetup 11

Делюсь отдельными видео с нашего недавно прошедшего митапа:
- Как играть, побеждать и учиться в CSS Battle / Тимофей Чаптыков
- 5 лучших практик, чтобы предотвратить хаос в Tailwind CSS / Нина Торгунакова
- OpenSource. Зачем тебе это надо и как начать / Егор Левченко

Плейлист целиком: https://www.youtube.com/playlist?list=PL3uk4LxG9ZznGCBLJZhifqjQoPQ-7-6zn

Prettier-плагин для void-элементов

В HTML есть void-элементы, вы их часто встречаете: <br>, <img>, <input>, <link>, <source> и так далее (вот тут можно посмотреть полный список). Это такие элементы, у которых не может быть дочерних DOM-узлов, в том числе текстовых.

А ещё в современном HTML нет самозакрывающихся тегов. Вот цитата с MDN:

Self-closing tags (<tag />) do not exist in HTML.

То есть когда я пишу <br /> — это ошибка, которую браузер за мной чинит. У Джейка Арчибальда есть статья про бесполезные слеши в HTML-тегах, мы её как-то активно в подкасте обсуждали.

Беда в том, что prettier, которым я всё-таки активно пользуюсь в React-проектах, очень не очень работает с обычным HTML. Конкретно с void-элементами работает плохо: расставляет те самые бесполезные слеши, придумывает какие-то новые самозакрывающиеся элементы вроде <div /> и так далее.

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

https://github.com/awmottaz/prettier-plugin-void-html

Итоги 2023 года в книгах

В ленте многие подводят итоги года. Каждый делает это по-разному, я вот решил поделиться с вами прочитанными мной в 2023 году книгами, которые хочется посоветовать.

В прошлом году я ставил себе цель прочитать 20 книг, справился только с 12. В этом году решил здраво оценить свои возможности, поэтому поставил цель в 12 книг, а справился с 26. Вывод — я не умею оценивать свои возможности.

Итак, топ-5 из прочитанного за 2023 год по мнению доброжелюбного бородача:

5. Дарелл Хафф, «Как лгать при помощи статистики»
Я про неё писал уже в этом блоге. Хорошие примеры того, как можно красиво преподносить данные, чтобы они по-разному влияли на разную аудиторию. Как рисовать графики, которые как будто показывают правду, а на самом деле обманывают читателя. Как проводить статистические исследования, чтобы они давали нужный, а не правдивый результат. После этой книги любые графики теперь воспринимаю ещё скептичней, чем раньше.

4. Роберт Мартин, «Чистый Agile. Основы гибкости»
Классика. Дядя Боб рассказывает, как появился Agile, как с ним правильно работать и почему он на самом деле не противоречит многим другим методологиям.
Главное, чем книга расстроила: чтобы принципы начали работать, нужно всего лишь нанять команду крутых профессионалов. Делов-то. Но в целом принципы Agile в голове у меня книга устаканила хорошо, что-то попробовал применять в работе.

3. Ася Казанцева, «В интернете кто-то неправ!»
Работает ли гомеопатия, опасны ли ГМО, умнее ли мужчины женщин, вредно ли мясо для употребления в пищу. Кайф книги в том, что Ася Казанцева не навязывает своё субъективное мнение, а даёт ссылки на реальные научные исследования. И вообще призывает думать своей головой.

2. Рид Хастингс, Эрин Мейер, «Никаких правил. Уникальная культура Netflix»
Книга про успешный успех Netflix. Про то, как менялись процессы в компании, как выстроен найм. В целом неплохо объясняет, почему Netflix считается вполне себе желанным местом работы среди айтишников. Какие-то принципы можно попробовать перетащить к себе, они очень здравые. Какие-то не стыкуются с моими реалиями. В общем, читать нужно со здравой долей скепсиса, но полезного всё-таки в книге много.

1. Пирс Браун, «Алое восстание»
Художественная, Sci-Fi. Целая серия книг про будущее человечества, разделённого на касты. «Золотые» правят миром, опираясь на принципы древнеримской и древнегреческой империй, «алые» находятся внизу цепочки. Колонизация Солнечной системы, терраформирование, революции, «ваятели». Не всем подойдёт, это довольно жестокий боевик. Но я прочитал первые 3 книги саги взахлёб.

Вообще, за мной можно подглядывать на GoodReads. Я из тех, кто всем просмотренным фильмам ставит оценку на Кинопоиске, а всем прочитанным книгам — на GoodReads.

https://www.goodreads.com/user/year_in_books/2023/75780428

Запросы за спрятанными картинками

Когда вижу задачу по оптимизации первой загрузки веб-страницы, первым делом ищу на странице куски, которые можно не грузить в принципе, пока пользователь не окажется рядом с ними. Картинки за пределами первого экрана — идеальные кандидаты.

Стоян Стефанов провёл эксперимент с разными способами прятанья картинок:
1. Внутри <div style="visibility: hidden">.
2. Внутри <div style="display: none">.
3. Внутри закрытого <details>.
4. Пункты 1–3, но с loading=lazy.
5. Пункты 1–4, но внизу длинной страницы.

Результаты эксперимента:
- Если картинка без loading=lazy — она загрузится в любом случае. Во всех браузерах.
- <details> и display: none вместе с loading=lazy не загружают картинку, а вот visibility: hidden вместе с loading=lazy — загружает.
- Хотите что-то не загружать — либо loading=lazy, либо JS-решение.

В статье есть ссылка на демку, где можете сами посмотреть, как работают разные комбинации. И интересная старая техника с комментариями в HTML.

https://www.phpied.com/image-requests-in-hidden-content/

Выключение сторонних кук в Chrome

Если вы не следили за тем, что происходит в браузерах с 3rd-party куками, то сегодня, 4 января, Chrome запустил следующий этап по отключению сторонних кук на сайтах. Это значит, что у 1% пользователей Chrome такие куки будут выключены. Длиться тестирование будет целых полгода, в Q3 2024 планируют отключить 3rd-party куки совсем.

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

https://blog.google/products/chrome/privacy-sandbox-tracking-protection/

(Более) современный CSS Reset

Хоть я сам не сторонник «универсальных» библиотек для сброса браузерных стилей, часто что-нибудь в них подсматриваю, когда они обновляются.

Энди Белл делится обновлением своей версии стилей для сброса, которой он пользуется в личных и рабочих проектах. Сразу скажу, просто взять и скопировать — плохая идея, Энди про это в том числе пишет в статье. Но разобраться, зачем нужен каждый блок, точно будет полезно.

box-sizing: border-box — сам использую в своих проектах, хотя в статье справедливо написано, что в современных раскладках это часто уже не нужно.

text-size-adjust: none — чинит необычное поведение горизонтального поворота экрана в iOS.

ul[role='list'],
ol[role='list'] {
  list-style: none;
}

— интересная самомотивация расставлять role у списков, чтобы Safari не превращало нестилизованные списки в обычные блоки с текстом.

h1, h2, h3, h4 {
  text-wrap: balance;
}

— современно, сам в свои проекты добавляю постепенно.

a:not([class]) {
  text-decoration-skip-ink: auto;
}

— тоже как будто уже не нужно в большинстве браузеров, но для консистентности с остальными ссылками добавлял бы.

input, button, textarea, select {
  font: inherit;
}

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

:target {
  scroll-margin-block: 5ex;
}

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

В статье есть ещё несколько стилей. Почитайте, вдруг найдёте для себя что-то полезное.

https://piccalil.li/blog/a-more-modern-css-reset/

Блокирующие рендеринг скрипты и стили

В браузерах есть механизм блокирования рендеринга по каким-то событиям. Например, для синхронных скриптов браузер сначала их выполнит и только потом отдаст управление потоку отрисовки. Для стилевых таблиц работает так же. Это нужно, чтобы избегать FOUC — Flash of Unstyled Content.

Оказывается, в Chrome есть возможность задавать явно блокирование рендеринга для link и noscript. Причём на этот раз не мимо спецификации. Если быть точнее, то атрибут blocking=render рекомендует браузеру блокировать рендеринга, пока скрипт или другой ресурс не скачается и не выполнится, если он исполняемый. Например, можно писать вот так:

<noscript id="async-noscript" blocking="render" async src="async-noscript.js"></noscript>
<noscript>
  setTimeout(() => document.getElementById('async-noscript').blocking = '', 1500);
</noscript>

Такой код всё ещё загружает скрипт асинхронно, но при этом блокирует рендеринг первые 1.5 секунды загрузки приложения. Если соединение медленное, то возвращает дефолтный механизм с FOUC.

Полный текст эксплейнера: https://gist.github.com/xiaochengh/9404abbecdc3b45c0e9f3d5e99fbc65d

Спецификация: https://html.spec.whatwg.org/multipage/urls-and-fetching.html#blocking-attribute

Идея интересная, но не помню, чтобы про неё где-то рассказывали. Даже в release notes Chrome 105, где эту фичу, собственно, включили, ни слова. А ведь при помощи этого атрибута как будто можно хитро тюнить метрику CLS (сдвиг разметки) из Core Web Vitals. Аккуратно, конечно, чтобы не навредить пользователям ради метрик. То есть бездумно пихать этот атрибут где попало точно не стоит — в браузере всё-таки и так много встроенных эвристик, чтобы сделать пользователю хорошо, не нужно им мешать.

Кстати, судя по вот этому коммиту, в Firefox тоже этот атрибут скоро появится. От Safari их позицию узнаем уже только с релизом какого-нибудь Safari TP, заранее вряд ли.

https://chromestatus.com/feature/5452774595624960

О переводчиках и псевдоэлементах

Хорошее напоминание от Софии Валитовой, почему внутрь content псевдоэлементов не стоит вкладывать текст в принципе. Он про оформление, не про смыслы.

Кстати, у Софии есть канал, где она делится всяким интересным про CSS: https://news.1rj.ru/str/css_mind

https://ru.ariarzer.dev/2024/notes/pseudo-translation/

Генератор разметки

Брэд Вудс собрал визуальный редактор разметки на гридах и флексбоксах. Просто выбираете из готовых шаблонов подходящий и подстраиваете под себя. По сути как DevTools браузера, только с более удобным превью, полезными подсказками по CSS-свойствам и сразу правит как HTML, так и CSS.

Что-то серьёзное этим инструментом собрать будет сложно, но для генерации разметки перед тем, как садиться верстать страничку, полезно — экономит время. Автору можно написать с фичереквестом, если вам очень нужна какая-то функциональность.

https://layout.bradwoods.io/

Встраивание сторонних видео, примеров кода, слайдов и так далее

Наверняка вы добавляли видео с YouTube на свои страницы. Или в своём блоге добавляли демки с CodePen. Или внутри страницы показывали PDF. Это полезно, когда нужно дать пользователю быстро что-то сделать с iframe. Но очень часто пользователь ничего с этим iframe не делает, а трафик на загрузку содержимого уже потратил. Для меня такое особенно критично либо в роуминге, либо там, где интернет медленный.

Адриан Розелли делится способом встраивать любые iframe экономно для трафика пользователей:
1. Используем атрибут srcdoc. Этот атрибут внутри себя может содержать валидный заэнкоженный HTML, который будет показываться внутри iframe при начальной загрузке. Помещаем внутрь, например, превьюшку видео.
2. Внутри этого HTML должна быть ссылка на тот контент, который вы встраиваете. По сути это та же ссылка, которую вы обычно вставляете в атрибут src. Когда пользователь кликнет на ссылку, внутри айфрейма произойдёт переход на встраиваемый контент. То есть на старте трафик экономим, но по клику даём полезное действие.
3. Настраиваем атрибуты allow, allowfullscreen и sandbox, чтобы встраиваемый контент отображался так, как нам надо, а не как он хочет.
4. На всякий случай можем ещё поверх добавить loading=lazy, чтобы внутренности srcdoc не ходили за своими ресурсами (например, картинками), пока до айфрейма не доскроллили.
5. Оформляем всё это дело в веб-компонент (так у автора статьи). Или в компонент для используемого вами фреймворка.

Атрибут srcdoc не работает в Internet Explorer, но если вы его всё ещё поддерживаете, то айфреймы вряд ли самая большая ваша проблема.

В статье есть готовые примеры HTML для YouTube (кстати, с доменом youtube-nocookie.com, не знал про такой), CodePen, PDF. И код веб-компонента youtube-embed, который можно доработать под себя.

https://adrianroselli.com/2024/01/embed-slides-youtube-videos-and-more.html

«Эффективность не работает»

Видео выходного дня. Илья Якямсев честно и искренне рассказывает, почему всем в айти стоит думать о своём ментальном здоровье, как жить и что делать с рабочей депрессией, зачем думать о себе. Сложный, но жизнеутверждающий доклад, который за 5 лет не потерял в актуальности.

Осторожно, в видео есть мат, не включайте на всю громкость при детях :)

https://youtu.be/K6oZuB8_dU8?si=LvlbR22Jveyav5xI

Приведение численных типов в CSS

Наверняка вы сталкивались с тем, что в CSS нельзя делить, умножать, складывать и вычитать разные единицы измерения. То есть запись calc(100vw / 1px) не работает. А ведь так можно было бы получить количество пикселей в ширине вьюпорта, что можно было бы использовать для каких-нибудь интересных анимаций или других эффектов. Не ширину вьюпорта, а именно число пикселей, без единиц измерения.

Джейн Ори хакнула современные возможности CSS и всё-таки получила ширину вьюпорта числом.

1. Регистрируем CSS-переменную с типом <length>. Так браузер позволит использовать её в операциях с длиной, что пригодится нам дальше.

@property --100vw {
  syntax: "<length>";
  initial-value: 0px;
  inherits: false;
}

2. Используем обратные тригонометрические функции в CSS, а именно тангенс и арктангенс:

--width: calc(
  tan(atan2(var(--100vw), 1px))
);

Из школьного курса геометрии можно вспомнить, как работают тангенс и арктангенс. По сути здесь записано --100vw / 1px, зачем-то обёрнутое в вычисления. Но именно благодаря вычислениям в итоге внутри --width будет лежать число, а именно 100vw в пикселях. Если записать просто calc(var(--100vw) / 1px), вы получите ошибку.

В комментариях к статье Темани Афиф справедливо пишет, что сейчас в Chrome не учитывается тип делителя, что по сути является ошибкой браузерной реализации. То есть напишите там хоть 1px, хоть 1em, разницы нет. Но в будущем, когда тригонометрические функции починят, код с пикселями будет всё равно работать.

https://dev.to/janeori/css-type-casting-to-numeric-tanatan2-scalars-582j

Чеклист для дизайн-систем

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

Арда Карачизмели, Дмитрий Беляев и Стивен Багали собрали огромный чеклист, разбитый на 4 категории: дизайн-язык, основы, компоненты, поддержка. В блоке про компоненты по мне так супер-ценные напоминания, что нужно предусмотреть.

Если считаете, что чеклист неполный, можно законтрибьютить на гитхабе.

https://www.designsystemchecklist.com/

Вертикальное выравнивание через cap-height

Задача: выровнять иконку или картинку по центру относительно строки текста.

Кажется, всё просто: добавляем vertical-align: middle, коммитим, пушим, деплоим, профит. Но есть нюанс.

Дело в том, что vertical-align: middle выравнивает элемент относительно высоты строчной буквы x. Это так называемая x-height. И если текст у вас состоит только из строчных букв, то задача как будто решена, иконка действительно будет выровнена относительно текста. Но сомневаюсь, что у вас именно такой текст.

Рома Комаров показывает, как можно починить выравнивание для текстов с прописными буквами. В CSS не так давно появилась единица измерения cap, от английского capital — прописная. Это высота прописной буквы шрифта, cap-height. Прелесть в том, что браузер может сам высчитать эту высоту для шрифта, потому что он очень неплохо справляется с рендерингом текста. А это значит, что мы можем комбинировать x-height и cap-height, чтобы посчитать, какой отрицательный margin добавить иконке сверху: margin-top: calc(1ex - 1cap). В таком случае текст будет выровнен красиво по центру иконки или картинки.

Единица измерения cap появилась в Chrome 117, Safari 17.2 и Firefox 97. То есть пока ещё не самая высокая браузерная поддержка (чуть ниже 70% по данным caniuse на момент публикации поста). Для старых браузеров Рома предлагает фолбек на CSS-переменных, если у вас есть возможность достать параметры шрифта из самого шрифта. Пример кода — в статье. Ссылка на инструмент для извлечения метрик шрифта — тоже.

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

https://blog.kizu.dev/cap-height-align/

Идеального вьюпорта не существует

В Set Studio провели замеры на своих проектах, какого размера вьюпорт у пользователей. Собрали 120000 window.innerWidth и window.innerHeight. И оказалось, что уникальных размеров — 2300. Уникальный — это когда отличается или ширина, или высота, или оба измерения.

А теперь вспомните, сколько размеров у вас в условной Figma для ваших макетов, которые нужно сверстать. Хорошо, если 3: мобильный, планшетный, десктопный. Но чаще я видел всего 2 размера: совсем мелкий мобильный под какой-нибудь iPhone и большой для десктопов. Кстати, даже на том же iPhone есть как минимум 6 вьюпортов: Safari, WebView, превью сайта по долгому нажатию (бывший 3D Touch) и всё это при горизонтальном расположении экрана.

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

Кстати, на сайте можно найти полные данные про все 2300 уникальных вьюпорта, которые намайнили в Set Studio, если вам интересна более подробная статистика. Например, можно отранжировать по ширинам, чтобы понять, стоит ли тратить время на совсем уж мелкие экраны. Только не попадитесь в ловушку, перепутав причину и следствие: возможно, на ваш сайт не заходят с мелкими экранами, потому что он на них банально разваливается.

https://viewports.fyi/

Использование abbr с атрибутом noscript

В HTML можно пояснять аббревиатуры при помощи такого кода: <abbr noscript="National Aeronautics and Space Administration">NASA</abbr>. На странице покажется текст из содержимого тега abbr, а если навести на него мышку, то появится тултип с содержимым из атрибута noscript. Удобно же, правда?

Опустим тот факт, что системный тултип — ужасное решение, даже если он работает. Адриан Розелли проверил, как ведёт себя такая конструкция в разных браузерах и в разных операционных системах с точки зрения доступности с клавиатуры, на тач-устройствах, в голосовых ассистентах. И если коротко, то плохо. Подробности по ссылке.

Мораль: не используйте abbr. Чтобы он по-настоящему работал, всё равно придётся реализовывать собственную обёртку. А ещё лучше расшифровать аббревиатуру прямо в тексте. В книгах и журналах так делают сотни лет — и ничего, как-то люди эти тексты без курсора понимают. Если можно сделать текст понятнее без дополнительных действий — стоит это сделать.

https://adrianroselli.com/2024/01/using-abbr-element-with-noscript-attribute.html

Альтернатива live-server

Мне часто нужно запустить какую-нибудь html-страничку на мини-сервере, чтобы и айфреймы в ней работали нормально, и по локальной сети пошарить (с телефона открыть). И обычно я для этого использую npm-пакет live-server. Запускаешь npx live-server, ждёшь минуту скачивания зависимостей, профит. Или ставишь глобально, чтобы ждать минуту всего один раз.

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

Оба пакета, если что, давно не обновляются на github, но это не делает их устаревшими: свою работу выполняют отлично.

https://github.com/lukejacksonn/servor
https://github.com/tapio/live-server

CSS First. Когда JavaScript не нужен

Осенью на HolyJS читал доклад про то, что умеет современный CSS (и не только) и какие библиотеки на JS, которые мы скорее используем по привычке, чем осознанно, можно уже сейчас заменить на CSS. Делал упор на том, как доставлять меньше байтиков на клиент, но в конце задвинул философскую мысль.

Теперь можно посмотреть доклад на YouTube, не сдерживайте себя.

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

Стриминг HTML почти в любом порядке

Долго думал, чем мне может быть полезен декларативный Shadow DOM. Это такая конструкция, которая позволяет внутри template указать какой-то html, добавить этому шаблону атрибут shadowrootmode, всё это вместе со слотами. Вот пример кода:

<host-element>
  <template shadowrootmode="open">
    <slot></slot>
  </template>
  <h2>Light content</h2>
</host-element>

В примере контент из h2 передвинется внутрь слота, а само содержимое template окажется внутри Shadow Root элемента host-element.

Выглядит интересно, но я всё не понимал, как мне это дружить с фреймворками, которые уже есть в проектах. Фреймворки давно умеют в шаблоны, слоты сложнее в восприятии, чем JSX, да и внутрь Shadow Root прокинуть стили надо по-особенному.

Важная часть: Declarative Shadow DOM не нуждается в JavaScript. И в статье Крис Хейнс показывает, как это использовать.

1. Вам нужен сервер, который умеет стримить HTML. Таких много на любых языках. Стримить — это отдавать по частям, пропушивая на клиент некоторые кусочки, когда они уже готовы.

2. Для удобства Крис предлагает использовать шаблонизаторы, которые умеют в стриминг. Хотя на самом деле это совсем не обязательно, главное не ошибиться в том, когда какой кусок страницы отдаётся.

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

4. Тут же отдаём template с пустыми именованными слотами. В этот момент браузер поймёт, что ему нужно будет в слоты что-то вставить, как только они приедут в разметке.

5. Крутим-вертим бизнес-логику, медленно ходим в БД, наполняем слоты данными. Как только данные готовы — отдаём содержимое с указанием, в какой слот его нужно вставить, в HTML-потоке.

6. Отправляем остатки HTML, закрываем теги, досылаем маловажные скрипты.

Самая магия происходит в пунктах 4 и 5. Шаблон страницы мы отдаём сразу, а вот его содержимое — позже. То есть вообще не соблюдаем порядок внутри HTML. Но отрендерится страница в том порядке, в котором вам надо. И всё это без JS на клиенте, он не нужен.

Подобный подход используют многие крупные сервисы: отдают сразу шапку и кусок универсальных стилей, а потом доставляют всё остальное. И этим сервисам приходится сталкиваться с ограничением порядка доставки. Тот же Яндекс.Поиск работает аж в три этапа: шапка, вехний важный результат выдачи, всё остальное. Интересно посмотреть, поможет ли Declarative Shadow DOM здесь и в скорости доставки контента не потерять, и в удобстве разработки не ухудшиться.

Работает DSD в Chrome и Safari, в Firefox довезут в конце февраля, есть полифил.

https://lamplightdev.com/blog/2024/01/10/streaming-html-out-of-order-without-javanoscript/