SPA (Single Page Application) с точки зрения юзера: голосуем реакциями!

Ты меня ща прям триггернул ссылкой. Там выше по треду про gql такая редкая чушь написана что прям хоть смеяться хоть плакать. Можешь в удалённом глянуть в конце

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

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

Единственный и решающий недостаток SPA - неадекватная и нестандартизированная работа на медленном соединении. Зачастую никакого индикатора выполнения запроса нет, и ты не понимаешь, в каком состоянии браузер после твоего клика - загружает что-то для новой страницы, отвалился по таймауту, словил ошибку в JS, вот это вот всё. Кроме того, SPA часто зависают при смене сети или потере пакетов (например, в метро/в лифте), и ты не можешь до заложенного веб-макакой таймаута прервать выполнение запроса и запустить его заново.

Там выше по треду про gql такая редкая чушь написана что прям хоть смеяться хоть плакать.

Угу, вижу. И твоё само-удалённое многобукаф тоже. На самом деле byko3y там просто сформулировал достаточно коряво (проверку прав какую-то приплёл на клиенте), но идея, что бакенд – это тонкая прослойка между вебом и базой, не нова и по-своему красива и толкова: два, раз (парой ответов выше), ноль (до кучи); Sinclair – один из тамошних гуру.

Недавно на ЛОРе кто-то спрашивал, что мол пилит что-то в похожей идее, есть ли смысл публиковать. Не могу найти. Если кто понял о чём речь, киньте ему ссылку на этот камент.

То что фреймворки шлак - да, возможно, но без них адекватный time to market не получится.

Ну, я выше вскользь упомянул про маркетинг и «быть как все». Ясен пень, если весь мир живёт в парадигме копроэкономики, то вариантов нет.

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

У меня было предостаточно времени в профессии, чтобы не попытаться самому писать фреймворки самых разных сортов. Как же я ржал, обнаружив, что мой веб фреймворк на scala, изначально задумывавшийся как чисто функциональный, с каждым рефакторингом всё ближе и ближе напоминает servlet API. Только диспатчинг URL-ей не через web.xml, а нормальным scala-кодом.

Из всего этого опыта я вынес дзен: в большинстве своём фреймворки тупо переливают из пустого в порожнее, переформулируя underlying APIs в других терминах. И польза от них если и есть, она с лихвой перекрывается обременением (стоимостью изучения/внедрения, увеличением сложости/времени компиляции/трафика, etc). Исключения единичны.

И выбор между популярным фреймворком на миллион строк и собственной поделкой на пару тыщ – лично для меня очевиден всегда (по ссылке я упоминал SPA вообще в 200 строк).

Не путать фреймворк и библиотеку. Для меня критерием отличия является паттерн skeleton (или как его там): фрейморк диктует тебе архитектуру, давая лишь ограниченное число точек расширения. Шаг влево-вправо – расстрел. Библиотека же неинтрузивна. Многие дополнительные полезные фичи фреймворков могут быть переформулированы неинтрузивно – в теории; на практике их разумеется хрен вырвешь из написанного графоманами монолита.

Зачастую никакого индикатора выполнения запроса нет, и ты не понимаешь, в каком состоянии браузер после твоего клика

Не, ну за это тоже надо пороть. Функция wait(bool), показывающая/скрывающая полупрозрачный не пропускающий мышь div с какой-нибудь крутилкой, пишется в одну строчку.

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

Это косяк, да. Приходится жать F5 или Ctrl+F5 – и весь SPA загружается заново, а его bootstrap даже в идеальном случае всё-таки пообъёмнее, чем обвязка отдельной страницы.

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

Каждая страница в вики должна иметь свой адрес. А по хоршему и не только в вики. СПА этому мешают

Нет, СПА никак не могут помешать вики иметь адрес для каждой страницы.

но идея, что бакенд – это тонкая прослойка между вебом и базой, не нова и по-своему красива и толкова

