Эх, вы, дево-псы... как там DevSecFinBisOps поживает? Не пора ли уже похоронить этот термин? То о чем вы написали называется Continuous Delivery. Как следствие переименуем дево-псов в то, чем они являются - опсы обыкновенные и перестанем разыгрывать этот театр.
Те ребятки которые себя фулстеками считают и приходят на существующие продукты, они же не идут пилить существующий код на Java\php\python. Они начинают пилить свой "бэкенд" оборачивая существующие АПИ, делая тот самый SSR.
Это требует понимания что мы вообще в браузере выполняемся, и что фронт - это часть общего приложения и его надо рассматривать ВМЕСТЕ с бэком и БД и инфраструктурой.
А с СПА - можно закрыться в своем мирке и считать что вокруг ничего нет. Удел мидлов.
я не говорил что они отказываются от сахара вообще в пользу голого html.
Просто надо не запихивать целиком все в реакт, а делать виджеты. Да по другому чутка работает, но столько лишней сложности уходит. И htmx тут очень хорошо подходит. 99% веб приложений не нуждается в чем-то более сложном.
ССГ это хорошо, вот вы и вернулись к тому, о чем была статья изначально. Велком.
Только статья про Спринг, а не про JS фреймворки. И со стороны Спринга действительно проще делать SSG + htmx.
Так что я не понимаю в чем в принципе особая проблема..
Проблема в том что SPA - это дефолтное решение. Фронтендерам не приходит в голову мысль что можно НЕ делать SPA, не тащить стейт менеджмент, не тащить рутер и тп. Попробуйте, вам понравится.
у меня сложилось впечатление, что суть дискуссии утеряна и мы говорим о разных вещах. Напомните пожалуйста в чем суть беседы сейчас? Иначе предлагаю свернуть это все.
Я не говорил, что АПИ веб компонентов легко использовать без оберток. Но уже есть готовые решения, которые добавляют минимум полезного, типа lit или stencil.
Да и что вы под рантаймом имеете ввиду?
Шаблоны есть уже встроеные в сами веб компонетны. Зачем городить еще свое что-то? Просто по тому что можем?
Я лично написал на них демку пошаговой боевки одной игры несколько лет назад. Да отличается от реакта, но выходить из зоны комфорта иногда надо. Там обычно точки роста.
Сегодня вокруг них столько всего есть, что разработка становится гораздо комфортней.
Попробуйте взглянуть на этот процесс с другой стороны. Если вы испытываете сложности, то скорее всего это знак, что вы что-то делаете не так. Просто остановитесь и подумайте.
Жмете газ, а машина не едет - проверьте, не пытаетесь ли вы по сугробам на кабриолете гонять.
Если среда сопротивляется - бесполезно дальше давить.
Подход с набором отдельных фронтов и общей UI-библиотекой — интересный, но на практике он уже близок к архитектуре микро-фронтендов. Даже если всё на React, остаётся масса тонких мест:
– Как быстро команда может внести правку в компонент, если он переиспользуется во всех фронтах? – Что происходит, когда библиотеку обновляют? Как избежать цепной реакции поломок, версионирования, откатов? – А если одна из команд решит использовать Astro или вообще уйдёт от React — переиспользование UI-компонентов уже не работает.
Такие зависимости сильно сказываются на скорости. Команды вроде бы разделены, но на деле — завязаны на общий код и инфраструктуру.
Мне ближе подход, где команда владеет всем стеком — от шаблона до схемы БД. Тогда можно доставлять фичи быстро, без синхронизаций, ожидания чужих изменений и с меньшим количеством багов.
Как ты думаешь, насколько предложенная тобой схема действительно ускоряет команды, если смотреть на разработку целиком — от идеи до продакшна?
пара лендингов, каждый со своим стэком, т.к. они делались в разное время
каталог + поиск
чекаут форма
личный кабинет
система управления заказами
внутренняя документация
система управления складом
система управления нотификациями/рассылками
система учета финансов
документация для пользователей
внутренняя документация
еще десяток внутренних тулзов
Все это вместе - многостраничное приложение. Оно служит всем его пользователям, чтобы предоставлять не противоречивую информацию.
Я правильно понимаю, что по вашей логике, чтобы стили не ломались, вы предлагаете ВСЕ это засунуть в условное "next" приложение? Или делать статическую документацию на реакте, по тому что там есть чекаут форма?
Ну вот вы свели все снова в Реакту, хотя назвали его Next.js.
UI kit это хорошо, но не требует чтобы была только 1 имплементация. Библиотека компонентов может содержать имплементации для разных кейсов. Может быть и кнопка на реакте, vuew и хелпер для темплейта в бэке.
Вы похоже заранее пытаетесь применить DRY там где не надо. И жертвуете YAGNI выбирая Next для ВСЕГО проекта, хотя интерактивности может быть 1 страница, и ее можно было запилить сделав виджет и добавив скрипт тэг.
Хендлеры все же разные бывают. Нужно что-то более четкое. Уверен часть из них может быть просто ссылками + htmx, а другая решаться CSS. Так что уточните пожалуйста.
Валидация интерактивная конечно прикольная. Но 1 форма не должна требовать замены всего стэка. htmx выкатит скоро свой апи для плагинов. Уверен мы взглянем на эту проблему по новому. А еще есть старый добрый jQuery, используемый кстати в бутстрапе, который решает эту задачу декларативно. И бандл сильно меньше будет.
Я понимаю что все к Реакту привыкли. Уже выросло новое поколение разработчиков, которые не пробовали ничего другого, не видели как можно малым обойтись. Но просто представьте, что эта валидация - это подключение htmx + пара дата тэгов от бэка, который знает о валидации, переводах и связях между полями.
Вы про какие-то обработчики постоянно говорите. Можете пояснить что вы имеете ввиду?
В случае наличия серверной валидации, зачем нужно что-то более сложное чем htmx, если так уж перезагрузка страницы раздражает? Надо просто отправить форму и показать ответ. Это не требует преобразования формы в json 2 раза.
Про сложность работы с вордпрессом ничего не могу сказать, у меня мало с ним опыта. Но возможно сложность там появилась не на пустом месте.
Тут вопрос в том чем вы расплачиваетесь за это. Собрав весь гуи в 1 место, вы вставляете палки в колеса другим командам, которым надо разрабывать что-то параллельно с вами.
Таким образом, следующий шаг после МВП не отрезать фронт от бэка, а разделить фронт на микрофронты и виджеты. Что не подразумевает одного большого репозитория с реактом.
И даже там будут вопросы о целесообразности использования какого-то конкретного фреймворка.
Как вы сами упомянули, вордпресс уже умеет многое. Так зачем фронтендеры каждый раз пересобирают это сами на новом фреймворке с новой либой? Какой в этом бизнесу прок?
Сегодня Реаакт, завтра Solid, Vue, Angular - много способов провалидировать форму. Вот только сколько фреймворк не меняй, а валидация на сервере никуда не денется.
Не понятно что вы имеете ввиду под обработчиками. Но в целом, если вам надо отобразить HTML, то не надо его лишний раз сериализовать в json, чтоб потом развернуть обратно. Сразу получите html и вставьте куда надо. Особенно если у вас веб это единственный клиент. Так вы избежите дубликации логики, ведь все валидации, доступы, транзакции все равно будут на бэке. Фронт всегда работает с кэшом.
Даже если вы скажете, что вот там приложение мобильное - оберните часть страниц в WebView.
Если у вас интерактивный компонент типа Карты с маршрутами/графики с данными/анимациями/3д - получайте данные и рендерите на клиенте. Это нестандартные компоненты браузера. И то в каких-то случаях надо использовать Web Assembly.
вот вы долистали до 7й страницы и так и, видимо, так и не нашли товар который вас интересовал. Вам с какой целью иметь все предыдущие на странице? А что если вы долистаеете до 120 страницы? Сейчас наверное окажется что предыдущие можно прятать. Чем это от постраничного показа отличается? А если надо будет поделиться ссылкой на найденые товары? Или сохранить ее чтобы продолжить дальше с другого девайса? Снова будем листать? Или еще какую сложность придумаем? Кто вообще сказал что бесконечные страницы хороши где-то кроме сайтов с котиками, где предыдущие карточки не надо больше показывать? Пользователю важно видеть нужную информацию вовремя. Это можно сделать и пагинацией и 5-ю строками JS без реакта. Есть htmx на крайняк. Моя боль вообще не про сам реакт или эту интерактивность, а про структуру команд и как работает процесс разработки... Разделять фичи по слоям - плохая идея.
А что вы называете пользовательским опытом? Если страница загружается с prefetch и интерфейс обновляется так же бысто как с ajax - то что для пользователя изменится? А со стороны разработки что изменится? Сколько времени займет выставить 1 атрибут и распилить приложение на 2?
Эх, вы, дево-псы... как там DevSecFinBisOps поживает? Не пора ли уже похоронить этот термин? То о чем вы написали называется Continuous Delivery. Как следствие переименуем дево-псов в то, чем они являются - опсы обыкновенные и перестанем разыгрывать этот театр.
Просто, похоже, что скоро выкатят новую модель и надо будет ее как-то продать. Вот и будут рассказывать что новая версия понимает их на 20% лучше...
А поделитесь своими лайфхауами, как вы тяните оценки для больших и важных задач в wsjf. А то метод выглядит очень интересно и хотелось бы попробовать.
Там кажется в статье упоминается htmx...
В принципе то согласен. Но есть проблемка:
Те ребятки которые себя фулстеками считают и приходят на существующие продукты, они же не идут пилить существующий код на Java\php\python. Они начинают пилить свой "бэкенд" оборачивая существующие АПИ, делая тот самый SSR.
Это НЕ нормально.
Вы что, это же слишком сложно )
Это требует понимания что мы вообще в браузере выполняемся, и что фронт - это часть общего приложения и его надо рассматривать ВМЕСТЕ с бэком и БД и инфраструктурой.
А с СПА - можно закрыться в своем мирке и считать что вокруг ничего нет. Удел мидлов.
я не говорил что они отказываются от сахара вообще в пользу голого html.
Просто надо не запихивать целиком все в реакт, а делать виджеты. Да по другому чутка работает, но столько лишней сложности уходит. И htmx тут очень хорошо подходит. 99% веб приложений не нуждается в чем-то более сложном.
ССГ это хорошо, вот вы и вернулись к тому, о чем была статья изначально. Велком.
Только статья про Спринг, а не про JS фреймворки. И со стороны Спринга действительно проще делать SSG + htmx.
Проблема в том что SPA - это дефолтное решение. Фронтендерам не приходит в голову мысль что можно НЕ делать SPA, не тащить стейт менеджмент, не тащить рутер и тп. Попробуйте, вам понравится.
Верно и для всех других типов приложений. Любой Реакт\Некст ломается мгновенно, когда "Фронтендеры" перестают думать о структуре проекта.
Вот только те кто думают, быстро приходят к выводу что Реакт, а тем более СПА - это скорее плохо для 99% приложений.
у меня сложилось впечатление, что суть дискуссии утеряна и мы говорим о разных вещах.
Напомните пожалуйста в чем суть беседы сейчас? Иначе предлагаю свернуть это все.
Я не говорил, что АПИ веб компонентов легко использовать без оберток. Но уже есть готовые решения, которые добавляют минимум полезного, типа lit или stencil.
Да и что вы под рантаймом имеете ввиду?
Шаблоны есть уже встроеные в сами веб компонетны. Зачем городить еще свое что-то? Просто по тому что можем?
Я лично написал на них демку пошаговой боевки одной игры несколько лет назад. Да отличается от реакта, но выходить из зоны комфорта иногда надо. Там обычно точки роста.
Сегодня вокруг них столько всего есть, что разработка становится гораздо комфортней.
Все уже было разобрано другими, но мало кто осилил имплементацию. https://serzn1.github.io/micro-frontends/
В оригинальной книге есть пример с веб компонентами.
Вот тут тоже хорошо описано что по чем https://martinfowler.com/articles/micro-frontends.html
Попробуйте взглянуть на этот процесс с другой стороны. Если вы испытываете сложности, то скорее всего это знак, что вы что-то делаете не так. Просто остановитесь и подумайте.
Жмете газ, а машина не едет - проверьте, не пытаетесь ли вы по сугробам на кабриолете гонять.
Если среда сопротивляется - бесполезно дальше давить.
Подход с набором отдельных фронтов и общей UI-библиотекой — интересный, но на практике он уже близок к архитектуре микро-фронтендов. Даже если всё на React, остаётся масса тонких мест:
– Как быстро команда может внести правку в компонент, если он переиспользуется во всех фронтах?
– Что происходит, когда библиотеку обновляют? Как избежать цепной реакции поломок, версионирования, откатов?
– А если одна из команд решит использовать Astro или вообще уйдёт от React — переиспользование UI-компонентов уже не работает.
Такие зависимости сильно сказываются на скорости. Команды вроде бы разделены, но на деле — завязаны на общий код и инфраструктуру.
Мне ближе подход, где команда владеет всем стеком — от шаблона до схемы БД. Тогда можно доставлять фичи быстро, без синхронизаций, ожидания чужих изменений и с меньшим количеством багов.
Как ты думаешь, насколько предложенная тобой схема действительно ускоряет команды, если смотреть на разработку целиком — от идеи до продакшна?
в реальном екоммерс проекте, у вас как раз будет:
пара лендингов, каждый со своим стэком, т.к. они делались в разное время
каталог + поиск
чекаут форма
личный кабинет
система управления заказами
внутренняя документация
система управления складом
система управления нотификациями/рассылками
система учета финансов
документация для пользователей
внутренняя документация
еще десяток внутренних тулзов
Все это вместе - многостраничное приложение. Оно служит всем его пользователям, чтобы предоставлять не противоречивую информацию.
Я правильно понимаю, что по вашей логике, чтобы стили не ломались, вы предлагаете ВСЕ это засунуть в условное "next" приложение? Или делать статическую документацию на реакте, по тому что там есть чекаут форма?
Ну вот вы свели все снова в Реакту, хотя назвали его Next.js.
UI kit это хорошо, но не требует чтобы была только 1 имплементация. Библиотека компонентов может содержать имплементации для разных кейсов. Может быть и кнопка на реакте, vuew и хелпер для темплейта в бэке.
Вы похоже заранее пытаетесь применить DRY там где не надо. И жертвуете YAGNI выбирая Next для ВСЕГО проекта, хотя интерактивности может быть 1 страница, и ее можно было запилить сделав виджет и добавив скрипт тэг.
Хендлеры все же разные бывают. Нужно что-то более четкое. Уверен часть из них может быть просто ссылками + htmx, а другая решаться CSS. Так что уточните пожалуйста.
Валидация интерактивная конечно прикольная. Но 1 форма не должна требовать замены всего стэка. htmx выкатит скоро свой апи для плагинов. Уверен мы взглянем на эту проблему по новому. А еще есть старый добрый jQuery, используемый кстати в бутстрапе, который решает эту задачу декларативно. И бандл сильно меньше будет.
Я понимаю что все к Реакту привыкли. Уже выросло новое поколение разработчиков, которые не пробовали ничего другого, не видели как можно малым обойтись. Но просто представьте, что эта валидация - это подключение htmx + пара дата тэгов от бэка, который знает о валидации, переводах и связях между полями.
Вот занимательное видео на эту тему.
Да, к вам было, комменты почему-то не индентируются как надо.
Ну так доработки можно делать и в вордпрессе, и в других решениях.
Кстати, SPA by default - считается плохим тоном.
Вы про какие-то обработчики постоянно говорите. Можете пояснить что вы имеете ввиду?
В случае наличия серверной валидации, зачем нужно что-то более сложное чем htmx, если так уж перезагрузка страницы раздражает? Надо просто отправить форму и показать ответ. Это не требует преобразования формы в json 2 раза.
Про сложность работы с вордпрессом ничего не могу сказать, у меня мало с ним опыта. Но возможно сложность там появилась не на пустом месте.
Тут вопрос в том чем вы расплачиваетесь за это. Собрав весь гуи в 1 место, вы вставляете палки в колеса другим командам, которым надо разрабывать что-то параллельно с вами.
Таким образом, следующий шаг после МВП не отрезать фронт от бэка, а разделить фронт на микрофронты и виджеты. Что не подразумевает одного большого репозитория с реактом.
И даже там будут вопросы о целесообразности использования какого-то конкретного фреймворка.
Как вы сами упомянули, вордпресс уже умеет многое. Так зачем фронтендеры каждый раз пересобирают это сами на новом фреймворке с новой либой? Какой в этом бизнесу прок?
Сегодня Реаакт, завтра Solid, Vue, Angular - много способов провалидировать форму. Вот только сколько фреймворк не меняй, а валидация на сервере никуда не денется.
Не понятно что вы имеете ввиду под обработчиками.
Но в целом, если вам надо отобразить HTML, то не надо его лишний раз сериализовать в json, чтоб потом развернуть обратно. Сразу получите html и вставьте куда надо. Особенно если у вас веб это единственный клиент. Так вы избежите дубликации логики, ведь все валидации, доступы, транзакции все равно будут на бэке. Фронт всегда работает с кэшом.
Даже если вы скажете, что вот там приложение мобильное - оберните часть страниц в WebView.
Если у вас интерактивный компонент типа Карты с маршрутами/графики с данными/анимациями/3д - получайте данные и рендерите на клиенте. Это нестандартные компоненты браузера. И то в каких-то случаях надо использовать Web Assembly.
вот вы долистали до 7й страницы и так и, видимо, так и не нашли товар который вас интересовал. Вам с какой целью иметь все предыдущие на странице? А что если вы долистаеете до 120 страницы?
Сейчас наверное окажется что предыдущие можно прятать. Чем это от постраничного показа отличается? А если надо будет поделиться ссылкой на найденые товары? Или сохранить ее чтобы продолжить дальше с другого девайса? Снова будем листать? Или еще какую сложность придумаем?
Кто вообще сказал что бесконечные страницы хороши где-то кроме сайтов с котиками, где предыдущие карточки не надо больше показывать?
Пользователю важно видеть нужную информацию вовремя. Это можно сделать и пагинацией и 5-ю строками JS без реакта. Есть htmx на крайняк.
Моя боль вообще не про сам реакт или эту интерактивность, а про структуру команд и как работает процесс разработки... Разделять фичи по слоям - плохая идея.
А что вы называете пользовательским опытом? Если страница загружается с prefetch и интерфейс обновляется так же бысто как с ajax - то что для пользователя изменится? А со стороны разработки что изменится? Сколько времени займет выставить 1 атрибут и распилить приложение на 2?