Толстый web-сервер или толстый web-клиент

наверно, должны быть ситуации, в которых такой подход оправдан. Или нет?

1. Нет денег на сервер.

В первую очередь удобство для пользователя.

В случае если для того чтоб эту одну строку обновить на другую строку приходится делать запрос на бекенд - а это минимум 100мс, когда js это может сделать быстрее чем один кадр 60 фпс (16 мс).

но, наверно, должны быть ситуации, в которых такой подход оправдан

SPA. Когда у тебя интерактивный интерфейс, постоянно взаимодействующий с постетителем, проще и логичнее сделать это на SPA framework’е

должны быть ситуации

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

Всё просто. Если ты пилишь сайт, то правильней первое, если веб-приложение, то второе.

Удваиваю этого оратора.

Беда в том, что между ними нет чёткой грани. Вот если на сайте есть калькулятор стоимости заказа какой-нибудь — это уже приложение, или ещё нет? Где та грань, когда количество JS-лапши, спутанной с бэкендом, становится чрезмерным и надо переделывать всё в виде SPA?

ИМХО, тогда, когда сайт можно полностью заменить «нативным» приложением.

Считаю, что разрабатывать проекты в виде SPA удобней. Во-первых, фронт отделен от бэка, что очень удобно в разработке. Фронты и верстаки занимаются своим кодом и бэкенд не трогают вообще, формат API они видят в OpenApi-документации. Кроме того, сразу же есть готовое API для мобильных приложений. Бэкенд становится проще, потому что превращается в обычную API, где нет никаких шаблонов, никакого HTML-ля. Если припрет, то части проекта можно без боли и страданий переписывать с помощью более пригодных технологий, и это фронтендеров никак вообще не затронет. Более того, смена дизайна всего сайта заключается лишь в замене фронтенда целиком, и это все бэкендеров не касается.

и он отдавал готовую страничку

Сейчас при первоначальном запросе у многих SPA-сайтов с сервера точно так же приходит готовая страница, потому что есть server side rendering.

На мой скромный взгляд, SPA - это самый перспективный и удобный подход к разработке для тех сайтов, которые делаются не на всякого рода CMS.

три мегабайта скриптов для показа одной строки

Ну так нужно потому что оптимизировать код и грамотно подходить к работе. Например, не использовать MomentJS тогда, когда это не нужно. Есть способы анализировать js-бандл, чтобы выявлять, какие библиотеки много весят.

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

Грань чётче некуда. Веб-приложение (фронтенд) можно заменить мобильным приложением или чем угодно ещё, переиспользовав бэкенд. А сайт — это собственно, сайт, он монолитен.

Для какой платформы? Беда в том, что нет ничего кроссплатформеннее вебни. В особенности если это лапша на ES3-ванильке, а не новомодные извращения.

А вот и неосиляторы парсинга HTML и написания приложений без API подъехали.

А ещё во всяких CMS нередко встречается, что одни и те же штуки параллельно реализованы перезагрузкой HTML-страницы и через AJAX (правда, зачастую в AJAX куски HTML вместо чистых данных, но тем не менее). Куда это-то относить?

А вот и неосиляторы парсинга HTML и написания приложений без API подъехали

Лол, вот и говноеды подъехали. Наднюсь, что ты шутишь.

В случае если для того чтоб эту одну строку обновить на другую строку приходится делать запрос на бекенд - а это минимум 100мс, когда js это может сделать быстрее чем один кадр 60 фпс (16 мс).

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

Где та грань, когда количество JS-лапши, спутанной с бэкендом, становится чрезмерным

Как только спутаешься с бэкендом, считай уже дело дрянь. Вот этот ajax и есть причина рака. Ну и никаких модулей, классов, зависимостей в скриптах быть не должно. Если оно появилось, то тоже пиши пропало. Через пару итераций на лбу вскочит фреймворк.

Это все в теории, а на деле мегабайты скриптов адски тормозят

С чего бы это вдруг?

а отдача закешированной статики мгновенно происходит на современных каналах

Но никто не делает статику на SPA фреймворках без SSR (который по сути тоже статика).

Так что ты прав что статика отдается мгновенно, но это ни плюс ни минус в сторону SPA vs backend

Так сайт это на 99% статика. А тот 1%, где требуется страничку перерисовать, тоже никаких заметных задержек не вызывает если у вас не 100500 клиентов в секунду. SPA это рак никому не нужный в эпоху мобильных приложений. Какое-то историческое недоразумение с единственным обоснованием «нам кодерам так удобнее».

SPA это рак никому не нужный в эпоху мобильных приложений

Таки три приложения досок объявлений лучше трёх сайтов досок объявлений?

сейчас же сваяют три мегабайта скриптов для показа одной строки

и данные для нее дергается с трех десятков эндпонйтов бека

Не надо все в кучу, сейчас все используется вместе. Или ты только про гуй?

когда js это может

Может. А данные откуда? Или куда?

Или ты только про гуй?

Не про гуй.

Я могу понять SPA для условного Google Docs. Реализовать одними запросами к серверу тяжело и даже, наверно, вредно. Однако разные преимущественно текстовые сайты (новостные, например, или Medium, но у медиума какой-то особо извращённый подход к сайту) без JS не работают. Я не знаю, что у них устроено - но городить SPA для показа текста и в основном текста?