Ну, да, только к graphql она отношение имеет примерно как космический корабль к самолёту. Оба летают и в целом можно куски одно частично и с напильником впихнуть в другое, не более того. Суть и плюшки gql совершенно другие.

Не путать фреймворк и библиотеку. Для меня критерием отличия является паттерн skeleton (или как его там): фрейморк диктует тебе архитектуру, давая лишь ограниченное число точек расширения.

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

А ты, стало быть, не знаешь как сделать адрес страниц в SPA.

Я как бы делал такое.

ты апеллируешь к программистским заморочкам

Нет - наличие отдельного адреса - именно удобство пользователя. Ты видимо слабо разбираешся к требованиям UI но имеешь своё мнение по поводу того, что трогать, а что не трогать в голосовании.

Да есть возможность имитировать адрес, но большинство пограммистов на это забивают.

Суть и плюшки gql совершенно другие.

Это понятно. Просто вспомнилось.

Вот шпринг это фреймворк или либа?

Фреймворк однозначно. Корявый и монструозный, хотя в стародавние времена позиционировался как лёгкая альтернатива JEE.

В целом можно руками дёрнуть все что его аннотации делают

И дёргая руками, ты проваливаешься в него и выныриваешь только там где он тебе позволит. Впрочем, ещё можно выпилить его вообще из web.xml. Я бы даже сказал – нужно. :) Вот тогда будет либа. :)

Да есть возможность имитировать адрес, но большинство пограммистов на это забивают.

Это проблемы большинства программистов, а не обсуждаемой технологии. Повторюсь: говёной реализацией можно испоганить любую идею.

Нет, СПА никак не могут помешать вики иметь адрес для каждой страницы.

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

Хорошего маньяка на улице не узнать. :) Но нас, юзающих uMatrix или NoScript, довольно много.

Попробовал c выключенным js, даже почту не проверить. Хорошо вам наверное там.

Ну, не, ты таки не прав про шпринг. Вот скажем статейка как руками и без бута/integration/mvc заюзать контекст и autowire. Ничего стремного там нету. Да, оно идёт рефлекшеном по указанному классу. Но ведь джексон и гсон тоже так делают и они ни разу не фреймворки. Да, жрёт аннотации, аналогично.

https://allaboutspringframework.com/java-spring-di-without-spring-boot/

Если лезть в бут там да, руками тяжко, но оно и сервак пускает и ещё кучу всего.

А ещё есть Next.js, который берёт лучшее от двух миров.

А веб макаки, которые забивают на нормальный роутинг, это неотъемлемая часть СПА?

голосуем реакциями

Не выйдет, тут же нет говносмайлика.

разве что считать недостатком необходимость включённого JS

Что значит «разве что»?

Если сайтом пользуешься часто - ангуляр нужен, если нет - не нужен.

Пофиксил.

отрубить башку

Придется вам всем рубить, потому что тупят абсолютно все отжиэсенные сайты. Вот ЛОР не тупит, похоже здесь серверные шаблоны как у лохов.

Ангуляр - точно не нужен. Есть более человечные способы делать SPA.

Но вопрос был с точки зрения пользователя.

валидацию пользователя

Что это?

Ты кто?

Что?

Мороз высок, понимаю. Рождество, люди празднуют, пытаются троллить.

Что ты несёшь?

Ты варежку бы не открывал в таком тоне. Иди за Sway топи и доказывай, как у тебя всё хорошо.

Вообще, моё мнение, касательно не только SPA, но и вообще, JS в браузере: он должен использоваться только для вспомогательных фич. Условно: если хотите, можете сделать, чтобы форма отправлялась AJAX’ом без перезагрузки страницы. НО если я отключу JS - пусть форма отправляется обычным способом и это тоже должно работать.

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

Есть конечно веб-приложения, требующие SPA. Разного рода дешборды и карты. Тут вопросов нет. Но нужны они редко.

В каком тоне? Ты через текст можешь видеть в каком тоне я это сказал?

