JavaScript
Ruby on Rails
Website development
Comments 45
0
На полученный фрагмент HTML с сервера нужно навешивать обработчики событий (onclick и т.п.) в соответствии с бизнесс-логикой. Причём навешивать только на элементы этого нового фрагмента. Это дополнительная задача, о которой как-то забыли.
0

Вроде не забыли, этим занимается упомянутый фреймворк Stimulus.

0

Как-то концептуально Stimulus мне показался похожим на Vue или Angular.

+3

Из крайности в крайность.
Понятно, SPA не серебряная пуля, и много сложнее традиционных приложений.
Но и решает более сложные задачи.
Что касается Turbolinks и прочего JS из Rails, то ИМХО это жуть и кошмар.
Работает? Да.
Эффективно? Кхм.

+4
Примерно 4 года назад поработал фулстэк девелопером на небольшом проекте, с простеньким простеньким фронтом. Турболинки были для меня спасением, так как я больше бэкендер, для больших и интерактивных проектов — согласен это будет жутью и спаггети кодом, но если на сайту не нужна интерактивность, всё шустро работает, тем более в рельсах отличный пайплайн для сбора/упаковки фронта
+1

Для простых проектов вполне пойдет, согласен.
Но SPA — не для простых проектов, КМК.
Насчет эффективности попробую на примере. Вот, допустим, эта самая страница хабра работает на Turbolinks. Мы нажимаем кнопку "обновить комментарии", нам прилетает 55 Kb HTML всей страницы, даже если новых комментариев нет.
Если без Turbolinks — нам нужно по клику на кнопке сделать AJAX-запрос (~100 байт, если нет новых комментариев), и обновить не всю страницу, а только комментарии, да и то если они изменились. Можно HTML генерировать на сервере и просто добавить в нужный узел, а можно брать JSON и готовить HTML на клиенте (с помощью handlebars, например).
И для AJAX-запросов можно использовать старый добрый JQuery, а можно xhr или fetch.
Да, это сложнее.

+2
Всю страницу не надо запрашивать, делается SJR запрос и обновляется только нужный узел
+1

В статье же говорится, что это SPA на базе Ember? Или что-то работает на Turbolinks?

0
Они просто используют такой-же подход с пререндером, наверное не совсем удачная параллель
+1

Отличная статья. Вы прямо сформулировали те мысли, которые не раз посещали меня за последние годы.


Но одна проблема остается нерешенной. Как только на сайте появляются сложные UI элементы (динамические таблицы, деревья, формы ввода и т.п.), разработка всего этого на серверных шаблонах превращается в боль. И здесь уже не поможет Progressive Enhancement вроде Stimulus. Нужны полноценные клиентские шаблонизаторы. Теперь часть страниц нашего сайта превращаются в точки входа для клиентских виджетов. И хорошо, если написанных на одном и том-же фреймворке.


И вот, чтобы не утонуть в этой мешанине, нам придется:


  • реализовать единообразный API (хотя бы JSON RPC)
  • настроить систему сборки (webpack) и code splitting
  • выбрать клиентский фреймворк
  • выбрать state container (чтобы обеспечить взаимодействие наших отдельных виджетов)
  • etc.

Отдельная проблема — это разные шаблонизаторы на клиенте и на сервере. Каждый раз нужно решать, достаточно ли сложна задача, чтобы переносить ее на клиент? Или можно еще чуть-чуть допилить серверный шаблон. Возможно, тут может помочь Vue с его альтернативными шаблонизаторами: можно использовать Pug и на клиенте, и на сервере. А вот с React / Angular так не прокатит.

0
Вопрос в сторону. Не поделитесь ли вы или ваши читатели, как использовать medium что бы не пропускать такие статьи? Вот просто тэги web development и frontend на latest показывают мне столько белеберды на китайском турецком что читать невозможно. А какой-то «подписки», «фильтров по языкам» я не нашел. Плохо искал? Как пользуетесь mediumом вы?
0
На medium неплохо работают рекомендации, но это скорее всего зависит от частоты чтения статей на похожую тематику.
0

Мне medium как-то сам рекомендует. Во всяком случае все интересные переводы которые тут попадаются мне в рекомендациях там попадались. Хотя вроде ни на один блог не был подписан даже.

