у меня сложилось впечатление, что суть дискуссии утеряна и мы говорим о разных вещах. Напомните пожалуйста в чем суть беседы сейчас? Иначе предлагаю свернуть это все.
Я не говорил, что АПИ веб компонентов легко использовать без оберток. Но уже есть готовые решения, которые добавляют минимум полезного, типа 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?
DevOps это про культуру. А вы рассказываете про Опс. Что же вы 10 лет википедию не открыли? Культуру нельзя аутсорсить, её надо вырастить и внедрить в днк команды.
Все остальное в статье про ОПС. А про отдельный опс мы знаем только то, что 100% это будет боль и страдания. Именно по тому и появился DevOps.
+ Аутсорсерам по умолчанию не выгодно решать для вас проблему до конца. Им важно вас посадить на иглу и доить.
Ну и отдельным бонусом, это менталитет Опсов. Эти ребята при всей своей экспертности смотрят на картину совсем под другим углом. А в экономиках масштабирования это очень не правильно.
Решение этой проблемы - изменение культуры, опять же. Но это про пресловутый аджайл и коллаблрацию, которые только единицы СТО умеют строить(я про Европу сейчас, мне кажется в РФ с этим получше должно быть)
Ну можно еще изначально брать без подсветки все... Я себе собрал системник в прошлом году вообще без подсветки. Единственное что светится там - это видюха, но ее не я брал. Возможно у вас ограничен ассортимент и выбора мало, но теоретически он есть. Ну и не берите самое дешевое. Берите качественное.
Верно и для всех других типов приложений. Любой Реакт\Некст ломается мгновенно, когда "Фронтендеры" перестают думать о структуре проекта.
Вот только те кто думают, быстро приходят к выводу что Реакт, а тем более СПА - это скорее плохо для 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?
Вполне разумный подход. 90% сайтов должны быть так сделаны. Можно сдобрить htmx чтобы получить заветную интерактивность, когда придут первые деньги.
Иначе будет типичное не эффективное Г с кучей дублированного кода.
Абсолютно согласен с автором.
Вы не гугл. Вам это не надо.
DevOps это про культуру. А вы рассказываете про Опс. Что же вы 10 лет википедию не открыли? Культуру нельзя аутсорсить, её надо вырастить и внедрить в днк команды.
Все остальное в статье про ОПС. А про отдельный опс мы знаем только то, что 100% это будет боль и страдания. Именно по тому и появился DevOps.
+ Аутсорсерам по умолчанию не выгодно решать для вас проблему до конца. Им важно вас посадить на иглу и доить.
Ну и отдельным бонусом, это менталитет Опсов. Эти ребята при всей своей экспертности смотрят на картину совсем под другим углом. А в экономиках масштабирования это очень не правильно.
Решение этой проблемы - изменение культуры, опять же. Но это про пресловутый аджайл и коллаблрацию, которые только единицы СТО умеют строить(я про Европу сейчас, мне кажется в РФ с этим получше должно быть)
Ну можно еще изначально брать без подсветки все... Я себе собрал системник в прошлом году вообще без подсветки. Единственное что светится там - это видюха, но ее не я брал. Возможно у вас ограничен ассортимент и выбора мало, но теоретически он есть. Ну и не берите самое дешевое. Берите качественное.
Круто что у вас есть скил отпаять что не надо)
Ни разу. Он поставляется в разных вариантах. У меня монолитный черный без стекла, без подсветки. Могу фотку скинуть.
https://www.fractal-design.com/de/products/cases/focus/focus-2/black-solid/
не подключайте к материнке, или используйте софт для этого. Паяльник уже давно не нужен.
Fractal Focus 2, рекомендую)
Это вы про те, которые начали писать когда node.js появился?)