Если сделано правильно, то не будет. Зум просто пропорционально увеличивает всю страницу. С адаптивностью (а это стандарт де-факто), страница просто скатится в лэйаут для мобилок. Но это на экстремальных значениях зума, типа 400%. Я увеличиваю на 125-150 и в большинстве случаев всё нормально.
Если брать стандарт WCAG, то там есть требование, чтобы страница не разваливалась при 200% зуме. Удовлетворить критерию не сложно, но это делает функцию зума полезной и ничего не ломает.
Ну и для таких нюансов давно придуманы "пользовательские таблицы стилей"
Пользовательские таблицы стилей, всё же, не для рядового пользователя. Не каждый напишет CSS и разберётся, как его подключить к странице. А из браузеров давно выпилили эту возможность, осталась только в виде расширений.
Но это всё и не нужно, потому что высококонтрастные темы и прочее есть в настройках операционной системы. И в CSS с помощью медиа-запросов это можно отслеживать. Автор в статье как раз и пишет о нюансах в этих режимах.
Их поддержка, повторюсь, не такая сложная, хотя и соглашусь, что иногда выглядит как хаки. Но эти мелочи делают ненужными пользовательские таблицы стилей.
Но, как я говорил, Интернет для всех, поэтому в нём должно найтись место и пользователям зума, и тем, кто считает это ненужной функцией.
В этом и заключается суть универсального доступа. Дядя Тим завещал, что веб должен быть для всех. Для тех, кто не любит 100500 вкладок и не пользуется браузерным зумом, и для тех, кто им пользуется.
У меня с рождения не лучшее зрение, поэтому некоторые страницы я немного увеличиваю браузерным зумом. А ещё у людей с возрастом падает зрение, но люди всё равно продолжают пользоваться Интернетом.
Хороший интерфейс без проблем удовлетворяет и тем, и другим. И ничего особого для этого делать не надо.
Не знаю ни одного реального сайта за пределами домена w3.org, где это бы использовалось
Это, отнюдь, не значит, что их нет. Я пункты из статьи стараюсь применять на практике. В моём окружении хватает людей, которые тоже стараются их применять. Также я работаю с крупным SaaS вендором, у которого есть требования и подобные решения есть в кодовой базе их продуктов.
Очень доступно. Что под капотом у AccessibleButton? Пачка <div>-ов с tabindex, onclick, role и прочим? aria-label зачем-то переопределяет встроенный текст кнопки, что как минимум ломает программы голосового управления и нарушает несколько критериев WCAG. Вот такая вот «улучшенная доступность» в UI-библиотеках React.
Вот вы говорите, что вам всё равно на качество сайта, миллисекунды загрузки (не миллисекунды), нежелание заморачиваться и так далее. Но далее говорите о продажах, бизнесе и продукте. Я вижу в этом противоречие.
Продавать продукт нужно кому-то, то есть пользователям. Лэндинг продукта как раз и создаётся, чтобы рассказать пользователям о продукте и подвести их к целевому действию.
То есть уже тут неплохо бы, чтобы у потенциальных клиентов сайт загрузился и работал как можно быстрее. Особенно в мире мобильных устройств и нестабильных беспроводных сетей.
Также неплохо, чтобы пользователи вообще на сайт попадали. Понимаю, что источники трафика могут быть разными. Но ведь органика тоже хорошо. Значит, поисковики и AI-боты должны быстро находить и индексировать сайт. То есть нужно банальное SEO.
Известно, что скорость загрузки и поведенческие факторы влияют на SEO и позицию в выдаче. Известно, что гугл индексирует сайты с большим количеством JS в несколько раз дольше статики и с определёнными квотами из-за запуска headless-браузера.
Таким образом, сайт в достаточно конкурентной нише (ботов много кто делает) может выиграть в плане SEO, удобства для пользователей и скорости загрузки. А это влияет на бизнес-показатели.
Не стал бы гугл столько вкладываться в Web Vitals, Lighthouse и прочие инструменты, если бы это не влияло на время нахождения пользователей на сайтах и другие бизнес-метрики.
Так что хорошо сделанный и производительный сайт может лучше продавать при прочих равных.
В этом и суть. Аппликейшин, то есть приложение с какой-то логикой, высокой степенью интерактивности, обработкой данных на клиенте, длительными сеансами взаимодействия. А у вас сайт из нескольких страниц, на которых обычный текст, изображения, ссылки, иконки, несколько аккордеонов, формы и бургер-меню.
Первый рендеринг главной страницы из пяти секций на десктопе, в Chrome, на проводном соединении произошёл на отметке 2.9с и потребовал 19 запросов JS общим объёмом около 1.1мб. По мне так это неоправданно много. Всё из-за того, что так работает выбранный вами инструментарий и его не рационально использовать для такой задачи.
Я посмотрел страницы сайта и не увидел там чего-то, для чего вообще нужен JS. То есть сайт с точно таким же внешним видом, адаптивностью и функциями можно сделать без клиентского JS, роутеров, контекстов, вебпаков и прочего. Разве что десяток-другой строк JS для обработки форм и бургер-меню.
В моём понимании это должен быть обычный статический сайт, а в качестве инструмента для разработки, если хочется фреймворк, я бы предложил Astro, Eleventy, Hugo и другие SSG с упором на zero JS by default. ИИ бы также помог сгенерировать сайт на этих технологиях. Или, если нужно было быстро и без написания кода, то какие-нибудь готовые шаблоны.
Отсюда и вопрос от izibrizi2 и меня насчёт целесообразности, как вы писали, "сделать полноценный SPA-сайт" и выбора технологического стека для разработки контентного сайта.
Показанный код — это встроенные методы работы с DOM, которые одинаковы для всех браузеров, документированы и описаны в стандартах. Автор не разработал ничего своего, чтобы назвать это фреймворком. Он лишь показал пример разработки средствами стандартного DOM API.
Фреймворки поверх этих API есть и обычно они прячут многое под капот, упрощая написание кода и снижая количество ручной работы и вызовов DOM. Они вполне используются в продакшине очень даже крупными компаниями.
<template> — не просто строка, а экземпляр DocumentFragment. То есть кусок DOM, который браузер распарсил и собрал из строки. И с этим фрагментом DOM можно работать через DOM API и потом вставить в нужное место или многократно клонировать.
С <div style="display:none"> проблема в том, что если внутри есть ресурсы, <script>, <style>, <link> — они будет загружаться/выполняться, чего от шаблона обычно не хочется. Фишка <template> как раз в том, что внутри него всё инертно. Такое можно получить, разве что, от <script>, но в нём всё будет строкой.
Пользовательские элементы построены на основе стандартного DOM API браузера. Вызовы методов жизненного цикла пользовательского элемента, по сути, биндинги к подкапотному API на C++. Браузер это и так делает при построении DOM, но разработчикам даётся возможность немного влезть в этот процесс и выполнить какой-то JS.
Поэтому технически пользовательскте элементы медленнее, чем простой HTML/CSS. И требуют загрузки, парсинга и выполнения JS-кода. Но разница не существенная. Остальное зависит от того, что происходит в методах жизненного цикла. Если там сетевые запросы на мегабайты данных или циклы на сотни тысяч итераций, то это будет медленно.
А может объяснить в чем прикол экспортировать функцию customElements.define потом дожидаться domload и только потом регистрировать компоненты?
Например для ленивой инициализации. Скажем, есть компонент, который изначально не нужен и инициируется только при каком-то пользовательском действии. Но вообще вкусовщина автора.
По воводу DOMContentLoaded, предполагаю, чтобы не грузить основной поток выполнением лишнего JS и работой с DOM, которая возникает при инициализации пользовательских элементов. То есть сначала даём браузеру спокойно пропарсить разметку, загрузить стили и другие ресурсы, а потом, когда он построил DOM, уже выполнять скрипты. Но тоже похоже на вкусовщину автора.
Эта статья — пример того, как делать не стоит. Если вы новичок и читаете эту статью, то я не рекомендую вам делать как там написано.
Сама идея «меню без JS» плоха. Чем не угодил JS? Не надо выдумывать хаки на чекбоксах, а потом обмазывать всё ARIA, ради того, чтобы не писать 20 строчек JS. А если прям очень хочется без JS, есть более современные и практичные решения: <details> + <summary>, Popover. Хотя и это не повод городить огород «без JS».
Целый раздел посвятили доступности и её важности, но меню доступным так и не сделали. Добавили две ненужные роли banner и navigation, которые по умолчанию встроены у <header> и <nav>. Зато не добавили самое главное для раскрываемого меню — кнопку, передающую связь и состояние раскрытия aria-expanded. Для этого ведь JS нужен...
А ещё на видео-демонстрациях меню классно раскрывается по :hover. А что на счёт мобильных устройств с тач-экранами? Там нет :hover. Таким меню будет неудобно пользоваться на мобильных. И ещё куча моментов, которые не буду расписывать.
Для меня показатель. Я придерживаюсь мнения, что на странице должно быть как можно меньше JS.
Из примеров - Svelte
Согласен. Острова интерактивности можно сделать разными способами и не обязательно веб-компонентами. Svelte - Хороший пример инструмента для такой задачи.
При этом вы не сталкиваетесь с ограничениями веб-компонентов - глобальной областью видимости, необходимостью парсить строковые шаблоны в рантайме, крайне мутной системой изоляции стилей через Shadow DOM. В общем плюсы все еще не ясны.
Возможно я слегка предвзят тут, потому что мне нравятся веб-компоненты и идеи, которые за ними стоят. И что это стандарт, для базового использования которого не нужны никакие инструменты и рантаймы. Веб-компоненты на мой взгляд хорошая точка монтирования островов. Можно написать логику на Svelte, скомпилировать это в веб-компонент и легко вставлять в HTML.
Ну и главное не забывать, что 5кб рантайма даются не бесплатно, а за счет функционала.
Я считаю, что функциональность нужно добавлять по мере необходимости. То есть начать с тех же 5кб и наращивать функциональность тогда, когда это действительно нужно. То есть не исходить из того, что в дальнейшем что-то может понадобится, поэтому сразу заложусь на большую библиотеку. А может никогда и не понадобится, что на практике достаточно часто и происходит.
я предпочту 100кб рантайма
Вы - да. А что на счёт пользователей? Мы ведь разрабатываем сервисы не для себя. А ещё бизнес, который вместо этих 100кб предпочтёт добавить 100кб рекламы и аналитики. При этом нужно сохранить адекватный уровень производительности и метрики RUM. А лишний JS - это самый главный враг производительнсоти.
То, что динамический HTML готовится быстрее JSON - сомнительное утверждение. Бенчмарков у меня нет, но я такого в жизни не встречал.
Я как раз привёл ссылку на такой бенчмарк.
С чего ему быть быстрее, если для JSON обычно нужно вытащить поля из базы и отдать как есть, а для HTML - дополнительно прокинуть эти вытащенные поля в строковой шаблон? При этом делать это на каждый запрос.
Извлекая данные из базы, вы оперируете структурами данных языка. Для отправки данных на клиент их нужно сериализовать в JSON-строку. На сериализацию тратится достаточно много времени, потому что происходит рекурсивный обход структуры и преобразование в строку. Это время сравнимо с конкатенацией строк с фрагментами HTML, что на низком уровне происходит с шаблонизаторами.
Тоже не самое очевидное утверждение
Я исхожу из результатов такого бенчмарка. Фреймворки на JS/TS в нём далеко от топовых строчек, которые в основном занимает Rust, C++, Java, Go и PHP.
кроме скорости рендеринга мы получаем один язык для шаблонов и динамики
Согласен, один язык для фронта и бэка может быть полезен.
удоная гидратация
Честно говоря, для меня гидратация антипаттерн. Мы выполняем один и тот же код сначала на сервере, чтобы получить HTML. Затем на клиенте, чтобы получить виртуальное представление компонентов, построить дерево, привязать данные и обработчики.
На клиент идёт немаленький рантайм, который забивает основной поток, конфликтуя с всякими трекерами, аналитикой и другими скриптами, которые бизнес обязательно захочет добавить. И всё для того, чтобы создать в памяти дерево компонентов фреймворка, большинство из которых просто отображают статический текст и картинки.
Минусом к этому идёт плохой с точки зрения UX момент, когда страница отрендерилась и видна пользователю, а гидратация ещё в процессе и ничего не работает. Поэтому я больше сторонник статической генерации и серверного рендеринга с островами.
В ветке речь шла о шаблонизаторах, динамических областях с обработчиками событий и проблемах, связанных с этим. Про сложность виджетов речь не шла. Вопрос отрисовки динамических частей при помощи шаблонизатора веб-компоненты решают. Тут и изоляция стилей сторонних виджетов, и отсутствие ручной инициализаци, и жизненный цикл. То, о чём вы писали. Сами веб-компоненты при этом — просто набор низкоуровневых API и их можно использовать кучей разных способов.
Теперь про сложность. Надо отталкиваться от задачи. Если виджет простой или средний по сложности, вполне можно написать без обвеса. Я не из тех, для кого отсутствие синтаксического сахара и любимого фреймворка — препятствие и ухудшение.
А если нужно что-то действительно сложное, можно и рантайм добавить. Самое популярное для этого решение весит ~5кб, поставляется сразу с механизмом для работы со стилями, реактивными контроллерами и прочим. При этом ещё может работать без сборщиков.
Разница с SPA в том, что SPA полностью рисует и контролирует всю страницу. А тут классический северный рендеринг с островами интерактивности.
Не упускается. Само собой на генерацию HTML нужно время. Но и на генерацию JSON ответа время тоже нужно. HTML-ответ уже готов к рендерингу, а ещё его можно стримить. JSON-ответ нужно передать в скрипт для отрисовки.
Разница по времени подготовки HTML и JSON на сервере на самом деле не такая большая. Есть бенчмарк, где HTML оказался быстрее. Но разница такова, что ей можно пренебречь. HTML можно готовить фрагментарно. Неизменяемые части можно заранее пререндерить в файлы и отдавать клиенту без запуска рендерера.
Ну и Node — не лучшее решение для рендеринга HTML, другие языки справляются лучше и быстрее.
плюс <script> вставки с ручной инициализацией, то это супер решение конечно
Вы много пишите о <script>, изоляции, переиспользовании и прочем. Всё это решается веб-компонентами, если нужен динамический компонент с изолированной разметкой, стилями и логикой, жизненным циклом, автоматической инициализацией без ручного вызова скрипта и прочими прелестями. Полученный веб-компонент вставляется в шаблоны как любой другой HTML-элемент.
Ну в целом так работает большая часть интернета, как-то живём с этим 30 лет. Браузеры настолько быстро работают с обычным HTML с сервера, что никакой рендеринг JS-шаблона с этим не сравнится. Если пользователь уже был на странице, к повторному рендерингу 90% всех ресурсов уже будет лежать в кеше (особенно если его грамотно настроить).
Если всё же не хочется перерисовывать шапку/подвал, то есть решения — фрагментарные обновления. Сделали запрос, получили HTML-ответ, достали кусок с товарами и вставили в нужное место. Проблема с обработчикам? Можно делегировать на window/document/body, можно в метаданных (data-атрибутах) передавать. А вообще веб-компоненты сами инициализируются при парсинге. Под это есть разные инструменты, от pjax и unpoly, до htmx, alpine-ajax и т.д.
Если сделано правильно, то не будет. Зум просто пропорционально увеличивает всю страницу. С адаптивностью (а это стандарт де-факто), страница просто скатится в лэйаут для мобилок. Но это на экстремальных значениях зума, типа 400%. Я увеличиваю на 125-150 и в большинстве случаев всё нормально.
Если брать стандарт WCAG, то там есть требование, чтобы страница не разваливалась при 200% зуме. Удовлетворить критерию не сложно, но это делает функцию зума полезной и ничего не ломает.
Пользовательские таблицы стилей, всё же, не для рядового пользователя. Не каждый напишет CSS и разберётся, как его подключить к странице. А из браузеров давно выпилили эту возможность, осталась только в виде расширений.
Но это всё и не нужно, потому что высококонтрастные темы и прочее есть в настройках операционной системы. И в CSS с помощью медиа-запросов это можно отслеживать. Автор в статье как раз и пишет о нюансах в этих режимах.
Их поддержка, повторюсь, не такая сложная, хотя и соглашусь, что иногда выглядит как хаки. Но эти мелочи делают ненужными пользовательские таблицы стилей.
Но, как я говорил, Интернет для всех, поэтому в нём должно найтись место и пользователям зума, и тем, кто считает это ненужной функцией.
В этом и заключается суть универсального доступа. Дядя Тим завещал, что веб должен быть для всех. Для тех, кто не любит 100500 вкладок и не пользуется браузерным зумом, и для тех, кто им пользуется.
У меня с рождения не лучшее зрение, поэтому некоторые страницы я немного увеличиваю браузерным зумом. А ещё у людей с возрастом падает зрение, но люди всё равно продолжают пользоваться Интернетом.
Хороший интерфейс без проблем удовлетворяет и тем, и другим. И ничего особого для этого делать не надо.
Это, отнюдь, не значит, что их нет. Я пункты из статьи стараюсь применять на практике. В моём окружении хватает людей, которые тоже стараются их применять. Также я работаю с крупным SaaS вендором, у которого есть требования и подобные решения есть в кодовой базе их продуктов.
Очень доступно. Что под капотом у
AccessibleButton? Пачка<div>-ов сtabindex,onclick,roleи прочим?aria-labelзачем-то переопределяет встроенный текст кнопки, что как минимум ломает программы голосового управления и нарушает несколько критериев WCAG. Вот такая вот «улучшенная доступность» в UI-библиотеках React.Потому что автор вдохновлялся идеями React при написании своего микро-фреймворка
Идейно похоже на Webstudio. Может как источник вдохновения подойдёт.
Вот вы говорите, что вам всё равно на качество сайта, миллисекунды загрузки (не миллисекунды), нежелание заморачиваться и так далее. Но далее говорите о продажах, бизнесе и продукте. Я вижу в этом противоречие.
Продавать продукт нужно кому-то, то есть пользователям. Лэндинг продукта как раз и создаётся, чтобы рассказать пользователям о продукте и подвести их к целевому действию.
То есть уже тут неплохо бы, чтобы у потенциальных клиентов сайт загрузился и работал как можно быстрее. Особенно в мире мобильных устройств и нестабильных беспроводных сетей.
Также неплохо, чтобы пользователи вообще на сайт попадали. Понимаю, что источники трафика могут быть разными. Но ведь органика тоже хорошо. Значит, поисковики и AI-боты должны быстро находить и индексировать сайт. То есть нужно банальное SEO.
Известно, что скорость загрузки и поведенческие факторы влияют на SEO и позицию в выдаче. Известно, что гугл индексирует сайты с большим количеством JS в несколько раз дольше статики и с определёнными квотами из-за запуска headless-браузера.
Таким образом, сайт в достаточно конкурентной нише (ботов много кто делает) может выиграть в плане SEO, удобства для пользователей и скорости загрузки. А это влияет на бизнес-показатели.
Не стал бы гугл столько вкладываться в Web Vitals, Lighthouse и прочие инструменты, если бы это не влияло на время нахождения пользователей на сайтах и другие бизнес-метрики.
Так что хорошо сделанный и производительный сайт может лучше продавать при прочих равных.
В этом и суть. Аппликейшин, то есть приложение с какой-то логикой, высокой степенью интерактивности, обработкой данных на клиенте, длительными сеансами взаимодействия. А у вас сайт из нескольких страниц, на которых обычный текст, изображения, ссылки, иконки, несколько аккордеонов, формы и бургер-меню.
Первый рендеринг главной страницы из пяти секций на десктопе, в Chrome, на проводном соединении произошёл на отметке 2.9с и потребовал 19 запросов JS общим объёмом около 1.1мб. По мне так это неоправданно много. Всё из-за того, что так работает выбранный вами инструментарий и его не рационально использовать для такой задачи.
Я посмотрел страницы сайта и не увидел там чего-то, для чего вообще нужен JS. То есть сайт с точно таким же внешним видом, адаптивностью и функциями можно сделать без клиентского JS, роутеров, контекстов, вебпаков и прочего. Разве что десяток-другой строк JS для обработки форм и бургер-меню.
В моём понимании это должен быть обычный статический сайт, а в качестве инструмента для разработки, если хочется фреймворк, я бы предложил Astro, Eleventy, Hugo и другие SSG с упором на zero JS by default. ИИ бы также помог сгенерировать сайт на этих технологиях. Или, если нужно было быстро и без написания кода, то какие-нибудь готовые шаблоны.
Отсюда и вопрос от izibrizi2 и меня насчёт целесообразности, как вы писали, "сделать полноценный SPA-сайт" и выбора технологического стека для разработки контентного сайта.
Показанный код — это встроенные методы работы с DOM, которые одинаковы для всех браузеров, документированы и описаны в стандартах. Автор не разработал ничего своего, чтобы назвать это фреймворком. Он лишь показал пример разработки средствами стандартного DOM API.
Фреймворки поверх этих API есть и обычно они прячут многое под капот, упрощая написание кода и снижая количество ручной работы и вызовов DOM. Они вполне используются в продакшине очень даже крупными компаниями.
<template>— не просто строка, а экземплярDocumentFragment. То есть кусок DOM, который браузер распарсил и собрал из строки. И с этим фрагментом DOM можно работать через DOM API и потом вставить в нужное место или многократно клонировать.С
<div style="display:none">проблема в том, что если внутри есть ресурсы,<script>,<style>,<link>— они будет загружаться/выполняться, чего от шаблона обычно не хочется. Фишка<template>как раз в том, что внутри него всё инертно. Такое можно получить, разве что, от<script>, но в нём всё будет строкой.Пользовательские элементы построены на основе стандартного DOM API браузера. Вызовы методов жизненного цикла пользовательского элемента, по сути, биндинги к подкапотному API на C++. Браузер это и так делает при построении DOM, но разработчикам даётся возможность немного влезть в этот процесс и выполнить какой-то JS.
Поэтому технически пользовательскте элементы медленнее, чем простой HTML/CSS. И требуют загрузки, парсинга и выполнения JS-кода. Но разница не существенная. Остальное зависит от того, что происходит в методах жизненного цикла. Если там сетевые запросы на мегабайты данных или циклы на сотни тысяч итераций, то это будет медленно.
Тогда уж
<script type="application/json">{ ... }</script>для JSON (или любого другого текстового формата), если смотреть с точки зрения стандарта.Например для ленивой инициализации. Скажем, есть компонент, который изначально не нужен и инициируется только при каком-то пользовательском действии. Но вообще вкусовщина автора.
По воводу
DOMContentLoaded, предполагаю, чтобы не грузить основной поток выполнением лишнего JS и работой с DOM, которая возникает при инициализации пользовательских элементов. То есть сначала даём браузеру спокойно пропарсить разметку, загрузить стили и другие ресурсы, а потом, когда он построил DOM, уже выполнять скрипты. Но тоже похоже на вкусовщину автора.Эта статья — пример того, как делать не стоит. Если вы новичок и читаете эту статью, то я не рекомендую вам делать как там написано.
Сама идея «меню без JS» плоха. Чем не угодил JS? Не надо выдумывать хаки на чекбоксах, а потом обмазывать всё ARIA, ради того, чтобы не писать 20 строчек JS. А если прям очень хочется без JS, есть более современные и практичные решения:
<details>+<summary>, Popover. Хотя и это не повод городить огород «без JS».Целый раздел посвятили доступности и её важности, но меню доступным так и не сделали. Добавили две ненужные роли
bannerиnavigation, которые по умолчанию встроены у<header>и<nav>. Зато не добавили самое главное для раскрываемого меню — кнопку, передающую связь и состояние раскрытияaria-expanded. Для этого ведь JS нужен...А ещё на видео-демонстрациях меню классно раскрывается по
:hover. А что на счёт мобильных устройств с тач-экранами? Там нет:hover. Таким меню будет неудобно пользоваться на мобильных. И ещё куча моментов, которые не буду расписывать.Для меня показатель. Я придерживаюсь мнения, что на странице должно быть как можно меньше JS.
Согласен. Острова интерактивности можно сделать разными способами и не обязательно веб-компонентами. Svelte - Хороший пример инструмента для такой задачи.
Возможно я слегка предвзят тут, потому что мне нравятся веб-компоненты и идеи, которые за ними стоят. И что это стандарт, для базового использования которого не нужны никакие инструменты и рантаймы. Веб-компоненты на мой взгляд хорошая точка монтирования островов. Можно написать логику на Svelte, скомпилировать это в веб-компонент и легко вставлять в HTML.
Я считаю, что функциональность нужно добавлять по мере необходимости. То есть начать с тех же 5кб и наращивать функциональность тогда, когда это действительно нужно. То есть не исходить из того, что в дальнейшем что-то может понадобится, поэтому сразу заложусь на большую библиотеку. А может никогда и не понадобится, что на практике достаточно часто и происходит.
Вы - да. А что на счёт пользователей? Мы ведь разрабатываем сервисы не для себя. А ещё бизнес, который вместо этих 100кб предпочтёт добавить 100кб рекламы и аналитики. При этом нужно сохранить адекватный уровень производительности и метрики RUM. А лишний JS - это самый главный враг производительнсоти.
Я как раз привёл ссылку на такой бенчмарк.
Извлекая данные из базы, вы оперируете структурами данных языка. Для отправки данных на клиент их нужно сериализовать в JSON-строку. На сериализацию тратится достаточно много времени, потому что происходит рекурсивный обход структуры и преобразование в строку. Это время сравнимо с конкатенацией строк с фрагментами HTML, что на низком уровне происходит с шаблонизаторами.
Я исхожу из результатов такого бенчмарка. Фреймворки на JS/TS в нём далеко от топовых строчек, которые в основном занимает Rust, C++, Java, Go и PHP.
Согласен, один язык для фронта и бэка может быть полезен.
Честно говоря, для меня гидратация антипаттерн. Мы выполняем один и тот же код сначала на сервере, чтобы получить HTML. Затем на клиенте, чтобы получить виртуальное представление компонентов, построить дерево, привязать данные и обработчики.
На клиент идёт немаленький рантайм, который забивает основной поток, конфликтуя с всякими трекерами, аналитикой и другими скриптами, которые бизнес обязательно захочет добавить. И всё для того, чтобы создать в памяти дерево компонентов фреймворка, большинство из которых просто отображают статический текст и картинки.
Минусом к этому идёт плохой с точки зрения UX момент, когда страница отрендерилась и видна пользователю, а гидратация ещё в процессе и ничего не работает. Поэтому я больше сторонник статической генерации и серверного рендеринга с островами.
В ветке речь шла о шаблонизаторах, динамических областях с обработчиками событий и проблемах, связанных с этим. Про сложность виджетов речь не шла. Вопрос отрисовки динамических частей при помощи шаблонизатора веб-компоненты решают. Тут и изоляция стилей сторонних виджетов, и отсутствие ручной инициализаци, и жизненный цикл. То, о чём вы писали. Сами веб-компоненты при этом — просто набор низкоуровневых API и их можно использовать кучей разных способов.
Теперь про сложность. Надо отталкиваться от задачи. Если виджет простой или средний по сложности, вполне можно написать без обвеса. Я не из тех, для кого отсутствие синтаксического сахара и любимого фреймворка — препятствие и ухудшение.
А если нужно что-то действительно сложное, можно и рантайм добавить. Самое популярное для этого решение весит ~5кб, поставляется сразу с механизмом для работы со стилями, реактивными контроллерами и прочим. При этом ещё может работать без сборщиков.
Разница с SPA в том, что SPA полностью рисует и контролирует всю страницу. А тут классический северный рендеринг с островами интерактивности.
Не упускается. Само собой на генерацию HTML нужно время. Но и на генерацию JSON ответа время тоже нужно. HTML-ответ уже готов к рендерингу, а ещё его можно стримить. JSON-ответ нужно передать в скрипт для отрисовки.
Разница по времени подготовки HTML и JSON на сервере на самом деле не такая большая. Есть бенчмарк, где HTML оказался быстрее. Но разница такова, что ей можно пренебречь. HTML можно готовить фрагментарно. Неизменяемые части можно заранее пререндерить в файлы и отдавать клиенту без запуска рендерера.
Ну и Node — не лучшее решение для рендеринга HTML, другие языки справляются лучше и быстрее.
Вы много пишите о
<script>, изоляции, переиспользовании и прочем. Всё это решается веб-компонентами, если нужен динамический компонент с изолированной разметкой, стилями и логикой, жизненным циклом, автоматической инициализацией без ручного вызова скрипта и прочими прелестями. Полученный веб-компонент вставляется в шаблоны как любой другой HTML-элемент.Ну в целом так работает большая часть интернета, как-то живём с этим 30 лет. Браузеры настолько быстро работают с обычным HTML с сервера, что никакой рендеринг JS-шаблона с этим не сравнится. Если пользователь уже был на странице, к повторному рендерингу 90% всех ресурсов уже будет лежать в кеше (особенно если его грамотно настроить).
Если всё же не хочется перерисовывать шапку/подвал, то есть решения — фрагментарные обновления. Сделали запрос, получили HTML-ответ, достали кусок с товарами и вставили в нужное место. Проблема с обработчикам? Можно делегировать на window/document/body, можно в метаданных (data-атрибутах) передавать. А вообще веб-компоненты сами инициализируются при парсинге. Под это есть разные инструменты, от pjax и unpoly, до htmx, alpine-ajax и т.д.