Я просто поинтересовался что такое «валидация пользователя». Я понимаю слово «аутентификация». Но аутентификация вполне реализуется без SPA и даже без JS. Я понимаю, что такое «валидация данных». Что такое валидация пользователя - не понимаю.

Ты начал закидывать меня каким то бредом.

Давай сразу к http - сколько параллельных соединений разрешено в протоколе 1.1? Как это обходили?

Потом мы зададимся вопросом о stateless. О печенюхах на 4кб, сессиях…

И только потом… Потом мы зададимся вопросом ЧТО можно смотреть, а что нельзя. И как это делали/ют.

К чему это всё?

если система не поддерживает какие то фичи, то программа не должна падать полностью, а должна отключать функциональность, требующую этих фич и работать дальше

Это значит затраты на дописывание дополнительного ssr ради долей процента пользователей что сидят с NoScript, когда вместо этого можно потратить усилия на новые rich-фичи, это называется прогресс, по этой причине в автомобиле не предусмотрены педали на случай если в нём кончится бензин. 🤷

по этой причине в автомобиле не предусмотрены педали на случай если в нём кончится бензин

А не надо использовать автомобиль там где достаточно велосипеда (пусть и с опциональным электромоторчиком для удобства).

Чувак, у тебя дислексия. Ты не можешь донести ни одной мысли своим текстом.

это называется прогресс

Я не вижу в этом прогресса.

Autowire не нужен: (1) он лишь запутывает код, как и любая магия, хотя декларировался как решение от запутанности кода связывания; (2) если связывать руками не всё вообще одной простынёй, а сначала контроллеры внутри слоя, а потом слои между собой – никакого спагетти не будет. Тривиальный рефакторинг, а на выходе всё чисто, просто и красиво. И стартовать будет мгновенно, в отличие от.

То же самое с аннотациями, в которых URL-и прописываются для веб-контроллеров. Централизованная функция (или декомпозированная на несколько функций, например по подсистемам), в которой явно императивно парсится URL и выполняется диспатч по контроллерам, – даёт на выходе неизмеримо меньший бардак и опять же мгновенный старт.

Общее правило: любая магия – зло. А спринг – это одна сплошная сраная магия.

Ах да, и ещё одно правило: метапрограммирование надо делать в buildtime. Вот это всё сканирование классов, генерация проксей и т.п.

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

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

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

В нормальном интернете браузер запрашивает у сервера страницу, в ответ получает готовый html/css/минимум js для некоторой интерактивности и пользователь рад. В ущербном интернете браузер запрашивает у сервера страницу, а получает мегабайты непонятно чего, это непонятно что потом опять обращается к севреру, чтобы получить гору json'а, из которого потом на лету пытается сгенерить html/css/ещё килограмм js, которое потом отдаёт браузеру и пользователь ждёт и матерится, пока всё это глючево отработает и надеется, что оно не упадёт молча на середине запроса, о чём пользователь разумеется не узнает.

Попытка имитировать поведение нормального приложения путём генерации html на лету ущербна в принципе по определению. Взять для сравнения любой почтовый клиент vs любой почтовый web-интерфейс.

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

А нечего использовать хром вместо браузера.

У всего есть обратная сторона. Rich web apps решают проблему синхронного обновления кода для всех юзеров, а «as a service» решает проблему пиратства. И то и другое – нифига не маркетинговая чушь.

А «200 метров жаваскрипта грузят текста 300 байт» – это про качество современных программистов и копроэкономику вообще. Говёной реализацией можно испоганить любую идею.

проблему синхронного обновления кода для всех юзеров

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

а «as a service» решает проблему пиратства

Это проблема маркетологов и продаванов. Опять же, не юзера.

Говёной реализацией можно испоганить любую идею.

Потому что конкретно данная идея говёная изначально. Пытаться повторить с помощью html/css то, что делает тулкит типа QT или GTK - это глупо. И это всегда будет жрать ресурсы. Условно говоря, каждый раз, открывая «web-приложение», ты скачиваешь, компилируешь и запускаешь на компе говёную реализацию QT/GTK, а говёная она, потому что язык разметки гипертекста не предназначен для создания приложений. Эта идея никогда не станет хорошей.

