То, что динамический HTML готовится быстрее JSON - сомнительное утверждение. Бенчмарков у меня нет, но я такого в жизни не встречал. С чего ему быть быстрее, если для JSON обычно нужно вытащить поля из базы и отдать как есть, а для HTML - дополнительно прокинуть эти вытащенные поля в строковой шаблон? При этом делать это на каждый запрос.
Ну и Node — не лучшее решение для рендеринга HTML, другие языки справляются лучше и быстрее.
Тоже не самое очевидное утверждение, но даже если так - при использовании Node для этих целей, кроме скорости рендеринга мы получаем один язык для шаблонов и динамики, со всеми его преимуществами - удобный проброс данных, удоная гидратация, то же самые server components позволяют организовать серверный рендеринг с динамическими островками.
Я понимаю, что можно сделать все и без этого, но это просто удобнее и быстрее.
Я согласен с тем, что вы пишете, и сам примерно также применяю веб-компоненты. Размер рантайма тут не показатель, так как и для решений без веб-компонентов не обязательно брать тот же реакт. Есть решения в 5кб с минимальным обвесом, которые дадут все эти бонусы. Из примеров - Svelte, который может self-бандлить компонент с микрорантаймом в виде одного скрипта. И во многих других фреймворках сейчас появилась такая возможность.
При этом вы не сталкиваетесь с ограничениями веб-компонентов - глобальной областью видимости, необходимостью парсить строковые шаблоны в рантайме, крайне мутной системой изоляции стилей через Shadow DOM. В общем плюсы все еще не ясны.
Ну и главное не забывать, что 5кб рантайма даются не бесплатно, а за счет функционала. Если вам хватает - это нормально. Если потенциально мне может потребоваться больше функционала или более богатая экосистема готовых компонентов - я предпочту 100кб рантайма, зато без необходимости его менять в будущем.
Я не говорил, что АПИ веб компонентов легко использовать без оберток. Но уже есть готовые решения, которые добавляют минимум полезного, типа lit или stencil.
Вы отвечали на вот этот мой комментарий:
Вы пробовали их использовать для чего либо, сложнее простых виджетов? Без обвеса это удовольствие сильно ниже среднего при разработке. А с обвесом они становятся просто аналогом SPA фреймворков, к которым нужно тащить свой рантайм.
С чем вы тут несогласны? Под рантаймом я имею в виду код, без которого ваш веб-компонент не запустится. В Lit это его core-packages.
Без рантайма вы будете вынуждены писать так, как по вашей ссылке - вручную управлять DOM, вешать и удалять евенты строго через addEventListener, через придумывать как разместить кастомные евенты в глобальном скоупе чтобы не законфликтили, следить за именованием веб-компонентов (чтобы тодже не законфликтили), и т.д.
Я лично написал на них демку пошаговой боевки одной игры несколько лет назад. Да отличается от реакта, но выходить из зоны комфорта иногда надо. Там обычно точки роста.
В каждом вашем сообщении я замечаю какой-то способ самоутверждения через фразы вроде "выходить из зоны комфорта". Я поддерживал и дописывал крупный американский проект на Polymer в 2017-18 годах. На Lit примерно в те же годы я писал свой сайд проект в связке с leaflet. Веб-компоненты (включая безрантаймовые) я до сих иногда пишу на работе, там где это уместно. Первый свой доклад по ним делал еще в 2014 году. Реакт тогда только появлялся, все (включая меня) писали на jQuery/Backbone/Marionette/Knockout/Angular 1.3.
Я достаточно вышел из зоны комфорта? К чему вся эта информация, кто сколько чего написал, если мы обсуждаем конкретные примеры? На конкретном примере докажите вашу правоту, покажите код - и вы будете правы независимо от ваших/моих заслуг.
Вы лучше не "как делать" покажите, а конечный результат. Как правильно делать может учить любой дурак, тут вон целая статья на эту тему, в рамках которой мы общаемся.
У вас есть пример веб-компонента, к которому не пришлось писать свой рантайм для работы с шаблонами, проброса данных в виде объектов, навешивания обработчиков событий декларативного, и т.д.?
Хотя бы какое нибудь более менее сложное поле ввода или мультиселект.
Конечно они быстрее работают с готовым HTML. Только как то упускается, что перед этим этот HTML надо сгенерить на сервере. Что далеко не бесплатно и не моментально.
Вы пробовали их использовать для чего либо, сложнее простых виджетов? Без обвеса это удовольствие сильно ниже среднего при разработке. А с обвесом они становятся просто аналогом SPA фреймворков, к которым нужно тащить свой рантайм.
Я не нашел там кода, поэтому не могу понять как там выполняется на сервере js, чтобы получить итоговую разметку чтобы отдать ее пользователю. Ткните пожалуйста.
Но они же вроде бы просто автоматизируют добавление обработчиков на начальную разметку. То есть если применить компонент spoiler, то он из <div class="spoiler"> сделает <div onclick="...">...</div>. Но ведь он сделает это уже на клиенте, а не на сервере?
В SSR с гидрацией вы сразу получите итоговую разметку. Это может быть важно для скорости отрисовки, если речь не про спойлер, а про большой динамический компонент, например какой-нибудь top товаров в виде карусели, который надо показать максимально быстро и красиво до того, как отработает js.
Обработчики это ведь не только онклики, они могут дергать сторонние сервисы чтобы сформировать итоговую разметку.
Гидратация - это не когда контент отображается в режиме SSR, это умеют и обычные шаблонизаторы. При гидратации на пришедшую с сервера разметку автоматически навешиваются все обработчики, описанные в клиентском коде.
Такого классические шаблонизаторы делать не умеют, там надо явно вызывать скрипты инициализации для каждого компонента.
Я не припомню примеров из прошлого до реакта, где такое было, можете привести пример?
Серверные компоненты появились не более двух лет назад. Серверные фреймворки с поддержкой гидратации появились намного раньше, а без фреймворков это было доступно в React изначально, с помощью renderToString/hydrate. Это и стали называть SSR (в контексте SPA).
Все же шаблонизаторы отличаются от того, что называют сейчас SSR тем, что они не поддерживают гидратацию. Поэтому чтобы не путаться, результат работы классических шаблонизаторов в таком контексте называют MPA или как-то еще.
Мне ближе подход, где команда владеет всем стеком — от шаблона до схемы БД. Тогда можно доставлять фичи быстро, без синхронизаций, ожидания чужих изменений и с меньшим количеством багов.
Ну если команды поделить по проектам, то примерно так и будет, с поправкой, что бек отделен от фронта внутри каждого проекта. Это не создает сложностей при разработке - чаще наоборот, бек не хочет заниматься фронтом, а фронт - беком. И не создает особых сложностей при выкатке - катимся либо вместе одновременно, либо сам качусь когда мне удобно (если правки чисто фронтовые).
В сумме весь стек так и остается у одной команды, пусть и с разделением специализации
Я могу сказать лишь что это рабочая и популярная в энтерпрайзе схема. Headless UI либа решает вопрос с разными фреймворками для разных проектов, но она сложнее в разработке и поддержке (если своя). Хотя обычно компании все же стремятся придерживаться одного стека, и тогда либу можно взять под фреймворк.
Поддерживать версионирование и обратную совместимость компонентов естественно геморойно, но это так в любых публичных API. На крупных проектах под жто иногда выделяется отдельная команда, иногда решается на уровне лидов команд.
Если делать монорепу, то для ui либы можно пропустить момент с выкладкой в npm/nexus и сильно упростить ее правки/доставку в проекты - будут прямые импорты и не надо будет ее билдить в пакет. Это крайне удобно, но команды должны быть или темно связаны, или дисциплинированы чтобы пользоваться такой свободой с умом.
Если все эти приложения связаны единым UI, то я бы такое реализовал набором отдельных фронтендов, какие-то в виде SPA, какие-то нет. UI библиотека и все остальное , что хочется пошарить в этом случае выносится в отдельный пакет.
Но можно и монорепой, если сможете подружить ее со своим ci. В монорепе есть свои плюсы, и для них существуют хорошие инструменты управления (https://nx.dev/).
Повторю в третий, и надеюсь последний раз, что статику, включая документацию, можно отдавать чем угодно. В том числе и Next/Astro или аналогами.
Библиотека компонентов может быть на любом фреймворке, не обязательно на реакте. Она может быть даже в классическом MPA, просто там ее нельзя полноценно реализовать.
Сейчас в ходу есть целый ряд headless библиотек компонентов (https://headlessui.com/, https://www.radix-ui.com/, https://mantine.dev/), предоставляющих одинаковые контролы для разных фреймворков. Это на мой взгляд правильно, но необхлдимость их применения ограничена - чаще всего это надо на старых проектах с наслоениями из кучи разных технологий, которые нужно привести к одному виду. В этом случае там не будет на одной странице одновременно нескольких фреймворков.
Далее, если перечитаете, я не предлагаю Next. Я привел его как альтернативный вариант. Отдавать контент под индексацию можно чем угодно. Если это будет Next вы просто получите больше плюшек.
По валидации повторюсь, если делать лендинг с одной формой, можно сделать ее как угодно. Если посложнее, с зависимыми полями, с динамическими полями - уже не получится без написания самопального аналога библиотеки управления формами.
Хендлеры все же разные бывают. Нужно что-то более четкое. Уверен часть из них может быть просто ссылками + htmx, а другая решаться CSS. Так что уточните пожалуйста.
Пример - onClear евент на компоненте, который его не поддерживает. Например на обычном текстовом инпуте.
htmx я использовал на реальных проектах, он предполагает разработку в постраничной парадигме без выделения компонентов. Из-за этого у него тоже есть ограничения сверху по сложности разрабатываемого сайта/приложения.
Ага, понял. Я не в этом треде, а в других в этом же топике, приводил примеры доработок, которые намного сложнее сделать без компонентной системы в каком-либо виде.
Один пример сходу - если у вас кастомный, брендированный дизайн, то его дадут вам в виде юайкита, побитого на компоненты. Из которых собраны экраны. В фотошопе никто давно страницы не рисует. И хорошо бы их именно так и реализовывать, чтоб кнопка в одной папочке лежала и одним импортом вставлялась только туда, куда надо.
htmx тоже от этого страдает, можно посмотреть на частоту появления вопросов типа "а как мне вставить датагрид/диалог/что-то еще мало мальски динамическое" на реддите. Хотя это конечно намного более продвинутое решение, чем самописный MPA фреймворк непонятно на чем, как в этой статье рекомендуется.
SPA by default давно не требуется по умолчанию. Перед стартом проекта нужно определить предполагаемое количество интерактива и форм на нем. И если есть хоть небольшая вероятность, что интерактив будет расти, лучше сразу делать либо SPA для интерактивных страниц + серверный рендеринг для контентных, либо взять Next.js или аналог, и там из коробки можно создавать смешанные приложения, где часть страниц (или даже частей страниц) рендерится клиентом, а часть - сервером.
Обработчики - это ну.. обработчики. Вот есть у вас компонент с кастомными обработчиками, что проще - написать <component onCustomEvent="handleSomething"> или где то рядом приколхоживать <script>document.querySelector('#component_instance_1').init({ onCustomEvent: handleSomething }).
А если там с десяток таких компонентов на странице, и всем нужно что-то свое прицепить? На условных сайтах на вордпрессе такое может не часто надо. А так вообще регулярно требуется.
В случае наличия серверной валидации, зачем нужно что-то более сложное чем htmx, если так уж перезагрузка страницы раздражает?
Если в этом смысле, то понятно. Просто из заголовка ожидал прочитать про другое.
Прочитал, но не понял где тут собственно фреймворк. Вы же реакт выбрали в итоге, и создали для него библиотеку компонентов?
То, что динамический HTML готовится быстрее JSON - сомнительное утверждение. Бенчмарков у меня нет, но я такого в жизни не встречал. С чего ему быть быстрее, если для JSON обычно нужно вытащить поля из базы и отдать как есть, а для HTML - дополнительно прокинуть эти вытащенные поля в строковой шаблон? При этом делать это на каждый запрос.
Тоже не самое очевидное утверждение, но даже если так - при использовании Node для этих целей, кроме скорости рендеринга мы получаем один язык для шаблонов и динамики, со всеми его преимуществами - удобный проброс данных, удоная гидратация, то же самые server components позволяют организовать серверный рендеринг с динамическими островками.
Я понимаю, что можно сделать все и без этого, но это просто удобнее и быстрее.
Я согласен с тем, что вы пишете, и сам примерно также применяю веб-компоненты. Размер рантайма тут не показатель, так как и для решений без веб-компонентов не обязательно брать тот же реакт. Есть решения в 5кб с минимальным обвесом, которые дадут все эти бонусы. Из примеров - Svelte, который может self-бандлить компонент с микрорантаймом в виде одного скрипта. И во многих других фреймворках сейчас появилась такая возможность.
При этом вы не сталкиваетесь с ограничениями веб-компонентов - глобальной областью видимости, необходимостью парсить строковые шаблоны в рантайме, крайне мутной системой изоляции стилей через Shadow DOM. В общем плюсы все еще не ясны.
Ну и главное не забывать, что 5кб рантайма даются не бесплатно, а за счет функционала. Если вам хватает - это нормально. Если потенциально мне может потребоваться больше функционала или более богатая экосистема готовых компонентов - я предпочту 100кб рантайма, зато без необходимости его менять в будущем.
Вы отвечали на вот этот мой комментарий:
С чем вы тут несогласны? Под рантаймом я имею в виду код, без которого ваш веб-компонент не запустится. В Lit это его core-packages.
Без рантайма вы будете вынуждены писать так, как по вашей ссылке - вручную управлять DOM, вешать и удалять евенты строго через addEventListener, через придумывать как разместить кастомные евенты в глобальном скоупе чтобы не законфликтили, следить за именованием веб-компонентов (чтобы тодже не законфликтили), и т.д.
В каждом вашем сообщении я замечаю какой-то способ самоутверждения через фразы вроде "выходить из зоны комфорта". Я поддерживал и дописывал крупный американский проект на Polymer в 2017-18 годах. На Lit примерно в те же годы я писал свой сайд проект в связке с leaflet. Веб-компоненты (включая безрантаймовые) я до сих иногда пишу на работе, там где это уместно. Первый свой доклад по ним делал еще в 2014 году. Реакт тогда только появлялся, все (включая меня) писали на jQuery/Backbone/Marionette/Knockout/Angular 1.3.
Я достаточно вышел из зоны комфорта? К чему вся эта информация, кто сколько чего написал, если мы обсуждаем конкретные примеры? На конкретном примере докажите вашу правоту, покажите код - и вы будете правы независимо от ваших/моих заслуг.
Вы лучше не "как делать" покажите, а конечный результат. Как правильно делать может учить любой дурак, тут вон целая статья на эту тему, в рамках которой мы общаемся.
У вас есть пример веб-компонента, к которому не пришлось писать свой рантайм для работы с шаблонами, проброса данных в виде объектов, навешивания обработчиков событий декларативного, и т.д.?
Хотя бы какое нибудь более менее сложное поле ввода или мультиселект.
Так у меня и не возникают сложности:) Я ведь не использую веб компоненты с серверными шаблонизаторами.
Хотя и приходилось работать на проектах, которые в это пытались.
А вообще тут технический ресурс, ни к чему аналогии. Если хотите донести мысль, лучше покажите код.
Конечно они быстрее работают с готовым HTML. Только как то упускается, что перед этим этот HTML надо сгенерить на сервере. Что далеко не бесплатно и не моментально.
Вы пробовали их использовать для чего либо, сложнее простых виджетов? Без обвеса это удовольствие сильно ниже среднего при разработке. А с обвесом они становятся просто аналогом SPA фреймворков, к которым нужно тащить свой рантайм.
Да действительно, похоже. Я изначально подумал, что речь про что-то типа jQuery-плагинов.
Я не нашел там кода, поэтому не могу понять как там выполняется на сервере js, чтобы получить итоговую разметку чтобы отдать ее пользователю. Ткните пожалуйста.
upd. нашел, смотрю)
Но они же вроде бы просто автоматизируют добавление обработчиков на начальную разметку. То есть если применить компонент spoiler, то он из <div class="spoiler"> сделает <div onclick="...">...</div>. Но ведь он сделает это уже на клиенте, а не на сервере?
В SSR с гидрацией вы сразу получите итоговую разметку. Это может быть важно для скорости отрисовки, если речь не про спойлер, а про большой динамический компонент, например какой-нибудь top товаров в виде карусели, который надо показать максимально быстро и красиво до того, как отработает js.
Обработчики это ведь не только онклики, они могут дергать сторонние сервисы чтобы сформировать итоговую разметку.
Гидратация - это не когда контент отображается в режиме SSR, это умеют и обычные шаблонизаторы. При гидратации на пришедшую с сервера разметку автоматически навешиваются все обработчики, описанные в клиентском коде.
Такого классические шаблонизаторы делать не умеют, там надо явно вызывать скрипты инициализации для каждого компонента.
Я не припомню примеров из прошлого до реакта, где такое было, можете привести пример?
Серверные компоненты появились не более двух лет назад. Серверные фреймворки с поддержкой гидратации появились намного раньше, а без фреймворков это было доступно в React изначально, с помощью renderToString/hydrate. Это и стали называть SSR (в контексте SPA).
Все же шаблонизаторы отличаются от того, что называют сейчас SSR тем, что они не поддерживают гидратацию. Поэтому чтобы не путаться, результат работы классических шаблонизаторов в таком контексте называют MPA или как-то еще.
Ну если команды поделить по проектам, то примерно так и будет, с поправкой, что бек отделен от фронта внутри каждого проекта. Это не создает сложностей при разработке - чаще наоборот, бек не хочет заниматься фронтом, а фронт - беком. И не создает особых сложностей при выкатке - катимся либо вместе одновременно, либо сам качусь когда мне удобно (если правки чисто фронтовые).
В сумме весь стек так и остается у одной команды, пусть и с разделением специализации
Я могу сказать лишь что это рабочая и популярная в энтерпрайзе схема. Headless UI либа решает вопрос с разными фреймворками для разных проектов, но она сложнее в разработке и поддержке (если своя). Хотя обычно компании все же стремятся придерживаться одного стека, и тогда либу можно взять под фреймворк.
Поддерживать версионирование и обратную совместимость компонентов естественно геморойно, но это так в любых публичных API. На крупных проектах под жто иногда выделяется отдельная команда, иногда решается на уровне лидов команд.
Если делать монорепу, то для ui либы можно пропустить момент с выкладкой в npm/nexus и сильно упростить ее правки/доставку в проекты - будут прямые импорты и не надо будет ее билдить в пакет. Это крайне удобно, но команды должны быть или темно связаны, или дисциплинированы чтобы пользоваться такой свободой с умом.
Если все эти приложения связаны единым UI, то я бы такое реализовал набором отдельных фронтендов, какие-то в виде SPA, какие-то нет. UI библиотека и все остальное , что хочется пошарить в этом случае выносится в отдельный пакет.
Но можно и монорепой, если сможете подружить ее со своим ci. В монорепе есть свои плюсы, и для них существуют хорошие инструменты управления (https://nx.dev/).
Повторю в третий, и надеюсь последний раз, что статику, включая документацию, можно отдавать чем угодно. В том числе и Next/Astro или аналогами.
Библиотека компонентов может быть на любом фреймворке, не обязательно на реакте. Она может быть даже в классическом MPA, просто там ее нельзя полноценно реализовать.
Сейчас в ходу есть целый ряд headless библиотек компонентов (https://headlessui.com/, https://www.radix-ui.com/, https://mantine.dev/), предоставляющих одинаковые контролы для разных фреймворков. Это на мой взгляд правильно, но необхлдимость их применения ограничена - чаще всего это надо на старых проектах с наслоениями из кучи разных технологий, которые нужно привести к одному виду. В этом случае там не будет на одной странице одновременно нескольких фреймворков.
Далее, если перечитаете, я не предлагаю Next. Я привел его как альтернативный вариант. Отдавать контент под индексацию можно чем угодно. Если это будет Next вы просто получите больше плюшек.
По валидации повторюсь, если делать лендинг с одной формой, можно сделать ее как угодно. Если посложнее, с зависимыми полями, с динамическими полями - уже не получится без написания самопального аналога библиотеки управления формами.
Пример - onClear евент на компоненте, который его не поддерживает. Например на обычном текстовом инпуте.
htmx я использовал на реальных проектах, он предполагает разработку в постраничной парадигме без выделения компонентов. Из-за этого у него тоже есть ограничения сверху по сложности разрабатываемого сайта/приложения.
Ага, понял. Я не в этом треде, а в других в этом же топике, приводил примеры доработок, которые намного сложнее сделать без компонентной системы в каком-либо виде.
Один пример сходу - если у вас кастомный, брендированный дизайн, то его дадут вам в виде юайкита, побитого на компоненты. Из которых собраны экраны. В фотошопе никто давно страницы не рисует. И хорошо бы их именно так и реализовывать, чтоб кнопка в одной папочке лежала и одним импортом вставлялась только туда, куда надо.
htmx тоже от этого страдает, можно посмотреть на частоту появления вопросов типа "а как мне вставить датагрид/диалог/что-то еще мало мальски динамическое" на реддите. Хотя это конечно намного более продвинутое решение, чем самописный MPA фреймворк непонятно на чем, как в этой статье рекомендуется.
SPA by default давно не требуется по умолчанию. Перед стартом проекта нужно определить предполагаемое количество интерактива и форм на нем. И если есть хоть небольшая вероятность, что интерактив будет расти, лучше сразу делать либо SPA для интерактивных страниц + серверный рендеринг для контентных, либо взять Next.js или аналог, и там из коробки можно создавать смешанные приложения, где часть страниц (или даже частей страниц) рендерится клиентом, а часть - сервером.
Обработчики - это ну.. обработчики. Вот есть у вас компонент с кастомными обработчиками, что проще - написать <component onCustomEvent="handleSomething"> или где то рядом приколхоживать <script>document.querySelector('#component_instance_1').init({ onCustomEvent: handleSomething }).
А если там с десяток таких компонентов на странице, и всем нужно что-то свое прицепить? На условных сайтах на вордпрессе такое может не часто надо. А так вообще регулярно требуется.
Это валидация формы, серверная в данном случае. Есть еще кейсы для клиентской, живой валидации. Хорошее чтиво на тему есть у контура - https://guides.kontur.ru/principles/forms/validation/#Vidi_validatsii