+2
Как только на сайте появляются сложные UI элементы (динамические таблицы, деревья, формы ввода и т.п.), разработка всего этого на серверных шаблонах превращается в боль. И здесь уже не поможет Progressive Enhancement вроде Stimulus. Нужны полноценные клиентские шаблонизаторы.

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

0
А никто и не заставляет все сразу переписывать. Vue можно вообще подключить как еще одну библиотеку и постепенно переписывать jquery лапшу на него, постепенно избавляясь от легаси.
+1

Скорее всего рендер этих компонентов вынесен на сторону сервера, а клиентский скрипт только подменяет innerHTML. Статья такой подход поощряет. То есть придётся переделывать серверную логику, чтобы хотя бы по AJAX он отдавал JSON, а не HTML. Кстати, как Vue относится к пререндеренным на сервере компонентам? Умеет подхватывать без ошибок и предупреждений?

0
Не уверен что понял вопрос.

Можно конвертить их сразу в json из бд. Как указано здесь
<%= tad.div id: :boards, data { lists: @lists.to_json(include: :cards)} %>
0

Ну, вообще это поддерживает любой фреймворк с Server Side Rendering (в т.ч. Vue, React, Angular). Но, как по мне, это не особо нам поможет. Потому что придется иметь два шаблона — клиентский (например JSX) и серверный (например ASP.NET Razor). И нужно чтобы они идеально совпадали. А это просто рассадник багов.

0

Не совсем так. Им всё равно требуются исходные данные для рендера. И дальше будет сравнение виртуального DOM с реальным, на основе пришедшего с сервера HTML. Если будет даже минимальное расхождение, React выдаёт предупреждение.


Кроме того, полностью от Razor может быть тяжело отказаться, потому что шаблоны иногда бывают активные, придётся дорабатывать бэкенд.

0
Заинтересовало, что значит «постепенно», vue в таком использовании сможет 1) жить совместно с Views\Shared\_Layout.cshtml? 2) Как им заменять view component, partial view?
0
Речь была о другом в том комменте, но отвечу на вопросы)
Views\Shared\_Layout.cshtml

Откуда это? :)
Как им заменять view component, partial view?

Вот так github.com/rails/webpacker
0
Суммируя, с SPA у вас будет ещё одно приложение для поддержки.

И это же прекрасно. Команда фронтендщиков смогут сконцентрироваться на UI, сами решать как отрисовывать элементы, гибко менять хоть весь дизайн целиком каждый день.
На базе хорошего бэкенда можно даже создавать паралельно iOS/Android приложения, внешние плагины и т.д.
В первую очередь SPA это показатель грамотной архитектуры где фронтенд отделен от бэкенда.
Да, это слегка увеличивает накладные расходы, но взамен добавляет гибкость и скорость развития проекту над которым работает больше двух человек.
0
Там где нужен только один сайт, у вас вместо одного приложения будут два.

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

Почему минимум в два? Со стороны бекенда может быть нереально много логики, а фронт — значительно проще. Пример: банк-клиент (неважно, веб-версия или мобильное приложение).

0
И даже в этом случае кол-во знаний для использования фронтенд фреймворка для веб девелопера(в этом случае бэкенд девелопера) увеличивается на порядок. Хотя банк-клиент как пример здесь не очень.
0

Так в том и дело, что фронтенд-фреймворк бэкендеру не нужно будет знать, если это будет обязанность фронтендера. Точно так же, как ему не нужно будет знать ни Андроид, ни Айос.

0
Тогда все еще хуже. Для проекта нужен будет еще один девелопер)) И мы возвращаемся к…
И кол-во требуемых специалистов это тоже увеличивает как минимум в два раза
0

Я уже сказал, что это скорее всего будет не так. Бэкенд могут писать человек 20, а фронтовая команда, например, человек 5. И чем вам не нравится пример с банком? Тем, что там бэкендом занимаются сотни?

0
Я уже сказал, что это скорее всего будет не так. Бэкенд могут писать человек 20, а фронтовая команда, например, человек 5.

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

Со стороны бекенда может быть нереально много логики, а фронт — значительно проще. Пример: банк-клиент (неважно, веб-версия или мобильное приложение).

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

