LINUX.ORG.RU

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

 , ,


0

1

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

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

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

abs ★★★ ()

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

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

Ford_Focus ★★★★★ ()

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

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

mertvoprog ()
Ответ на: комментарий от WitcherGeralt

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

mertvoprog ()

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

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

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

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

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

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

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

dimuska139 ★★ ()
Последнее исправление: dimuska139 (всего исправлений: 1)
Ответ на: комментарий от mertvoprog

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

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

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

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

mertvoprog ()
Ответ на: комментарий от abs

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

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

bread ()
Ответ на: комментарий от mertvoprog

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

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

bread ()
Ответ на: комментарий от bread

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

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

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

abs ★★★ ()
Ответ на: комментарий от abs

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

bread ()

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

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

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

stave ★★★★★ ()
Ответ на: комментарий от stave

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

Не про гуй.

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

gedisdone ★★★ ()
Ответ на: комментарий от stave

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

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

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

abs ★★★ ()
Ответ на: комментарий от abs

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

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

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

mertvoprog ()
Последнее исправление: mertvoprog (всего исправлений: 2)
Ответ на: комментарий от bread

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

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

mertvoprog ()
Ответ на: комментарий от stave

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

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

mertvoprog ()
Ответ на: комментарий от gedisdone

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

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

mertvoprog ()
Ответ на: комментарий от abs

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

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

mertvoprog ()
Последнее исправление: mertvoprog (всего исправлений: 1)
Ответ на: комментарий от mertvoprog

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

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

bread ()

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

ya-betmen ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

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

mertvoprog ()
Ответ на: комментарий от dimuska139

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

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

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

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

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

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

deep-purple ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

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

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

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

deep-purple ★★★★★ ()
Ответ на: комментарий от abs

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

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

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

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

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

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

deep-purple ★★★★★ ()