А данные откуда? Или куда?

Ну вот классическая таска для джунов - ТУДУ лист с перетаскиванием (типа трелло или джиры). Когда юзер перетянул карточку в другую колонку мы мгновенно это отображаем, а на бек отправляем только сохранение, ответа ждать не нужно.

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

говноеды

От розового единорога слышим.

Как только спутаешься с бэкендом, считай уже дело дрянь

Статики хватит всем? Яснопонятно.

Потому что развитие процессоров упёрлось в потолок ещё в начале 00-х. И сейчас это ботлнек. А JS однопоточный…

без SSR (который по сути тоже статика)

Ага, а с SSR получается хитрожопая уловка уровня прогрессбара в Проводнике Windows 7: сначала добегает почти до конца, а потом мммэдленно доползает. Так же для пользователя выглядят и эти статические заглушки без функциональности, тьфу!

Причём если с классическими сайтами более-менее предсказуемо, можно ориентироваться на индикатор загрузки в браузере, на сообщения в статусбаре, то в SPA-говне всё на совести разработчиков. Поди пойми, чего спиннер крутится (если он вообще есть!) и когда всё это кончится. А может, и не кончится, потому что где-то сломалось и ошибку не выдало.

никому не нужный в эпоху мобильных приложений

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

А данные откуда? Или куда?

Ну таки есть полно случаев, когда данные ниоткуда и никуда гонять не надо. Толстый клиент даёт возможность так делать. И комбинировать оба способа. А раундтрип через сервер по каждому чиху — это боль.

SPA для показа текста

Агащяз! Им надо окучивать плебс. Следить за ним через аналитику, впаривать рекламу, и так далее. Текст — это просто приманка. Ну вот какой рыбак будет беспокоиться о рыбе, которая червя (текст) глотает и сваливает, не выполнив JS (путь из воды в ведро)? Пошла нафиг такая рыба!

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

мы же не будет перезагружать страницу чтоб отобразить его.

Тащемта, можно посадить уведомления в отдельный айфрейм! И пускай себе обновляется по интервалу. Без JS!

Если ты серьёзно, то вёрстку можно изменить в любой момент. Супертупо на неё полагаться. Вёрстка — это не часть интерфейса.

Статики хватит всем?

Нет, не хватит. Но вы же хотели разграничить сайты и приложения. Вот я вам и разграничил. Если кто-то тащит аякс на сайт, это не значит, что так нужно делать, и что сайт без этого не может обойтись. А за скриптозонды так вообще нужно судить приравнивая эту практику к терроризму.

Толстый клиент или тонкий - без разницы. Главное чтобы этот папик деньги платил ;)

beaver

Толстый веб клиент нужен для сложного интерфейса и малого обмена с сервером.

В подавляющем большинстве случаев это не нужно, достаточно django bootstrap jquery или типа того

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

Толстый web-сервер имхо лучше.

API тоже можно, если он не публичный и работа фронтендеров с бэкендерами синхронизирована (а то и одно рыло этим занимается). И что?

Нет, не хватит

Тогда посыл вообще непонятен. Динамический HTML без скриптов тоже бэкенд отдаёт.

Посыл в том, чтобы пользоваться легальными путями доставки документов через гиперссылки и формы. А не где-то в фоне зонды разводить.

С каких пор JS где-то стал нелегален? И почему выполняющийся в люто огороженной песочнице недоязычок вдруг стал зондом?

Ну ты и колхозник. Я думал, что ты шутишь.

А что ещё предлагаете делать со всякой мутной проприетарщиной, которая не предполагает каких-то левых поделок? Или предоставляет API, но урезанный или огороженный? Вон youtube-dl сплошь на этом «колхозе» работает.

Тред про собственную разаботку, а не про реверсинг всякой левой параши.

на сайте есть калькулятор стоимости заказа

Грань там, где ты хочешь спрятать алгоритмы расчёта на бекенде.

разрабатывать проекты в виде SPA удобней

А вот там другой оратор говорит что удобство это для пользователя, а ты тут говоришь что для разработчика.

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

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

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

А ты видел как втупляет твитор в браузере? Это ж просто вин. Дык там же нет нихера на странице то, кроме нескольких десятков каментиков с медиа.

А сайт — это собственно, сайт, он монолитен.

Эмм. Любой сайт можно рассматривать как бекенд, сервис, АПИ, который, на запросы отдаёт ответы. И то, что некоторые ответы являются хтмл страницами, ничего не значит — это частный случай ответа.

Другое дело, если к сайту (который суть бекенд, сервис или АПИ) легко прикрутить могильное и любое другое, то сайт (да, тут название «сайт» уже не в тему) сделан правильно.

Через пару итераций на лбу вскочит фреймворк

И калёным железом будет не вывести. Только заново переписывать.

классическая таска для джунов - ТУДУ лист с перетаскиванием (типа трелло или джиры)

Требование выглядит как говно.

А знаешь почему?

Ты когда такой таск выполнял, ты валидацию данных делал? А обвязку регистрация-забыл-пароль-войти? А роли юзеров и права доступа? Явно же — нет.

Ну и смысл какой этих джунотасков? Они же нихрена не показывают уровень кандидата и не показывают тормозявость фреймворка/либы на реальном приложении.

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