Извините, но Undiabler начал эту ветку с условия о том, что речь идёт о проекте, "над которым работает больше двух человек".

0
Без проблем. Кол-во человек говорит о размере проекта косвенно. В первом комменте я указал что лишь часть проектов требует увеличения кол-ва девелоперов. Я думаю что мы поняли друг друга и на этом предлагаю закончить ветку.
+1
От того что вы смешаете несколько проектов в одну репу/сайт у вас не получится одно приложение, у вас получится мешанина которую поддерживать сможет только фулстек разработчик с бубном который и css/js поправить может и sql запрос к базе.

И количество специалистов вырастет в два раза только если вы считаете что на проекте должен быть такой вот и швец, и жнец, и на дуде игрец. В остальных случаях у вас просто есть отдельно человек который делает фронт, отдельно человек который делает бек. А если есть swagger или документация то эти люди вообще могут даже не коммуницировать друг с другом.
0
От того что вы смешаете несколько проектов в одну репу/сайт у вас не получится одно приложение, у вас получится мешанина которую поддерживать сможет только фулстек разработчик с бубном который и css/js поправить может и sql запрос к базе.

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

И количество специалистов вырастет в два раза только если вы считаете что на проекте должен быть такой вот и швец, и жнец, и на дуде игрец. В остальных случаях у вас просто есть отдельно человек который делает фронт, отдельно человек который делает бек. А если есть swagger или документация то эти люди вообще могут даже не коммуницировать друг с другом.

Вы сами себе противоречите. Чтобы не было и швец и жнец, и появляется еще одна позиция для разработки сайта.
0
И скажу даже больше кол-во проектов на которых размер js настолько большое что требует для этого отдельный фреймворк — невелико.

А начиная с какого количества кода по-вашему разумно внедрять фронтенд-фреймворк?


Вы сами себе противоречите. Чтобы не было и швец и жнец, и появляется еще одна позиция для разработки сайта.

Так если фронт и бэк тесно связаны, всяко потребуется фуллстек.

0
А начиная с какого количества кода по-вашему разумно внедрять фронтенд-фреймворк?

Тогда, когда его поддержка становится невозможной.

Так если фронт и бэк тесно связаны, всяко потребуется фуллстек.

Вы о чем вообще? Перечитайте ветку.
0
Смешивать бэкенд и фронтенд конечно же.
Rust/php/python/go с js/html/css если так понятней.

Смешивание этих сущностей и есть отсутствие нормальной архитектуры. Бекенд отдает куски html который зависит от js/css. Начинаются танцы с динамическими импортами разных зависимостей на страницах, двойные накладные расходы на чудо проверки: «а что собственно поддерживает фронтенд» и т.д.

И не важно фреймворк у вас или нет. Открою для вас секрет — SPA можно сделать и без фреймворка. Да-да, spa на голом js+html если зашла уже речь о таких миниатюрных проектах где фреймворк не нужен.
0
Смешивание этих сущностей и есть отсутствие нормальной архитектуры. Бекенд отдает куски html который зависит от js/css. Начинаются танцы с динамическими импортами разных зависимостей на страницах, двойные накладные расходы на чудо проверки: «а что собственно поддерживает фронтенд» и т.д.

В каком месте вы его смешиваете? Все это отделено view слоем и шаблонами.

И не важно фреймворк у вас или нет. Открою для вас секрет — SPA можно сделать и без фреймворка. Да-да, spa на голом js+html если зашла уже речь о таких миниатюрных проектах где фреймворк не нужен.

Да какая разница как все это реализовываете. У вас в любом случае html, css и js. Это то как сейчас работает веб. Вы его не изменили своим SPA, от слова вообще никак. Только все это еще и делаете на машине клиента.
0
Если вы недоумеваете: «где я пропустил в логике автора, то место где, где объясняется почему при перечисленных проблемах SPA (время нач. загрузки, хрупкость, сложность), оригинальный rails (без Turbolinks, SJR, Stimulus) является недостаточным их решением?», то вы не одиноки. Мое понимание статьи распалось на две несвязанные части «критика SPA» и «плюшки Turbolinks etc.».
Only logged in users are able to leave comments. , please.