Комментарии 124
Кажется, вы не знаете что такое SSR...
Какая то видимо личная неприязнь к фронтендщикам у автора.
Может автор имел ввиду генераторы статических сайтов?
Мне так не показалось. У генераторов статических сайтов разве есть возможность включить ajax или websocket, как пишет автор. Причём, желательно, не доводя напильником, а прямо в рамках генерации? Всё-таки авторка имела в виду интерактивные сайты, а не чистую статику, как я понял из статьи.
может, вполне классические сайты на php? SSR - вроде бы про это.
А при чем тут статика? Чтобы сделать статику, бекенд не нужен. Достаточно одного верстальщика фрилансера. А в идеале такое вообще на тильде делать.
Вполне разумный подход. 90% сайтов должны быть так сделаны. Можно сдобрить htmx чтобы получить заветную интерактивность, когда придут первые деньги.
Иначе будет типичное не эффективное Г с кучей дублированного кода.
Абсолютно согласен с автором.
Вы не гугл. Вам это не надо.
А проблема, которую описывает автор существует?
Я просто что-то не вижу повального количества сайтов на реакте с полностью динамическим страницами. Как будто больше половины честно отдают страницы для отображения.
Даже если вы и видите сайты на реакте, скорее всего там будет настроен серверный рендеринг, чтобы отдавать всю страничку.
Чистые SPA без серверного рендеринга оюычно встречаются в веб-приложениях, которые нет смысла индексировать.
Вот это и есть SSR, когда на сервере стоит node и заранее выполняет работу браузера, чтобы SEO лучше была. Но от этого все преимущества фреймворков не исчезают, возможности SPA сохраняются в браузере, просто при начальной загрузке страницы посетителю приходит уже отрендеренный html.
Причем, каких-то особых отличий в разработке при этом может и не быть, по идее достаточно установить модуль, а в некоторых фреймворках это вообще из коробки, просто параметр mode ssr при сборке указывается и всё.
Конечно, это дополнительная нагрузка на сервер.
Что значит "вот это и есть"? А если нет node в стеке, то нет SSR? Сайты на PHP которые 15 лет назад писали, это не SSR? По вашему определению. Правильно я поняла? Как мне тогда стоит это назвать, что противопоставить SPA? Подскажите, я поправлю.
MPA
Да, понятно, согласна.
На самом деле рано соглашаетесь. SPA и MPA - это грубый критерий того, осуществляется ли при клике на раздел приложения/сайта переход на новую страницу, с полным ререндендерингом.
SSR - это больше про то, что выплевывается ли сначала вся верстка страницы с серверными данными, а не создаётся динамически из скрипта. И на той же пыхе использовались и используются шаблонизаторы при необходимости, которые как раз и являются тем, что сейчас начали называть SSR.
Все же шаблонизаторы отличаются от того, что называют сейчас SSR тем, что они не поддерживают гидратацию. Поэтому чтобы не путаться, результат работы классических шаблонизаторов в таком контексте называют MPA или как-то еще.
Вы говорите о серверных компонентах. Они по смыслу очень рядом с SSR, но это немного другое.
Серверные компоненты появились не более двух лет назад. Серверные фреймворки с поддержкой гидратации появились намного раньше, а без фреймворков это было доступно в React изначально, с помощью renderToString/hydrate. Это и стали называть SSR (в контексте SPA).
То, что React начал давать имена процессам, которые были известны разработчикам очень давно, я даже с этим спорить не буду. Для вордпрессов, пхпбб и прочих - это раньше просто называлось плагинами.
То, что Вы подметили важность гидратации, когда контент приложения отображается в режиме SSR, безоговорочный плюс. Но все-таки SSR - это больше про рендеринг основного контента сервером, а не клиентской либой.
Гидратация - это не когда контент отображается в режиме SSR, это умеют и обычные шаблонизаторы. При гидратации на пришедшую с сервера разметку автоматически навешиваются все обработчики, описанные в клиентском коде.
Такого классические шаблонизаторы делать не умеют, там надо явно вызывать скрипты инициализации для каждого компонента.
Я не припомню примеров из прошлого до реакта, где такое было, можете привести пример?
Гидратация - это не когда контент отображается в режиме SSR
Это все верно. Значит мы говорим об одном и том же.
Вот навскидку https://www.phpbb.com/customise/db/extension/bbcode_icons/.
Там процесс встраивания и в серверный код, а также работа ведется с клиентской частью: а именно навешиваются листенеры на разные пользовательские события.
Другим простейшим примером также может быть добавление компонента спойлер в bbcode в окно написания сообщения. Этому решению лет 15 минимум. Там также генерируется верстка и навешивается событие.
Но они же вроде бы просто автоматизируют добавление обработчиков на начальную разметку. То есть если применить компонент spoiler, то он из <div class="spoiler"> сделает <div onclick="...">...</div>. Но ведь он сделает это уже на клиенте, а не на сервере?
В SSR с гидрацией вы сразу получите итоговую разметку. Это может быть важно для скорости отрисовки, если речь не про спойлер, а про большой динамический компонент, например какой-нибудь top товаров в виде карусели, который надо показать максимально быстро и красиво до того, как отработает js.
Обработчики это ведь не только онклики, они могут дергать сторонние сервисы чтобы сформировать итоговую разметку.
И зачем я искал пример?:)
В общем, суть в том, что генерятся вставки и на html, и на js, именно при серверном рендеринге.
Я не нашел там кода, поэтому не могу понять как там выполняется на сервере js, чтобы получить итоговую разметку чтобы отдать ее пользователю. Ткните пожалуйста.
upd. нашел, смотрю)
Конечно, что Вы не найдете выполнение js на стороне сервера, потому что мы говорим в контексте php. Там php выполняется. На самом деле можно было бы и на престарелом ASP найти аналогичные примеры (там уже будет jscript/vbscript).
Итак, берем архивчик, ссылку на который я дал выше. В директории danieltj/bbcodeicons/adm/style/event есть файл acp_bbcodes_edit_fieldsets_after.html с таким содержимым:
<fieldset>
<legend>{L_ACP_BBCODE_FONT_ICON_LEGEND}</legend>
<dl>
<dt><label for="bbcode_font_icon">{L_ACP_BBCODE_FONT_ICON_LABEL}</label><br /><span>{L_ACP_BBCODE_FONT_ICON_EXPLAIN}</span></dt>
<dd>
<input type="text" name="bbcode_font_icon" id="bbcode_font_icon" value="{{ BBCODE_FONT_ICON }}" />
<i id="bbcode_icon_preview" class="icon fa-{{ BBCODE_FONT_ICON }}" style="font-size: 16px;" aria-hidden="true"></i>
</dd>
</dl>
</fieldset>
<script type="text/javascript">
document.addEventListener( 'keyup', function( e ) {
document.getElementById( 'bbcode_icon_preview' ).classList = "icon fa-" + document.getElementById( 'bbcode_font_icon' ).value;
});
</script>Так вот это содержимое будет встроено в страницу при ее рендеринге. Оно не загружается динамически, а именно выводится при загрузке страницы. В секции HTML мы видим создание элемента с id "bbcode_icon_preview", а в секции скрипта мы видим навешивание листенера на событие keyup на document, в котором идет взаимодействие с вновь созданными элементами. И вот вы получили и SSR, и самую классическую гидратацию.
Так называемые современные SSR — это и есть шаблонизаторы. Просто раньше это был код на PHP, а сейчас Node. И там и там в результате генерируется статический HTML, который отправляется клиенту с некоторым скриптом, который делает ту самую гидратацию. Суть одна, реализация и языки разные.
Сайты на PHP которые 15 лет назад писали, это не SSR?
Нет, это были просто сайты. Ну не 15, а 20 лет назад - SPA не было как устоявшейся концепции, поэтому почти любой сайт работал одинаково. Рендеринг всегда производился на стороне сервера, и не было нужны вводить специальную терминологию.
А когда появились SPA, то следом придумали засунуть node на сервер, и назвали это SSR.
И в общем, не обязательно node, есть другие, более легковесные решения, в том числе облачные как на cloudflare edges, которые рендерят html за микросекунды, и при этом вообще не требуют сервера. В частности, в NUXT очень легко такое организовать.
Вы предлагаете всё это выкинуть и вернуться к дедовским технологиям, потому что не хотите изучать новое.
Если я увижу что эти новые технологии позволят мне делать результат быстрее и как следствие я заработаю больше денег, то тогда захочу изучать новое =) А пока это не так. В теории оно всё прекрасно, на практике не вижу. Ни как пользователь, ни как участник и наблюдатель рынка разработки.
И я не предлагаю выкинуть. Я несколько раз в статье обозначила область применимости описываемой логики.
Проблема, которая обсуждается в статье, не про то на чьей стороне cpu расходуется, а в скорости разработки. Я обсуждаю проблемы заказчиков. А не проблему cpu. Ну придумали они механизм чтобы на сервере предгенерировать, ну и что? Это разработку ускорило? Нет.
А проблема того что сайты делаются долго и теперь для этого нужно минимум 2 человека, есть, да. Оно ещё ухудшается тем что заказчики идут у gpt спрашивать и тот расписывает: нужен фронтендер, нужен бекендер. Это уже сомнению не подвергается даже. Поэтому статья. А не потому что cpu на клиенте жалко.
Приведу пример. Вот у вас есть страница каталога интернет магазина. Сейчас они весьма динамические. Вы фронт для этой страницы на чем писать будете? Чтобы AJAX, обновление корзинок и всякая прочая красота?
Например, есть у вас первая страница каталога, которую вы сгенерируете на сервере. PHP там будет или любой другой язык - не важно.
Пользователь кликает на постраничнике следующую страницу. Происходит AJAX запрос на бэк. И что отдает бэк? Готовый HTML или JSON? Если первое, то вы употеете на это навешивать JS обработчики. Если второе, то вам нужно будет это рендерить на фронте и получается, что у вас идет дублирование HTML шаблонов на фронте и бэке и вам нужно будет их поддерживать.
Вот чтобы разделить отображение и данные, разделение на фронтовое приложение и бэкенд АПИ и придумали.
Для пагинации не нужен ни в коем случае никакой ajax, он вреден. При переходе на новую страницу добавляется get параметр page=2 и рендерится новая страница.
Вреден для чего?
Ну и второй вопрос: какая связь между урлом (Browser History) и подгрузкой данных AJAX-ом?
Тот же вопрос про InfinityScroll, когда новая пачка товаров подгружается по мере пролистывания страницы (так сделано в Ozon, например).
У вас написано, что вы в Яндексе работаете, посмотрите как это сделано на главной странице Яндекс.Маркета
Я написала достаточно ясно, что ajax не нужен, нужен переход на новую страницу, <a href='...?page=2'>, так понятней? При чём тут infinity scroll? Вы спросили про "Пользователь кликает на постраничнике следующую страницу", я на это и ответила.
Т.е. вы предлагаете заново перегружать всю страницу с меню, шапкой, и т.п. это точно хороший пользовательский опыт.
AJAX подгрузку я привел как пример необходимости поддерживать html шаблоны и на бэке и на фронте при вашем подходе. Будет это постраничник или кнопка "показать следующие 20 товаров" совершенно неважно.
Ужас! Это просто невозможно вынести! Страница вместе с шапкой перезагружается! Как люди только жили раньше! Ещё и на медленном интернете. Треш.
Почему-то ни одному разработчику интерфейсов (а сайт - это пользовательский интерфейс) вне веба не приходит в голову перерисовывать полностью весь вьюпорт при частичных изменениях (не считая GUI immediate-режима). Потому что это видно глазами, а в вебе еще и создает задержки на скорость взаимодействия.
Ограничения веба - это именно ограничения, и то что их обходят - это хорошо. А треш - это то что вы описываете.
А что вы называете пользовательским опытом? Если страница загружается с prefetch и интерфейс обновляется так же бысто как с ajax - то что для пользователя изменится? А со стороны разработки что изменится? Сколько времени займет выставить 1 атрибут и распилить приложение на 2?
Пользовательский опыт:
Я хочу листать товары в категории интернет магазина и ожидаю, что новые товары будут подгружаться по мере того, как я долистываю ленту до конца. Как вы это будете реализовывать?
вот вы долистали до 7й страницы и так и, видимо, так и не нашли товар который вас интересовал. Вам с какой целью иметь все предыдущие на странице? А что если вы долистаеете до 120 страницы?
Сейчас наверное окажется что предыдущие можно прятать. Чем это от постраничного показа отличается? А если надо будет поделиться ссылкой на найденые товары? Или сохранить ее чтобы продолжить дальше с другого девайса? Снова будем листать? Или еще какую сложность придумаем?
Кто вообще сказал что бесконечные страницы хороши где-то кроме сайтов с котиками, где предыдущие карточки не надо больше показывать?
Пользователю важно видеть нужную информацию вовремя. Это можно сделать и пагинацией и 5-ю строками JS без реакта. Есть htmx на крайняк.
Моя боль вообще не про сам реакт или эту интерактивность, а про структуру команд и как работает процесс разработки... Разделять фичи по слоям - плохая идея.
В случае бесконечной подгрузки как минимум остается возможность браузерного поиска по странице. Я лично им пользуюсь.
Именно так. Бесконечный скролл нужен для таких кейсов как инстаграм, дзен или маркет. Когда цель не в том чтобы человек нашёл то что ему нужно, а в том чтобы он залип, и думскроллил! Не может быть пользовательского сценария "хочу листать чтобы было красиво", есть пользовательский сценарий "хочу решить свою конкретную задачу, и чем быстрее тем лучше". Пагинация удобна тем что можно чётко увидеть сколько ты страниц пролистал и сколько осталось. Можно решить для себя "5 страниц посмотрю и уйду". С бесконечным скроллом не так, он придуман не для пользователей, а для сервиса чтобы поднимать его метрики!
То чем занимется автор этой ветки -- это подгон вопроса под ответ. Если пойти чуть дальше, пользователям не нужна динамичность, им даже красота не нужна. Им плевать перезагружается там что-то или нет. Им нужно чтобы было предсказуемо, привычно, просто, чтобы можно было задачу свою решить. Всё остальное надумано для того чтобы оправдать сложность реализации (и свою зарплату).
Кто-то думает что выбор стоит между "красиво и качественно" и "некрасиво и некачественно", но выбор стоит между "дёшево и сердито", и "монструозное поделие с багами, где надо чистить кеш и нажимать F5". А баги там сложно не засадить, нужна внимательность и перфекционизм. У большинства её нет, либо нет времени вылизывать. Поэтому имеем что имеем. Взять за пример рекламный кабинет фейсбука, всё сложное, рокетсайнс, но баг на баге. И там не с улицы фронтендеры работают. Ну может у местных хабравчан конечно повыше уровень, знают о чём говорят, и это просто и то просто, и проблема из пальца высосана.
Давным давно, я как-то попросил админа поставить фотошоп на корпоративную тачку. Он вместо того, чтобы это просто сделать 20 минут мне рассказывал почему мне не нужен фотошоп.
Я вам задал конкретный вопрос:
- У вас есть страница с первоначальным контентом. HTML. На страницу подгружается JS, который делает её динамической.
- Вам нужно подгрузить новый контент без перезагрузки страницы. Как вы будете это делать? Вы будете загружать уже готовый HTML и вставлять его в какой-нибудь блок на странице и навешивать обработчики событий или вы будете дергать API, получать JSON и рисовать все на фронтенде?
Могу предположить, что у автора статьи простые проекты, которые не предусматривают такую сложную функциональность в виде порционной загрузки данных. Притом безоговорочно и даже не обсуждается, будет только так и больше никак.
Всё что выходит за рамки условных "лендингов", сразу вызывает множество вопросов...
Я бы еще понял, если бы топили за какой-нибудь CMS Drupal или Wordpress, где есть механизмы динамической загрузки HTML и стандартные средства на уровне API фреймворка для этого. Но писать всё это вручную - считай подвиг совершить. Но повторюсь, такое и не требуется, насколько понимаю.
Если ориентироваться на список запущенных проектов на ее сайте в портфолио, то так и есть. Это то, что обычно называют "сайт на вордпрессе под ключ". Только зачем-то самописное, вордпресс давно уже покруче будет чем вся эта простенькая HTML5 валидация, нативные алерты, подключенный скрипт-тегом фэнсибокс (мило).
Можно ли так делать проекты для малого бизнеса за три копейки? Да вполне, хотя и непонятно чем ворпдресс не угодил.
Стоит ли поливать помоями тех, кто делает что-то иначе? Это на совести авторки.
Свои покажите, а мы оценим.
А насчёт вордпресса, я всегда говорю что всё что можно сделать на CMS, нужно делать на CMS. Никогда не возьмусь за работу, которую не считаю нужным делать кастомной разработкой.
Тут вопрос в том чем вы расплачиваетесь за это. Собрав весь гуи в 1 место, вы вставляете палки в колеса другим командам, которым надо разрабывать что-то параллельно с вами.
Таким образом, следующий шаг после МВП не отрезать фронт от бэка, а разделить фронт на микрофронты и виджеты. Что не подразумевает одного большого репозитория с реактом.
И даже там будут вопросы о целесообразности использования какого-то конкретного фреймворка.
Как вы сами упомянули, вордпресс уже умеет многое. Так зачем фронтендеры каждый раз пересобирают это сами на новом фреймворке с новой либой? Какой в этом бизнесу прок?
Сегодня Реаакт, завтра Solid, Vue, Angular - много способов провалидировать форму. Вот только сколько фреймворк не меняй, а валидация на сервере никуда не денется.
Я не совсем понял, ко мне ли обращен ваш ответ, если ко мне, то я не знаю кто и зачем что-то пересобирает просто ради смены фреймворка. Если что-то решается одним фрилансером-верстальщиком и готовым шаблоном вордпресса, то так и надо делать.
Клиентские фреймворки берут для проектов, требующих поддержки и доработок под специфические требования. Кроме валидации там еще много чего, чего нет в вордпрессе - он ведь не SPA и там нельзя легко навесить на разметку те же банальные обработчики, которых может быть очень много.
Ну и клиентская валидация не равна серверной, серверные валидации гораздо сложнее, могут опираться на кучу third-party систем, о которых фронтенду знать не нужно. Клиентские фреймворки поддерживают и клиентскую и серверную валидацию, в том числе одновременно.
На вордпрессе без спец. решений на мало мальски сложных формах уже можно начать сходить с ума если руками писать все это.
Да, к вам было, комменты почему-то не индентируются как надо.
Ну так доработки можно делать и в вордпрессе, и в других решениях.
Кстати, SPA by default - считается плохим тоном.
Вы про какие-то обработчики постоянно говорите. Можете пояснить что вы имеете ввиду?
В случае наличия серверной валидации, зачем нужно что-то более сложное чем htmx, если так уж перезагрузка страницы раздражает? Надо просто отправить форму и показать ответ. Это не требует преобразования формы в json 2 раза.
Про сложность работы с вордпрессом ничего не могу сказать, у меня мало с ним опыта. Но возможно сложность там появилась не на пустом месте.
Ага, понял. Я не в этом треде, а в других в этом же топике, приводил примеры доработок, которые намного сложнее сделать без компонентной системы в каком-либо виде.
Один пример сходу - если у вас кастомный, брендированный дизайн, то его дадут вам в виде юайкита, побитого на компоненты. Из которых собраны экраны. В фотошопе никто давно страницы не рисует. И хорошо бы их именно так и реализовывать, чтоб кнопка в одной папочке лежала и одним импортом вставлялась только туда, куда надо.
htmx тоже от этого страдает, можно посмотреть на частоту появления вопросов типа "а как мне вставить датагрид/диалог/что-то еще мало мальски динамическое" на реддите. Хотя это конечно намного более продвинутое решение, чем самописный MPA фреймворк непонятно на чем, как в этой статье рекомендуется.
SPA by default давно не требуется по умолчанию. Перед стартом проекта нужно определить предполагаемое количество интерактива и форм на нем. И если есть хоть небольшая вероятность, что интерактив будет расти, лучше сразу делать либо SPA для интерактивных страниц + серверный рендеринг для контентных, либо взять Next.js или аналог, и там из коробки можно создавать смешанные приложения, где часть страниц (или даже частей страниц) рендерится клиентом, а часть - сервером.
Обработчики - это ну.. обработчики. Вот есть у вас компонент с кастомными обработчиками, что проще - написать <component onCustomEvent="handleSomething"> или где то рядом приколхоживать <script>document.querySelector('#component_instance_1').init({ onCustomEvent: handleSomething }).
А если там с десяток таких компонентов на странице, и всем нужно что-то свое прицепить? На условных сайтах на вордпрессе такое может не часто надо. А так вообще регулярно требуется.
В случае наличия серверной валидации, зачем нужно что-то более сложное чем htmx, если так уж перезагрузка страницы раздражает?
Это валидация формы, серверная в данном случае. Есть еще кейсы для клиентской, живой валидации. Хорошее чтиво на тему есть у контура - https://guides.kontur.ru/principles/forms/validation/#Vidi_validatsii
Ну вот вы свели все снова в Реакту, хотя назвали его Next.js.
UI kit это хорошо, но не требует чтобы была только 1 имплементация. Библиотека компонентов может содержать имплементации для разных кейсов. Может быть и кнопка на реакте, vuew и хелпер для темплейта в бэке.
Вы похоже заранее пытаетесь применить DRY там где не надо. И жертвуете YAGNI выбирая Next для ВСЕГО проекта, хотя интерактивности может быть 1 страница, и ее можно было запилить сделав виджет и добавив скрипт тэг.
Хендлеры все же разные бывают. Нужно что-то более четкое. Уверен часть из них может быть просто ссылками + htmx, а другая решаться CSS. Так что уточните пожалуйста.
Валидация интерактивная конечно прикольная. Но 1 форма не должна требовать замены всего стэка. htmx выкатит скоро свой апи для плагинов. Уверен мы взглянем на эту проблему по новому. А еще есть старый добрый jQuery, используемый кстати в бутстрапе, который решает эту задачу декларативно. И бандл сильно меньше будет.
Я понимаю что все к Реакту привыкли. Уже выросло новое поколение разработчиков, которые не пробовали ничего другого, не видели как можно малым обойтись. Но просто представьте, что эта валидация - это подключение htmx + пара дата тэгов от бэка, который знает о валидации, переводах и связях между полями.
Вот занимательное видео на эту тему.
Библиотека компонентов может быть на любом фреймворке, не обязательно на реакте. Она может быть даже в классическом MPA, просто там ее нельзя полноценно реализовать.
Сейчас в ходу есть целый ряд headless библиотек компонентов (https://headlessui.com/, https://www.radix-ui.com/, https://mantine.dev/), предоставляющих одинаковые контролы для разных фреймворков. Это на мой взгляд правильно, но необхлдимость их применения ограничена - чаще всего это надо на старых проектах с наслоениями из кучи разных технологий, которые нужно привести к одному виду. В этом случае там не будет на одной странице одновременно нескольких фреймворков.
Далее, если перечитаете, я не предлагаю Next. Я привел его как альтернативный вариант. Отдавать контент под индексацию можно чем угодно. Если это будет Next вы просто получите больше плюшек.
По валидации повторюсь, если делать лендинг с одной формой, можно сделать ее как угодно. Если посложнее, с зависимыми полями, с динамическими полями - уже не получится без написания самопального аналога библиотеки управления формами.
Хендлеры все же разные бывают. Нужно что-то более четкое. Уверен часть из них может быть просто ссылками + htmx, а другая решаться CSS. Так что уточните пожалуйста.
Пример - onClear евент на компоненте, который его не поддерживает. Например на обычном текстовом инпуте.
htmx я использовал на реальных проектах, он предполагает разработку в постраничной парадигме без выделения компонентов. Из-за этого у него тоже есть ограничения сверху по сложности разрабатываемого сайта/приложения.
в реальном екоммерс проекте, у вас как раз будет:
пара лендингов, каждый со своим стэком, т.к. они делались в разное время
каталог + поиск
чекаут форма
личный кабинет
система управления заказами
внутренняя документация
система управления складом
система управления нотификациями/рассылками
система учета финансов
документация для пользователей
внутренняя документация
еще десяток внутренних тулзов
Все это вместе - многостраничное приложение. Оно служит всем его пользователям, чтобы предоставлять не противоречивую информацию.
Я правильно понимаю, что по вашей логике, чтобы стили не ломались, вы предлагаете ВСЕ это засунуть в условное "next" приложение? Или делать статическую документацию на реакте, по тому что там есть чекаут форма?
Если все эти приложения связаны единым UI, то я бы такое реализовал набором отдельных фронтендов, какие-то в виде SPA, какие-то нет. UI библиотека и все остальное , что хочется пошарить в этом случае выносится в отдельный пакет.
Но можно и монорепой, если сможете подружить ее со своим ci. В монорепе есть свои плюсы, и для них существуют хорошие инструменты управления (https://nx.dev/).
Повторю в третий, и надеюсь последний раз, что статику, включая документацию, можно отдавать чем угодно. В том числе и Next/Astro или аналогами.
Подход с набором отдельных фронтов и общей UI-библиотекой — интересный, но на практике он уже близок к архитектуре микро-фронтендов. Даже если всё на React, остаётся масса тонких мест:
– Как быстро команда может внести правку в компонент, если он переиспользуется во всех фронтах?
– Что происходит, когда библиотеку обновляют? Как избежать цепной реакции поломок, версионирования, откатов?
– А если одна из команд решит использовать Astro или вообще уйдёт от React — переиспользование UI-компонентов уже не работает.
Такие зависимости сильно сказываются на скорости. Команды вроде бы разделены, но на деле — завязаны на общий код и инфраструктуру.
Мне ближе подход, где команда владеет всем стеком — от шаблона до схемы БД. Тогда можно доставлять фичи быстро, без синхронизаций, ожидания чужих изменений и с меньшим количеством багов.
Как ты думаешь, насколько предложенная тобой схема действительно ускоряет команды, если смотреть на разработку целиком — от идеи до продакшна?
Я могу сказать лишь что это рабочая и популярная в энтерпрайзе схема. Headless UI либа решает вопрос с разными фреймворками для разных проектов, но она сложнее в разработке и поддержке (если своя). Хотя обычно компании все же стремятся придерживаться одного стека, и тогда либу можно взять под фреймворк.
Поддерживать версионирование и обратную совместимость компонентов естественно геморойно, но это так в любых публичных API. На крупных проектах под жто иногда выделяется отдельная команда, иногда решается на уровне лидов команд.
Если делать монорепу, то для ui либы можно пропустить момент с выкладкой в npm/nexus и сильно упростить ее правки/доставку в проекты - будут прямые импорты и не надо будет ее билдить в пакет. Это крайне удобно, но команды должны быть или темно связаны, или дисциплинированы чтобы пользоваться такой свободой с умом.
Мне ближе подход, где команда владеет всем стеком — от шаблона до схемы БД. Тогда можно доставлять фичи быстро, без синхронизаций, ожидания чужих изменений и с меньшим количеством багов.
Ну если команды поделить по проектам, то примерно так и будет, с поправкой, что бек отделен от фронта внутри каждого проекта. Это не создает сложностей при разработке - чаще наоборот, бек не хочет заниматься фронтом, а фронт - беком. И не создает особых сложностей при выкатке - катимся либо вместе одновременно, либо сам качусь когда мне удобно (если правки чисто фронтовые).
В сумме весь стек так и остается у одной команды, пусть и с разделением специализации
Тут 2 варианта реализации я буду выбирать один из них с точки зрения того что именно подгружается и дальнейшей работы с этим. Если просто статическая инфа без поведения (для примера -- это может быть подгрузка логов), то HTML, если там что-то посложнее (например подгрузка событий в календарь), то JSON.
Не понятно что вы имеете ввиду под обработчиками.
Но в целом, если вам надо отобразить HTML, то не надо его лишний раз сериализовать в json, чтоб потом развернуть обратно. Сразу получите html и вставьте куда надо. Особенно если у вас веб это единственный клиент. Так вы избежите дубликации логики, ведь все валидации, доступы, транзакции все равно будут на бэке. Фронт всегда работает с кэшом.
Даже если вы скажете, что вот там приложение мобильное - оберните часть страниц в WebView.
Если у вас интерактивный компонент типа Карты с маршрутами/графики с данными/анимациями/3д - получайте данные и рендерите на клиенте. Это нестандартные компоненты браузера. И то в каких-то случаях надо использовать Web Assembly.
Ну в целом так работает большая часть интернета, как-то живём с этим 30 лет. Браузеры настолько быстро работают с обычным HTML с сервера, что никакой рендеринг JS-шаблона с этим не сравнится. Если пользователь уже был на странице, к повторному рендерингу 90% всех ресурсов уже будет лежать в кеше (особенно если его грамотно настроить).
Если всё же не хочется перерисовывать шапку/подвал, то есть решения — фрагментарные обновления. Сделали запрос, получили HTML-ответ, достали кусок с товарами и вставили в нужное место. Проблема с обработчикам? Можно делегировать на window/document/body, можно в метаданных (data-атрибутах) передавать. А вообще веб-компоненты сами инициализируются при парсинге. Под это есть разные инструменты, от pjax и unpoly, до htmx, alpine-ajax и т.д.
Конечно они быстрее работают с готовым HTML. Только как то упускается, что перед этим этот HTML надо сгенерить на сервере. Что далеко не бесплатно и не моментально.
Не упускается. Само собой на генерацию HTML нужно время. Но и на генерацию JSON ответа время тоже нужно. HTML-ответ уже готов к рендерингу, а ещё его можно стримить. JSON-ответ нужно передать в скрипт для отрисовки.
Разница по времени подготовки HTML и JSON на сервере на самом деле не такая большая. Есть бенчмарк, где HTML оказался быстрее. Но разница такова, что ей можно пренебречь. HTML можно готовить фрагментарно. Неизменяемые части можно заранее пререндерить в файлы и отдавать клиенту без запуска рендерера.
Ну и Node — не лучшее решение для рендеринга HTML, другие языки справляются лучше и быстрее.
То, что динамический HTML готовится быстрее JSON - сомнительное утверждение. Бенчмарков у меня нет, но я такого в жизни не встречал. С чего ему быть быстрее, если для JSON обычно нужно вытащить поля из базы и отдать как есть, а для HTML - дополнительно прокинуть эти вытащенные поля в строковой шаблон? При этом делать это на каждый запрос.
Ну и Node — не лучшее решение для рендеринга HTML, другие языки справляются лучше и быстрее.
Тоже не самое очевидное утверждение, но даже если так - при использовании Node для этих целей, кроме скорости рендеринга мы получаем один язык для шаблонов и динамики, со всеми его преимуществами - удобный проброс данных, удоная гидратация, то же самые server components позволяют организовать серверный рендеринг с динамическими островками.
Я понимаю, что можно сделать все и без этого, но это просто удобнее и быстрее.
То, что динамический HTML готовится быстрее JSON - сомнительное утверждение. Бенчмарков у меня нет, но я такого в жизни не встречал.
Я как раз привёл ссылку на такой бенчмарк.
С чего ему быть быстрее, если для JSON обычно нужно вытащить поля из базы и отдать как есть, а для HTML - дополнительно прокинуть эти вытащенные поля в строковой шаблон? При этом делать это на каждый запрос.
Извлекая данные из базы, вы оперируете структурами данных языка. Для отправки данных на клиент их нужно сериализовать в JSON-строку. На сериализацию тратится достаточно много времени, потому что происходит рекурсивный обход структуры и преобразование в строку. Это время сравнимо с конкатенацией строк с фрагментами HTML, что на низком уровне происходит с шаблонизаторами.
Тоже не самое очевидное утверждение
Я исхожу из результатов такого бенчмарка. Фреймворки на JS/TS в нём далеко от топовых строчек, которые в основном занимает Rust, C++, Java, Go и PHP.
кроме скорости рендеринга мы получаем один язык для шаблонов и динамики
Согласен, один язык для фронта и бэка может быть полезен.
удоная гидратация
Честно говоря, для меня гидратация антипаттерн. Мы выполняем один и тот же код сначала на сервере, чтобы получить HTML. Затем на клиенте, чтобы получить виртуальное представление компонентов, построить дерево, привязать данные и обработчики.
На клиент идёт немаленький рантайм, который забивает основной поток, конфликтуя с всякими трекерами, аналитикой и другими скриптами, которые бизнес обязательно захочет добавить. И всё для того, чтобы создать в памяти дерево компонентов фреймворка, большинство из которых просто отображают статический текст и картинки.
Минусом к этому идёт плохой с точки зрения UX момент, когда страница отрендерилась и видна пользователю, а гидратация ещё в процессе и ничего не работает. Поэтому я больше сторонник статической генерации и серверного рендеринга с островами.
Всё-таки пагинация и инфинити скроллинг - это разные концептуальные решения. Второе - однозначно про рендеринг с помощью js.
А что там по бекенду?
Кто такие современные бэкендеры? Те кто берут монгу + nest и потом диву даются, что продукт не выдерживает 10к rps и 5к одновременных пользаков?
А дизайн и ux? Это наверное про Яндекс.Плюс, в котором надо быть гением, чтобы отключить подписку и когда найти, то три раза нажать отключить? Или про интерфейс, в котором модальные окна на каждый чих и пук и серые буквы на сером фоне? Про доступность я вообще молчу, нам же на фон надо паралакс навесить и чтобы контент со всех возможных сторон вылетал и всплывал на скроле.
Это статья набор стереотипов 5-10 летней давности, которая претендует на что? Что надо брать htmx и serverless для фронта и все будет хорошо? Что вместо бека можно в txt сохранять? Или что вместо ui kit можно использовать нативные браузерные стили?
И очень интересно посмотреть сколько мвп выжили и сколько потом по итогу не переписали с нуля и по итогу не превратились то самое зло оверхедное.
Вы говорите про htmx или unpoli?
Если все сводится в итоге к тому, чтобы сделать из бэкендеров фуллстеков, то что мешает сделать наоборот. Берем фронтендера, который поднимает бэкенд на nodeJS и пишет уже на знакомом ему JS/TS. Если речь про простые бэкенды/фронтенды, то в чем проблема? Если декомпозировать приложение, то это будет набор CRUD-контроллеров с парой методов посложнее. И туда еще можно прикрутить SSR)
Да ничего не мешает. Не вижу противоречий. Только это не задача заказчика сделать кого-то из кого-то, он возьмет готового. И это ведь не самое главное. Самое главное- результативность, скорость, адаптивность. Если при описанном подходе можно делать всё так же быстро, как при описанном мной, то почему нет.
Мне REACT сразу, при первом знакомстве, показался странным. С одной стороны всё объединяется и изолируется в компоненте (что хорошо), с другой стороны - смешивается представление с логикой управления. По существу там вообще нет HTML-кода, он заменен на js-функции, а то, что мы видим как похожее на HTML, является синтаксическим сахаром - компактной оберткой js-функций. В итоге мы не можем верстку просто отдать верстальщику, такой версткой должен заниматься скорее программист, чем верстальщик.
В итоге для веб-сайтов (не приложений) я сейчас перешел на использование HTMX. В большинстве случаев мне его хватает. Библиотека очень легкая, работать с ней просто и приятно.
Вы используете при организации кода на сайте компоненты, ui-kitы?
Если да, можете рассказать, как организовать аналог SPA-шного ui-kitа в парадигме MPA? С переиспользованием компонента целиком(а не только разметки), с изоляцией стилей на уровне компонента, с подключением на нужных страницах только тех компонентов, которые на ней используются. +, как организуется их жизненный цикл.
Или все это вам не нужно?
Вы используете при организации кода на сайте компоненты, ui-kitы?
Лично я в своих проектах использую bootstrap и готовые шаблоны (с wrapbootstrap), из них собираю итоговый интерфейс.
По второй части давайте переформулируем вопрос с точки зрения задачи бизнеса/продукта а не "как сделать то же самое". Какую задачу вы решаете?
Раз вы используете готовые юайкиты, вы не могли не столкнуться с задачей их кастомизации под требования дизайна. Другие паддинги, другие наборы иконок, другая типографика и т.д. Какими корявыми оверрайдами кастомизируются готовые решения, включая бутстрап, знают все, кто пробовал вообще хоть что-то делать по заданным дизайнам.
Если вы не сталкивались - либо у вас нет кастомных дизайнов вообще, либо вы их делаете под бутстрап. Ну либо вам не надо ничего кастомизировать сложнее кнопки и поля ввода.
По второй части как-то даже странно отвечать, но ок:
Нет изоляции стилей. Подрубаете любой готовый компонент, который нецелесообразно самим писать с нуля (скажем, продвинутое поле ввода номера телефона). После чего надеетесь, что он не использует пересекающиеся с вами стили. А если раскорячил и вы заметили - пишете те самые корявые оверрайды. Особенно весело если там :not(div) какой-нибудь.
Нет нормального переиспользования. Тогда вы плодите копипаст, и в случае правок, делаете их не в одном месте, а в нескольких (или в куче, как это обычно бывает) и надеетесь, что нигде не ошиблись.
Нет поддержки жизненного цикла. Ну тут интересно как вы ими вообще тогда управляете. Что-то типа <script>initSlider({ element: '#mySlider' })</script> перед закрывающим body? Ну удачи когда у много таких компонентов на одной странице.
Нет импорта компонента с поддержкой tree shaking? Тогда либо вы их сразу все тащите на каждую страницу одним жирным бандлом, либо делаете эту работу своими руками.
Нужно ли пояснять, что все перечисленное - это как раз время бизнеса, отнятое у его бизнес-задач?
Это даже не касаясь сомнительного утверждения, что 1 фронт + 1 бек дороже аналогичного фулстека. Это не так, за ту же цену или дешевле у вас будет "фулстек" с перекосом в одну из областей, который другую область не будет знать даже на уровне мидла. У вас видно, что перекос в сторону бекенда.
Раз вы используете готовые юайкиты, вы не могли не столкнуться с задачей их кастомизации под требования дизайна.
Конкретно в этом случае нет требований дизайна. Если я работаю с шаблоном, то работаю без дизайна. Если есть дизайнер, то нет шаблона. Я пробовала и так и так, и в итоге пришла к тому что дизайн делаю только для лендингов, а внутренние личные кабинеты делаю на шаблонах, без привлечения дизайнера. Тут нужен только UX, тот кто соберёт прототип без дизайна, чтобы компоновку продумать. Если нужно что-то подправить в одном месте, то я прям там пишу style (да-да, фу). Проблема делать что-то сложное с дизайном в том, что при изменении (а это постоянно) цикл правок затрагивает весь стек: дизайн, вёрстка, бек.
продвинутое поле ввода номера телефона
В шаблонах обычно это предусмотрено, они идут сразу со всеми inputmask, select2 и прочим.
Нет нормального переиспользования. Тогда вы плодите копипаст,
Зачем копипаст? Это решается шаблонизатором, например jinja2, там есть наследование, includ'ы есть и макросы. Скрипты тоже можно подключать так же, через шаблонизатор.
Нет импорта компонента с поддержкой tree shaking
Выше написала. Плюс это вопрос про оптимизацию, оптимизацией нужно заниматься по мере необходимости, иначе она преждевременная. Напомню, что мы говорим про стартапы и MVP. По поводу большого бандла - а в SPA он не большой? Да и он кешируется, не вижу проблемы тащить на каждую страницу, скачается один раз.
время бизнеса, отнятое у его бизнес-задач?
Время у бизнеса отнимает как раз оверинжиниринг и попытка предусмотреть всё и сделать "идеально", а не максимальное упрощение.
О чем и речь. Так и пишете, что ваш подход работает только на лендингах и админках без дизайна. Не стоит думать, что веб-разработка этим ограничивается.
В шаблонах обычно это предусмотрено, они идут сразу со всеми inputmask, select2 и прочим.
Как может быть предусмотрено, если вдруг ваш select2 в следующей версии добавит селектор, который пересечется с одним из ваших. Сидеть на одном компоненте одной и той же версии? А если незнакомый компонент - надеяться что все будет хорошо?
Зачем копипаст? Это решается шаблонизатором, например jinja2, там есть наследование, includ'ы есть и макросы. Скрипты тоже можно подключать так же, через шаблонизатор.
Покажите пример скрипта, который вы подключаете инклудом. На примере поля формы желательно. Инициализацию конкретного динамического компонента вы же не инклудами подключаете?
Выше написала. Плюс это вопрос про оптимизацию, оптимизацией нужно заниматься по мере необходимости, иначе она преждевременная. Напомню, что мы говорим про стартапы и MVP. По поводу большого бандла - а в SPA он не большой? Да и он кешируется, не вижу проблемы тащить на каждую страницу, скачается один раз.
Если "выше" - имеется в виду ручные инклуды, да судя по всему не один на компонент, да плюс <script> вставки с ручной инициализацией, то это супер решение конечно.
А что на стартапах и MVP не нужно предусмотреть возможность нагрузки? Там не важна скорость первого взаимодействия, которую ваш мегабандл рушит за счет нагрузки на scripting? JS так то однопоточный.
В современных SPA бандл не большой. Он не будет больше аналогичного велосипеда, который вы напишете, когда упретесь в ограничения своего подхода (читай, когда нужно чтото сложнее лендинга и админки на бутстрапе). И кешироваться он будет лучше вашего мегабандла, который будет инвалидироваться на каждую правку.
А если нагрузка вдруг возникнет, все переписывать? Ну открою секрет, тот кто за вами потом переписывает - это я. В целом своими действиями вы развиваете рынок труда, и лично мне грех жаловаться.
А если нагрузка вдруг возникнет, все переписывать?
Nice problem to have, к сожалению реальной жизни почти никогда не встречается. Намного же чаще встречается обратное, пока программисты занимаются технодрочерством, у стратапа заканчиваются деньги или мотивация, не добежав до первых пользователей.
Круто че. А если встретятся? Ну вдруг ваш стартап, который вы так дешево и грамотно написали, стрельнет? Видимо у вас таких не было, раз так пишете?
Какая вероятность того что "стрельнет"? Ничего само по себе не стреляет. Обычно трафик покупают, и этот напор можно регулировать. Даже если есть виральные механики, там всё равно не будет взрывного роста. Это очень и очень большая редкость. Перемножаем вероятность "стрельнет" (p, близкое к нулю) на ресурсы которые нужно потратить чтобы это предусмотреть и сравниваем с перемноженной вероятностью (1-p) на ресурсы если не предусматривать. И выбираем.
Даже если эта вероятность сработает, то будут и деньги и мотивация чтобы что-то там переделать. Это априори не работа в стол. И не так оно страшно, даже если потребует времени.
Я была CTO в проекте с выручкой в миллион долларов, где сделала всё так как пишу. И нам даже лень переписывать было. Там и с точки зрения дизайна из-за постоянных изменений всё стало выглядеть так себе, мы называли его "франкенштейн". И ничего. Это всё не главное.
Судя по тому, что вы пишете - вы разрабатываете заведомо одноразовые проекты. Я не осуждаю - в этом случае можно писать хоть ногами.
Только к чему весь этот негатив про фронтендщиков, еще и с историческим экскурсом. Вы же не занимаетесь фронтендом. А есть масса проектов, где им надо заниматься.
Ага. 1) в корпорациях 2) там где действительно нужно приложение в браузере. Я об этом сразу и написала. Проблема в том что остальные используют инструмент не по назначению, и из-за этого теряют время и деньги. Всё.
Корпорации и другие компании у которых бюджет побольше, чем у пиццерии на углу, тоже запускают стартапы. И там к ним могут быть совсем иные требования. Например там могут быть дизайн-гайдлайны к продукту. Необходимость поддержки смены темы под требования партнеров. И еще куча всего, что в представлении заказчика обеспечит конкурентность при выводе продукта на рынок.
То, что вы понимаете под стартапами и MVP какой-то примитив (в технологическом плане), это исключительно ваши представления об устройстве мира.
А пренебрежительное отношение к коллегам на этих представлений, говорит уже лично о вас. И не в положительном ключе.
плюс <script> вставки с ручной инициализацией, то это супер решение конечно
Вы много пишите о <script>, изоляции, переиспользовании и прочем. Всё это решается веб-компонентами, если нужен динамический компонент с изолированной разметкой, стилями и логикой, жизненным циклом, автоматической инициализацией без ручного вызова скрипта и прочими прелестями. Полученный веб-компонент вставляется в шаблоны как любой другой HTML-элемент.
Вы пробовали их использовать для чего либо, сложнее простых виджетов? Без обвеса это удовольствие сильно ниже среднего при разработке. А с обвесом они становятся просто аналогом SPA фреймворков, к которым нужно тащить свой рантайм.
Попробуйте взглянуть на этот процесс с другой стороны. Если вы испытываете сложности, то скорее всего это знак, что вы что-то делаете не так. Просто остановитесь и подумайте.
Жмете газ, а машина не едет - проверьте, не пытаетесь ли вы по сугробам на кабриолете гонять.
Если среда сопротивляется - бесполезно дальше давить.
Так у меня и не возникают сложности:) Я ведь не использую веб компоненты с серверными шаблонизаторами.
Хотя и приходилось работать на проектах, которые в это пытались.
А вообще тут технический ресурс, ни к чему аналогии. Если хотите донести мысль, лучше покажите код.
Все уже было разобрано другими, но мало кто осилил имплементацию. https://serzn1.github.io/micro-frontends/
В оригинальной книге есть пример с веб компонентами.
Вот тут тоже хорошо описано что по чем https://martinfowler.com/articles/micro-frontends.html
Вы лучше не "как делать" покажите, а конечный результат. Как правильно делать может учить любой дурак, тут вон целая статья на эту тему, в рамках которой мы общаемся.
У вас есть пример веб-компонента, к которому не пришлось писать свой рантайм для работы с шаблонами, проброса данных в виде объектов, навешивания обработчиков событий декларативного, и т.д.?
Хотя бы какое нибудь более менее сложное поле ввода или мультиселект.
Я не говорил, что АПИ веб компонентов легко использовать без оберток. Но уже есть готовые решения, которые добавляют минимум полезного, типа lit или stencil.
Да и что вы под рантаймом имеете ввиду?
Шаблоны есть уже встроеные в сами веб компонетны. Зачем городить еще свое что-то? Просто по тому что можем?
Я лично написал на них демку пошаговой боевки одной игры несколько лет назад. Да отличается от реакта, но выходить из зоны комфорта иногда надо. Там обычно точки роста.
Сегодня вокруг них столько всего есть, что разработка становится гораздо комфортней.
Я не говорил, что АПИ веб компонентов легко использовать без оберток. Но уже есть готовые решения, которые добавляют минимум полезного, типа lit или stencil.
Вы отвечали на вот этот мой комментарий:
Вы пробовали их использовать для чего либо, сложнее простых виджетов? Без обвеса это удовольствие сильно ниже среднего при разработке. А с обвесом они становятся просто аналогом SPA фреймворков, к которым нужно тащить свой рантайм.
С чем вы тут несогласны? Под рантаймом я имею в виду код, без которого ваш веб-компонент не запустится. В Lit это его core-packages.
Без рантайма вы будете вынуждены писать так, как по вашей ссылке - вручную управлять DOM, вешать и удалять евенты строго через addEventListener, через придумывать как разместить кастомные евенты в глобальном скоупе чтобы не законфликтили, следить за именованием веб-компонентов (чтобы тодже не законфликтили), и т.д.
Я лично написал на них демку пошаговой боевки одной игры несколько лет назад. Да отличается от реакта, но выходить из зоны комфорта иногда надо. Там обычно точки роста.
В каждом вашем сообщении я замечаю какой-то способ самоутверждения через фразы вроде "выходить из зоны комфорта". Я поддерживал и дописывал крупный американский проект на Polymer в 2017-18 годах. На Lit примерно в те же годы я писал свой сайд проект в связке с leaflet. Веб-компоненты (включая безрантаймовые) я до сих иногда пишу на работе, там где это уместно. Первый свой доклад по ним делал еще в 2014 году. Реакт тогда только появлялся, все (включая меня) писали на jQuery/Backbone/Marionette/Knockout/Angular 1.3.
Я достаточно вышел из зоны комфорта? К чему вся эта информация, кто сколько чего написал, если мы обсуждаем конкретные примеры? На конкретном примере докажите вашу правоту, покажите код - и вы будете правы независимо от ваших/моих заслуг.
В ветке речь шла о шаблонизаторах, динамических областях с обработчиками событий и проблемах, связанных с этим. Про сложность виджетов речь не шла. Вопрос отрисовки динамических частей при помощи шаблонизатора веб-компоненты решают. Тут и изоляция стилей сторонних виджетов, и отсутствие ручной инициализаци, и жизненный цикл. То, о чём вы писали. Сами веб-компоненты при этом — просто набор низкоуровневых API и их можно использовать кучей разных способов.
Теперь про сложность. Надо отталкиваться от задачи. Если виджет простой или средний по сложности, вполне можно написать без обвеса. Я не из тех, для кого отсутствие синтаксического сахара и любимого фреймворка — препятствие и ухудшение.
А если нужно что-то действительно сложное, можно и рантайм добавить. Самое популярное для этого решение весит ~5кб, поставляется сразу с механизмом для работы со стилями, реактивными контроллерами и прочим. При этом ещё может работать без сборщиков.
Разница с SPA в том, что SPA полностью рисует и контролирует всю страницу. А тут классический северный рендеринг с островами интерактивности.
Я согласен с тем, что вы пишете, и сам примерно также применяю веб-компоненты. Размер рантайма тут не показатель, так как и для решений без веб-компонентов не обязательно брать тот же реакт. Есть решения в 5кб с минимальным обвесом, которые дадут все эти бонусы. Из примеров - Svelte, который может self-бандлить компонент с микрорантаймом в виде одного скрипта. И во многих других фреймворках сейчас появилась такая возможность.
При этом вы не сталкиваетесь с ограничениями веб-компонентов - глобальной областью видимости, необходимостью парсить строковые шаблоны в рантайме, крайне мутной системой изоляции стилей через Shadow DOM. В общем плюсы все еще не ясны.
Ну и главное не забывать, что 5кб рантайма даются не бесплатно, а за счет функционала. Если вам хватает - это нормально. Если потенциально мне может потребоваться больше функционала или более богатая экосистема готовых компонентов - я предпочту 100кб рантайма, зато без необходимости его менять в будущем.
Размер рантайма тут не показатель
Для меня показатель. Я придерживаюсь мнения, что на странице должно быть как можно меньше JS.
Из примеров - Svelte
Согласен. Острова интерактивности можно сделать разными способами и не обязательно веб-компонентами. Svelte - Хороший пример инструмента для такой задачи.
При этом вы не сталкиваетесь с ограничениями веб-компонентов - глобальной областью видимости, необходимостью парсить строковые шаблоны в рантайме, крайне мутной системой изоляции стилей через Shadow DOM. В общем плюсы все еще не ясны.
Возможно я слегка предвзят тут, потому что мне нравятся веб-компоненты и идеи, которые за ними стоят. И что это стандарт, для базового использования которого не нужны никакие инструменты и рантаймы. Веб-компоненты на мой взгляд хорошая точка монтирования островов. Можно написать логику на Svelte, скомпилировать это в веб-компонент и легко вставлять в HTML.
Ну и главное не забывать, что 5кб рантайма даются не бесплатно, а за счет функционала.
Я считаю, что функциональность нужно добавлять по мере необходимости. То есть начать с тех же 5кб и наращивать функциональность тогда, когда это действительно нужно. То есть не исходить из того, что в дальнейшем что-то может понадобится, поэтому сразу заложусь на большую библиотеку. А может никогда и не понадобится, что на практике достаточно часто и происходит.
я предпочту 100кб рантайма
Вы - да. А что на счёт пользователей? Мы ведь разрабатываем сервисы не для себя. А ещё бизнес, который вместо этих 100кб предпочтёт добавить 100кб рекламы и аналитики. При этом нужно сохранить адекватный уровень производительности и метрики RUM. А лишний JS - это самый главный враг производительнсоти.
Я уверен, что автор никогда, подчеркиваю, в жизни не работал на действительно крупных проектах) Выглядит, будто живет в манямирке, таких, видимо и заменит гпт
Смешно. Я последние 8 лет являюсь сотрудником Яндекса. Глянула ваши комментарии, типичный тролль, удачи вашем в не-манямирке.
Можете показать крупный проект яндекса, с жирной клиентской логикой, на котором применяется описанный вами подход?
Я ведь несколько раз сказала про область применимости. Я умею и так, и так, и знаю где разница. В крупных корпорациях есть причины почему они делают именно так как делают. Это не тема статьи. А для стартапов нужно выбирать другой путь, у них нет гор денег, людей и десяток лет в запасе.
лишний повод задуматься о работе в яндексе. придёшь - а там такое)
А как вы будете расширять ваш MVP, когда к вам придут и спросят "мобильное приложение мне сделайте"?
Можно же сразу реализовать API на бэкенде (самый простой REST) и с ним работать как в вебе так и на мобильных платформах. А так, придется еще и rest api допиливать бэкендеру. Слишком большая нагрузка идет на него - и макеты поддерживай, и API, и еще тесты для всего этого пиши (вижу радость в его глазах).
Про проблемы фронта, которые вы озвучили - это банальные ошибки, которые быстро решаются. И вопрос синхронизации состояния UI с URL лучше сразу прописывать отдельным требованием в ТЗ, и не интерпретировать как "само разумеющееся". "Само разумеющиеся" - это если нет в ТЗ, значит не делаем (субъективное мнение).
Претензию про SEO вообще не понял, давно уже всё решается фреймворками Nuxt или Next, которые умеют в SSR.
Почему такое пренебрежительное отношение к фронтендерам (естественно к уровню мидл+) тоже не понял. Я тоже был бэкендером и использовал тот подход, о котором вы пишете. Данный подход имеет право на жизнь, но процент таких проектов даже среди MVP сейчас не значителен. Если у вас такая специфика работы и подход эффективен - то ОК, рад за вас. Но почему при этом, жесткой критике придается "стандартный подход" - загадка? Ведь в вашем подходе тоже много минусов.
А как вы будете расширять ваш MVP, когда к вам придут и спросят "мобильное приложение мне сделайте"?
Спасибо что спросили. А вот так: https://annkpx.ru/apps
это если нет в ТЗ, значит не делаем (субъективное мнение)
У вас подход "без ТЗ результат ХЗ", у меня же подход с заботой о заказчике и здравом смысле. Заказчик не обязан знать все эти нюансы. И это одна из причин почему разработка всегда затягивается. Потому что всем всё равно.
Спасибо что спросили. А вот так: https://annkpx.ru/apps
Подход рабочий, только вот с офлайн режимом возникают вопросы.
У вас подход "без ТЗ результат ХЗ", у меня же подход с заботой о заказчике и здравом смысле. Заказчик не обязан знать все эти нюансы.
В основном заказчик сам не знает чего он хочет :)
Ну основной посыл понятен - убрать оверинжиниринг для простых проектов. За статью, спасибо.
У вас подход "без ТЗ результат ХЗ", у меня же подход с заботой о заказчике и здравом смысле. Заказчик не обязан знать все эти нюансы. И это одна из причин почему разработка всегда затягивается. Потому что всем всё равно.
Это значит, что вы выполняете роль бизнес-аналитика. Если вы им при этом по специализации не являетесь, то не факт, что качественно. Зачем перекладывать эту роль на разработчиков - непонятно.
Опять же если речь не о масштабах лендинга для забегаловки (хотя и там за фасадом часто скрыты серьезные бизнес-процессы).
Мобильное приложение из сайта? Нет уж, увольте, не нужно нам такого! Мобильные приложения делаются на нативных фреймворках для мобильных ос и имеют свой собственный дизайн. Точка.
Потом верстальщики с мотивацией о том что нужно что-то упростить, решили усложнить всё остальное. Придумали vue и react.
Ахахахаха, спасибо, поржал от души в голосину 🤣🤣🤣
Генерация полноценного HTML на серверной стороне достаточно ресурсоемкая задача по сравнению с генерацией данных в формате JSON, XML, etc.
Заставлять фронтендеров сохранять дизайн страниц на серверной стороне – это смешение ответственностей.
На мой взгляд, уж лучше мухи отдельно, котлеты отдельно.
Backend формирует данные, фронтенд их красиво рендерит.
Так устроена индустрия, и я не вижу никакой необходимости, как бэкендер с 30-летним стажем, принуждать фронтендера пересекаться с моей работой.
А где мол ? (Mol)
Зумеры открыли для себя, что можно не использовать SPA для небольших лендингов.
а можно узнать, с чего вдруг обиженный заказчик решил, что он может рассуждать о том, как устроен фронт? в статье есть сравнение тёплого с мягким ради... ничего? 0 выводов, кроме того, что "15 лет назад могла верстальщика купить за копейки, а теперь они видите ли разработчики, денег хотят". если тебе нужна вёрстка - ищешь верстальщика. если нужна фронтенд разработка - фронтендера. да, прикинь, SEO не обязательно, многие проекты разворачиваются не для привлечения пользователей со стороны. а это - лишняя работа, которую надо описывать в тз и за которую (о, господи!) придётся платить. какой вывод я, как фронтендер, должен сделать из этой "статьи", кроме того, что автор обижена на фронтов?
Статья - памятник собственной дискредитации, на почве недостаточной квалификации и излишней самоуверенности
Современные фронтенды