И ты в каждом втором посте говоришь о говёной реализации, будто бы есть другие. А ведь их нет. Не возможно найти ни одного примера хорошего «web-приложения» так как их не существует. Почему так, см. выше.

Ты сам сказал смотреть с точки зрения юзера.

Ну ок.

Пытаться повторить с помощью html/css то, что делает тулкит типа QT или GTK - это глупо.

Electron и QtQuick - говно, согласен.

Не возможно найти ни одного примера хорошего «web-приложения» так как их не существует.

Тут я не согласен, ну да ладно. Дело вкуса.

Я не говорил что шпринг это хорошо. Суть поста была в том фреймворк это или нет если можно подключить только очень небольшой кусок без пихания в веб.хмл и прочего

Хотя autowire имхо удобно.

А «200 метров жаваскрипта грузят текста 300 байт» – это про качество современных программистов и копроэкономику вообще

Вот кстати буквально недавно на такое наткнулся. Пытался понять что именно гробит рейтинг на web vitals и блокирует отрисовку. Оказалось что возле одной из надписей анимированная стрелочка с lottie. Сам svg байт 200, анимация ещё 200. А вот плеер чтоб ее запустить 350кб жабоскрипта, и при загрузке он дохрена всего делает. И все это ради одной попсовой стрелки которая стоит на три экрана вниз от начальной точки.

Гы. А кто этот плеер туда тянет? Или само притащилось с фреймворком каким-нибудь? ;)

Хуже. Конструктором сайта. Сайт поддерживает человек который хорошо умеет маркетинг и seo и плохо умеет ИТ, поскольку выделять отдельного фронтендера на «поменять картинку и текст на 28 странице» по десять раз на дню слишком накладно. В итоге когда рейт упал ниже 40 фронтам пришлось сесть и посмотреть что же там происходит. Собственно плеер подключается как только на странице есть хоть одна lottie

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

Браузеры существуют для показа сайтов, не для раковых «приложений».

Поскольку имею непосредственное отношение к двум проектам, где используется SPA в качестве пользовательского интерфейса, могу сказать, что это весьма практичный и удобный подход как для конечных пользователей, так и для взаимодействия разработчиков, админов, DevOps и Product Owner-а:

• можно реализовать любой удобный, адаптивный интерфейс;
• одна и та же кодовая база может использоваться как в SPA так и в мобильном приложении;
• обеспечивается разумное разделение по специализации разработчиков, упрощается сопровождение проекта;

Для веб-приложений с достаточно «хитрым» интерфейсом никакой другой удобной альтернативы, кроме мобильных приложений, просто нет.

Что касается начальной загрузки javascript-кода, то весь код сразу грузить не требуется - можно обеспечить разумную модульную загрузку. Ну и не такие уж это и «тонны» ) Вот, к примеру, весь javascript-код конкретного SPA на базе Vue.JS:

-rw-r--r-- 1 root root 162697 Jan  5 00:46 app.f1de0424.js.gz
-rw-r--r-- 1 root root   1125 Jan  5 00:46 chunk-2d0c8407.2abd3e91.js.gz
-rw-r--r-- 1 root root    294 Jan  5 00:46 chunk-2d0f0050.c97e4643.js.gz
-rw-r--r-- 1 root root    235 Jan  5 00:46 chunk-2d22c171.3e1d9422.js.gz
-rw-r--r-- 1 root root    521 Jan  5 00:46 chunk-2d230c96.27db3aba.js.gz
-rw-r--r-- 1 root root 250349 Jan  5 00:46 chunk-vendors.8962b4c7.js.gz
-rw-r--r-- 1 root root  41117 Jan  5 00:46 sw.js.gz

После загрузки такой код может лежать к кэше веб-обозревателя несколько дней.

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

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

Вот как-то так…

SPA-подход требует начальной грамотной проработки проекта и наличия квалифицированных спецов

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