Thread by @mokevnin

Немного мыслей про SPA-приложения и серверный рендеринг. Еще каких-то 10 лет назад, весь рендеринг был серверный, а веб работал как и задумывалось. Клик по гиперссылке загружал новую страницу, которая представляла из себя уже готовый к отображению HTML. Клик = новая страница =>

В такой схеме (тонкий клиент) все было просто и понятно. Браузер автоматически знал как делать навигацию вперед/назад и в целом был заточен под такую схему. Плюс она идеально подходит для поисковиков. Индексация процесс, который не вызывал никаких вопросов. Но потом поехало =>

Появилась задача делать сайты более интерактивными, например создавать редакторы, или формы, изменяющиеся без перезагрузки. Сначала это делалось виджетами, которые встраивали кусок js в конкретное место на странице. Потом, постепенно это переросло в SPA, а бек превратился в API

Революцию в этом смысле сделал Gmail еще в далеком 2004 году. Это был первый по настоящему SPA сервис, который дал такой опыт взаимодействия, что все ахнули и побежали создавать фреймворки и интерактивные сайты. И оно много где было нужно, посмотрите на тот же Airbnb или Twitter

Еще одно место где без SPA почти нереально это сервисы с двухсторонним взаимодействием, например любые виды чатов и любых совместных штук. Совместное редактирование, рисование, кодирование и так далее. Все это требует серьезного клиентского кода. Плюс производительность =>

Все это подкреплялось идеей о том, что SPA сайты работают быстрее. И правда, нам ведь нужно загружать только сырые данные, все остальное делается на клиенте. Со временем этот аргумент почти перестал работать. Сильно шагнул вперед HTTP и браузеры, плюс, опять же, кеширование

Но дальше начались проблемы. Оказалось что SPA-приложения входят в конфликт с тем как устроен веб. Так как изменение содержимого и страниц теперь происходит на клиенте с помощью JS, то браузер потерял возможность за этим следить. То что раньше просто, стало сложно =>

Теперь если программист специально не следит за историей переходов, то кнопки назад/вперед работать не будут. Если специально не менять урл, то он всегда будет оставаться одним и тем же, что не дает возможность отправить ссылку на какую-то страницу.

Появилось много сетевого взаимодействия, что привело к большому количеству ошибок, которые надо правильно обрабатывать. Неадекватное поведение при сбоях в сети это бич современных SPA-сайтов. И автоматика тут мало поможет, нужно ручками все это обрабатывать.

Появились проблемы с ожиданиями. Что делать пока идет процесс? Нужно ли сначала обновить UI, или ждать пока не придет ответ от сервера? SPA приложения часто злоупотребляют спиннерами. Создается ощущение постоянных тупняков и постоянной загрузки чего-то.

Оказалось что приходится дублировать логику бекенда на фронтенде. Валидация? И там и тут. Какие-то бизнес правила? Возможность что-то сделать? Все это стало повторяться. В два раза больше программистов на те же самые задачи что и раньше.

Самое страшное что скорость разработки упала в разы. Это знают все кто когда-либо работал с классическими бекенд фреймворками. Тут у нас и сложность событийной модели (сложнее клиент-серверной модели) и выделение нового вида программистов и новые проблемы описанные выше

React, кстати, в этом смысле немного приблизил фронтенд разработку к принципам работы бекенда. Подход "каждый раз с нуля" совершенно точно отражает то, как устроен серверный рендеринг в бекенд-фреймворках, где шаблон формирует HTML, который отправляет в браузер.

Но по настоящему камнем преткновения стали две вещи: 1. индексация важная для SEO 2. Скорость первой отрисовки, которая из-за тяжести кода стала ну просто нереально долгой (классические сайты громко смеются). Эти проблемы привели к тому, что мы вернулись к серверному рендерингу

Был где-то смешной твит на тему того, что вот эта эволюция сайтов в чистый SPA была ошибкой, раз мы все равно откатились назад. Правда откатились на новом уровне. Сначала появился просто способ рендерить фронтовые штуки на сервере. Он до сих пор популярен и продолжает развиваться

Так мы решаем проблему первой загрузки и SEO, добавляя при этом новой сложности. В этой части я правда не очень силен, поэтому не могу говорить исходя из опыта. Тут сами скажите насколько это больно/сложно/прозрачно/понятно. Я скорее добавлю про следующий уровень

А дальше появилась старая-новая идея. Раз у нас вебсокеты, HTML5, HTTP/3 и нам нужен серверный рендеринг. Почему-бы не вернуться к идее классической серверной генерации HTML, средствами бекенд фреймворков, а вместо js мы начнем использовать data-атрибуты. И немного js если надо

И понеслась. Одним из первых был htmx.org > htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext

То есть концепция в том, что бек нам возвращает HTML, который мы вставляем в DOM. Делается это самим фреймворком, а нам надо только формировать правильный HTML на сервере. Большая часть кода управляется data-атрибутами, но при необходимости можно писать JS на спец фреймворках

К таким фреймворкам относится например stimulus.hotwired.dev Он нужен для того самого интерактива, который нельзя сделать через серверный рендеринг. Кстати stimulus является частью hotwired.dev крайне рекомендую посмотреть видосы использования этого решения

Подобные фреймворки уже строятся из принципа что есть готовый html, в который мы внедряемся через обычные атрибуты. То есть эти фреймворки заточены под серверную генерацию HTML. То есть возврат в JQuery мир, но с другого входа :)

Кстати, уже выросло поколение людей, которые не видели в глаза классический серверный рендеринг и не знают про подобные шаблонизаторы для бекенд языков: haml.info

Так вот что я хочу сказать. Не знаю куда все придет, но видно что мы сейчас на пороге нового витка. Кажется что индустрию бросало от чистого серевра до чистого клиента и только сейчас формируется гибридный подход, который найдет баланс и станет наиболее универсальным.

На текущий момент, мы на Хекслете делаем так: большая часть интерактива это виджеты в рамках классического рендеренга Rails. У нас есть SPA и это редактор. Плюс сейчас местами начинаем внедрять Stimulus, там где хочется переиспользовать готовый HTML, благо hotwire интегрирован

А глобально моя стратегия такая:

1. Можно сделать через серверный рендеринг => Делаем без js
2. Не можем сделать без клиента => Используем виджет
3. Нужно оживить текущий HTML => Stimulus
4. Нужен сквозной (страницы) и сложный интерактив => SPA

Оу забыл добавить. Есть же еще один путь развития в сторону написания фронта на любом языке на серверной стороне. Тут все начиналось с GWT и сейчас благодаря WebAssembly продолжает развиваться с утроенной силой. Скорее всего, вес фронт расползется по разным стекам.