Конечно они быстрее работают с готовым 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, если так уж перезагрузка страницы раздражает?
Я не совсем понял, ко мне ли обращен ваш ответ, если ко мне, то я не знаю кто и зачем что-то пересобирает просто ради смены фреймворка. Если что-то решается одним фрилансером-верстальщиком и готовым шаблоном вордпресса, то так и надо делать.
Клиентские фреймворки берут для проектов, требующих поддержки и доработок под специфические требования. Кроме валидации там еще много чего, чего нет в вордпрессе - он ведь не SPA и там нельзя легко навесить на разметку те же банальные обработчики, которых может быть очень много.
Ну и клиентская валидация не равна серверной, серверные валидации гораздо сложнее, могут опираться на кучу third-party систем, о которых фронтенду знать не нужно. Клиентские фреймворки поддерживают и клиентскую и серверную валидацию, в том числе одновременно.
На вордпрессе без спец. решений на мало мальски сложных формах уже можно начать сходить с ума если руками писать все это.
Если ориентироваться на список запущенных проектов на ее сайте в портфолио, то так и есть. Это то, что обычно называют "сайт на вордпрессе под ключ". Только зачем-то самописное, вордпресс давно уже покруче будет чем вся эта простенькая HTML5 валидация, нативные алерты, подключенный скрипт-тегом фэнсибокс (мило).
Можно ли так делать проекты для малого бизнеса за три копейки? Да вполне, хотя и непонятно чем ворпдресс не угодил.
Стоит ли поливать помоями тех, кто делает что-то иначе? Это на совести авторки.
Почему-то ни одному разработчику интерфейсов (а сайт - это пользовательский интерфейс) вне веба не приходит в голову перерисовывать полностью весь вьюпорт при частичных изменениях (не считая GUI immediate-режима). Потому что это видно глазами, а в вебе еще и создает задержки на скорость взаимодействия.
Ограничения веба - это именно ограничения, и то что их обходят - это хорошо. А треш - это то что вы описываете.
Эти генераторы позволяют писать SPA, получая на выход статическую разметку. У них есть своя область применимости, например писать лендинги на таких генераторах гораздо удобнее, чем с помощью описанного вами подхода. Как раз за счет технологического стека вокруг SPA.
Так у меня и не возникают сложности:) Я ведь не использую веб компоненты с серверными шаблонизаторами.
Хотя и приходилось работать на проектах, которые в это пытались.
А вообще тут технический ресурс, ни к чему аналогии. Если хотите донести мысль, лучше покажите код.
Конечно они быстрее работают с готовым 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
Я не совсем понял, ко мне ли обращен ваш ответ, если ко мне, то я не знаю кто и зачем что-то пересобирает просто ради смены фреймворка. Если что-то решается одним фрилансером-верстальщиком и готовым шаблоном вордпресса, то так и надо делать.
Клиентские фреймворки берут для проектов, требующих поддержки и доработок под специфические требования. Кроме валидации там еще много чего, чего нет в вордпрессе - он ведь не SPA и там нельзя легко навесить на разметку те же банальные обработчики, которых может быть очень много.
Ну и клиентская валидация не равна серверной, серверные валидации гораздо сложнее, могут опираться на кучу third-party систем, о которых фронтенду знать не нужно. Клиентские фреймворки поддерживают и клиентскую и серверную валидацию, в том числе одновременно.
На вордпрессе без спец. решений на мало мальски сложных формах уже можно начать сходить с ума если руками писать все это.
Сперва добейся? (с) Что же из ваших проектов в портфолио нельзя было сделать на готовой CMS?
Если ориентироваться на список запущенных проектов на ее сайте в портфолио, то так и есть. Это то, что обычно называют "сайт на вордпрессе под ключ". Только зачем-то самописное, вордпресс давно уже покруче будет чем вся эта простенькая HTML5 валидация, нативные алерты, подключенный скрипт-тегом фэнсибокс (мило).
Можно ли так делать проекты для малого бизнеса за три копейки? Да вполне, хотя и непонятно чем ворпдресс не угодил.
Стоит ли поливать помоями тех, кто делает что-то иначе? Это на совести авторки.
В случае бесконечной подгрузки как минимум остается возможность браузерного поиска по странице. Я лично им пользуюсь.
Почему-то ни одному разработчику интерфейсов (а сайт - это пользовательский интерфейс) вне веба не приходит в голову перерисовывать полностью весь вьюпорт при частичных изменениях (не считая GUI immediate-режима). Потому что это видно глазами, а в вебе еще и создает задержки на скорость взаимодействия.
Ограничения веба - это именно ограничения, и то что их обходят - это хорошо. А треш - это то что вы описываете.
Эти генераторы позволяют писать SPA, получая на выход статическую разметку. У них есть своя область применимости, например писать лендинги на таких генераторах гораздо удобнее, чем с помощью описанного вами подхода. Как раз за счет технологического стека вокруг SPA.