Comments 45
Из крайности в крайность.
Понятно, SPA не серебряная пуля, и много сложнее традиционных приложений.
Но и решает более сложные задачи.
Что касается Turbolinks и прочего JS из Rails, то ИМХО это жуть и кошмар.
Работает? Да.
Эффективно? Кхм.
Для простых проектов вполне пойдет, согласен.
Но SPA — не для простых проектов, КМК.
Насчет эффективности попробую на примере. Вот, допустим, эта самая страница хабра работает на Turbolinks. Мы нажимаем кнопку "обновить комментарии", нам прилетает 55 Kb HTML всей страницы, даже если новых комментариев нет.
Если без Turbolinks — нам нужно по клику на кнопке сделать AJAX-запрос (~100 байт, если нет новых комментариев), и обновить не всю страницу, а только комментарии, да и то если они изменились. Можно HTML генерировать на сервере и просто добавить в нужный узел, а можно брать JSON и готовить HTML на клиенте (с помощью handlebars, например).
И для AJAX-запросов можно использовать старый добрый JQuery, а можно xhr или fetch.
Да, это сложнее.
Отличная статья. Вы прямо сформулировали те мысли, которые не раз посещали меня за последние годы.
Но одна проблема остается нерешенной. Как только на сайте появляются сложные UI элементы (динамические таблицы, деревья, формы ввода и т.п.), разработка всего этого на серверных шаблонах превращается в боль. И здесь уже не поможет Progressive Enhancement вроде Stimulus. Нужны полноценные клиентские шаблонизаторы. Теперь часть страниц нашего сайта превращаются в точки входа для клиентских виджетов. И хорошо, если написанных на одном и том-же фреймворке.
И вот, чтобы не утонуть в этой мешанине, нам придется:
- реализовать единообразный API (хотя бы JSON RPC)
- настроить систему сборки (webpack) и code splitting
- выбрать клиентский фреймворк
- выбрать state container (чтобы обеспечить взаимодействие наших отдельных виджетов)
- etc.
Отдельная проблема — это разные шаблонизаторы на клиенте и на сервере. Каждый раз нужно решать, достаточно ли сложна задача, чтобы переносить ее на клиент? Или можно еще чуть-чуть допилить серверный шаблон. Возможно, тут может помочь Vue с его альтернативными шаблонизаторами: можно использовать Pug и на клиенте, и на сервере. А вот с React / Angular так не прокатит.
Мне medium как-то сам рекомендует. Во всяком случае все интересные переводы которые тут попадаются мне в рекомендациях там попадались. Хотя вроде ни на один блог не был подписан даже.
Ну, вообще это поддерживает любой фреймворк с Server Side Rendering (в т.ч. Vue, React, Angular). Но, как по мне, это не особо нам поможет. Потому что придется иметь два шаблона — клиентский (например JSX) и серверный (например ASP.NET Razor). И нужно чтобы они идеально совпадали. А это просто рассадник багов.
Views\Shared\_Layout.cshtml
Откуда это? :)
Как им заменять view component, partial view?
Вот так github.com/rails/webpacker
Суммируя, с SPA у вас будет ещё одно приложение для поддержки.
И это же прекрасно. Команда фронтендщиков смогут сконцентрироваться на UI, сами решать как отрисовывать элементы, гибко менять хоть весь дизайн целиком каждый день.
На базе хорошего бэкенда можно даже создавать паралельно iOS/Android приложения, внешние плагины и т.д.
В первую очередь SPA это показатель грамотной архитектуры где фронтенд отделен от бэкенда.
Да, это слегка увеличивает накладные расходы, но взамен добавляет гибкость и скорость развития проекту над которым работает больше двух человек.
И кол-во требуемых специалистов это тоже увеличивает как минимум в два раза, что для любого проекта не есть хорошо.
И кол-во требуемых специалистов это тоже увеличивает как минимум в два раза
Я уже сказал, что это скорее всего будет не так. Бэкенд могут писать человек 20, а фронтовая команда, например, человек 5.
Выше речь идет о том когда сайт разрабатывался одним девелопером. Вопрос больших команд, проблему загрузки разных позиций на проекте и их коммуникаций в этом треде я не обсуждал.
И чем вам не нравится пример с банком? Тем, что там бэкендом занимаются сотни?
Со стороны бекенда может быть нереально много логики, а фронт — значительно проще. Пример: банк-клиент (неважно, веб-версия или мобильное приложение).
Тем что фронт на примере банк-клиента может быть небольшим лишь в сравнение с бэкендом. В остальном он будет достаточно величины, чтобы рассматривать фронтенд фреймворки. И опять же обсуждались другие проекты.
И количество специалистов вырастет в два раза только если вы считаете что на проекте должен быть такой вот и швец, и жнец, и на дуде игрец. В остальных случаях у вас просто есть отдельно человек который делает фронт, отдельно человек который делает бек. А если есть swagger или документация то эти люди вообще могут даже не коммуницировать друг с другом.
От того что вы смешаете несколько проектов в одну репу/сайт у вас не получится одно приложение, у вас получится мешанина которую поддерживать сможет только фулстек разработчик с бубном который и css/js поправить может и sql запрос к базе.
Вы о чем? Кто что смешает? Открою для вас секрет большинство сайтов и разрабатывается без фронтенд фреймворков. И скажу даже больше кол-во проектов на которых размер js настолько большое что требует для этого отдельный фреймворк — невелико. И не имеет значения насколько это вам не нравится.
И количество специалистов вырастет в два раза только если вы считаете что на проекте должен быть такой вот и швец, и жнец, и на дуде игрец. В остальных случаях у вас просто есть отдельно человек который делает фронт, отдельно человек который делает бек. А если есть swagger или документация то эти люди вообще могут даже не коммуницировать друг с другом.
Вы сами себе противоречите. Чтобы не было и швец и жнец, и появляется еще одна позиция для разработки сайта.
Rust/php/python/go с js/html/css если так понятней.
Смешивание этих сущностей и есть отсутствие нормальной архитектуры. Бекенд отдает куски html который зависит от js/css. Начинаются танцы с динамическими импортами разных зависимостей на страницах, двойные накладные расходы на чудо проверки: «а что собственно поддерживает фронтенд» и т.д.
И не важно фреймворк у вас или нет. Открою для вас секрет — SPA можно сделать и без фреймворка. Да-да, spa на голом js+html если зашла уже речь о таких миниатюрных проектах где фреймворк не нужен.
Смешивание этих сущностей и есть отсутствие нормальной архитектуры. Бекенд отдает куски html который зависит от js/css. Начинаются танцы с динамическими импортами разных зависимостей на страницах, двойные накладные расходы на чудо проверки: «а что собственно поддерживает фронтенд» и т.д.
В каком месте вы его смешиваете? Все это отделено view слоем и шаблонами.
И не важно фреймворк у вас или нет. Открою для вас секрет — SPA можно сделать и без фреймворка. Да-да, spa на голом js+html если зашла уже речь о таких миниатюрных проектах где фреймворк не нужен.
Да какая разница как все это реализовываете. У вас в любом случае html, css и js. Это то как сейчас работает веб. Вы его не изменили своим SPA, от слова вообще никак. Только все это еще и делаете на машине клиента.
Выбираемся из кроличей норы SPA при помощи современного Rails