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