Комментарии 29
Неужели можно использовать PHP и Python и это даже в чём то стабильно - надёжней?
Когда то делал сайты, объяснял клиентам преимущество серверного рейдинга, только все просто кричали - React, нам только самые передовые технологии. Как и кто будет это поддерживать никто не задумывался, сколько будет стоить обслуживания - тоже.
То, что js не у всех работает и может быть по соображениям безопасности отключен, то же для многих было неправдоподобно из их реального опыта.
Ох уж эти священные битвы, SSR vs CSR vs SSG....
html это верстка, которая производится от дизайна/макета и слишком много бизнесовых и конфигурационных атрибутов в ней ухудшает поддерживаемость кода, так что htmx выглядит как решение для одной формочки на сайте, доступное любому вебмастеру, но не более того
Из Баден-Бадена?
Давно пора.
Сделайте сайты быстрыми снова.
Ох уж эта цикличность в веб-разработке... Я на этой карусели катаюсь с 2010 года, и до сих пор все по-старому) Вырастает\выпускается из универа новая порасль голубой крови веб-разработчики, НАСТОЯЩИХ программистов - бэкенд разработчиков - начинается свежая волна "зачем нам фронт". В мире PWA, пуш уведомлений, оффлайн работы и SW. И каждый раз с таким видом, будто на Марс первыми высадились. А те, кто десятилетиями отрывал бек от фронта и выносил фронт туда, где ему и место - да они же дурачки просто, то ли дело мы. Всех этих ребят ждет поле из граблей, которое приведет их в конечном итоге, куда привело тех, кто внедрял MVС, создавал React и иже с ними... Сейчас мы в точке цикла "все должно быть на беке!"
Смешно. Те же мысли. Но я считаю, что причины разделения бэка и фронта не технические, а коммерческие. Нужно превратить индустрию в конвейер! При больших масштабах это просто дешевле, еще Форд доказал ;-)
Ну да, ну да. А потом "грузится, грузится, грузится..." - потому что сначала надо загрузить 100500 жабаскриптов, потом забить всю память (купите еще 16 гигабайт рамы, жалко штоле?), а потом получить, наконец, {"reply":"access denied"} и вывести табличку "Что-то пошло не так попробуйте еще раз"
Смысл отрывания фронта от бека - только ради унификации с телефонными приложениями, чтобы ТАМ написать прикладуху, которую не надо ниоткуда тянуть, и работать с тем же бекендом, что и на сайте.
Для самих сайтов, которые в интернете и через браузер - это зло.
Что, кстати, можно было бы решить через middleware которое бы сидело на сервере, работало с беком по тому же API, что и прложения, но рендерило страницы без всех этих фронтенд-извращений.
Но это же лишние расходы...
При чем эти ребята вкорячивают nextjs, начиная каждый новый page со строчки 'use client' и прям обмазываются кайфом что они такие правильные, "используют SSR" 😁👍
Однако, в большинстве проектов из реального мира, которые мне приходилось видеть, мобильные приложения всегда имеют пользовательскую базу, отличающуюся от пользовательской базы веб приложения.
Не знаю что там у автора за реальный мир, в котором на сайте и в приложении будут разные юзеры. Я даже одного примера такого безумия придумать не могу.
Такое встречал пару раз, но это не было, чем-то рядовым. Как раз наоборот , было большой проблемой.
1 случай.
Веб сайт и windows приложение имели 2 разные удаленные бд на одном сервере. Приложение работало с mssql напрямую, через пользователя с сильно ограниченными правами. Чем это плохо (всем) думаю, объяснять не нужно. Ну а сайт был на php cms (не помню на какой) и работал через mysql стандартно. Видимо, разработчики приложения не поняли, как сделать, хотя бы обращение из приложения к mysql и решили сделать 2 базы данных, что синхронизировались, через крон скрипты на пайтоне (видимо в то время, информацию по готовым библиотекам на нём, найти было проще). Одним словом большой костыль, который и пришлось решать, путём создания нормального апи для приложения.
2 случай
2 сайта одной компании, которые развивались параллельно и в один момент, нужно было сделать единый вход для пользователей. Решить эту проблему оказалось относительно просто, через социальную авторизацию. Один сайт стал "главным", а на второй можно было зайти только через авторизацию первого. Хотя это больше не про использование двух разных баз, а скорее речь только про данные пользователей.
Конечно, можно ещё привести в пример проекты, где используются nosql + sql бд или например несколько бд для архивации или миграций (между серверами), но это не совсем, то что имел автор.)
Веб сайт и windows приложение имели 2 разные удаленные бд на одном сервере. Приложение работало с mssql напрямую
Ну я допускаю такое для какой-то внутренней кухни, но понятно же что выкладывать такое в мир это безумие.
А так любой нормальный сервис будет иметь общую бд для пользователей, неважно через какой клиент они заходят. И вроде как все крупные сервисы так и работают, может быть какие-то нишевые, бедные предприятия и делают как написал автор, но это точно не то на что стоит рассчитывать.
Да, я про то и говорю, что 2 разные бд это больше проблема, чем решение. Как раз в том случае с приложением и сайтом, нам пришлось писать апи для приложения, чтобы всё работало с единой бд.
может быть какие-то нишевые, бедные предприятия
На данный момент даже у них обычно всё сделано по уму, т.к. их программисты используют готовые решения, чтобы не тратить много времени.
Я делал веб-приложения на SSR, с bootstrap, и его jquery-плагинами. Это очень похоже не htmx - тоже добавляются всякие data-аттрибуты, и из div-ов получаются всякие модалки и datepicker-ы.
Оно работает пока:
на надо много логики, меняющей dom. Даже просто вставить новую строчку в табличку - уже неприятный вопрос: либо как-то тащить шаблон строчки с сервера, либо дублировать рендеринг строчки на клиенте.
Пока разработчики (фулстеки) бережно и вдумчиво пишут html и css: пишут переиспользуемые шаблоны для кусков страниц и компонент, хорошо секут в html/css/js
Если эти условия не выполняются, в шаблонах и css/js вокруг начинается такой ад, что приложение на 50 таблиц и 20 скринов уже не полчается развивать нормально. В моем случае, его переписали на реакт, и все прыгали от восторга.
Но если сайт плюс-минус статический - нет сложных форм, и прочего такого - может по-классике и будет проще.
Пока разработчики (фулстеки) бережно и вдумчиво пишут
Верно и для всех других типов приложений. Любой Реакт\Некст ломается мгновенно, когда "Фронтендеры" перестают думать о структуре проекта.
Вот только те кто думают, быстро приходят к выводу что Реакт, а тем более СПА - это скорее плохо для 99% приложений.
Не приходят, потому что есть еще понятие кодовой базы! Всякие UI либрари, взаимодействия с формами, стейт менеджерами, все это написано и работает в реакте. Поэтому просто отказаться в пользу голого HTML проблематично достаточно, потому что разработка будет явно замедлена!
Но есть же SSG! На выходе те же html страницы, такой же быстрый рендер! А под капотом тот же реакт со всеми плюшками. Так что я не понимаю в чем в принципе особая проблема..
я не говорил что они отказываются от сахара вообще в пользу голого html.
Просто надо не запихивать целиком все в реакт, а делать виджеты. Да по другому чутка работает, но столько лишней сложности уходит. И htmx тут очень хорошо подходит. 99% веб приложений не нуждается в чем-то более сложном.
ССГ это хорошо, вот вы и вернулись к тому, о чем была статья изначально. Велком.
Только статья про Спринг, а не про JS фреймворки. И со стороны Спринга действительно проще делать SSG + htmx.
Так что я не понимаю в чем в принципе особая проблема..
Проблема в том что SPA - это дефолтное решение. Фронтендерам не приходит в голову мысль что можно НЕ делать SPA, не тащить стейт менеджмент, не тащить рутер и тп. Попробуйте, вам понравится.
Меня всегда удивляло вот это "как-то тащить с сервера" - и искреннее непонимание в глазах программиста, как можно притащить с сервера строчку и вставить ее в таблицу (как пример).
Или еще хуже: "а как я получу с сервера только цифру 22.14?"
Как-как, да просто тупо строкой "<tr><td>22.14</td></tr>", которую создаст текущий шаблон на сервере (ответственность верстальщика и дизайнера), подставив в него данные из базы (ответственность бекендера), и просто воткнуть эту строку между "предыдущей" и "следующей" в DOM (ответственность фронтендера, умеющего задать в ЧатГПТ вопрос "как в джаваскрипте вставить элемент после элемента?").
Вы когда-нибудь встречали веб приложение, где изначально появляется что-то одно, но через секунду или две, появляется что‑то другое или что‑то одно заменяется на что‑то другое?
Хаха! Я здесь живу в нём сейчас пишу!
Сначала грузится страница со скроллом к комментариям, затем она начинает прыгать (рекламный блок же прогрузился!), а после и вовсе заменяет все прогруженные комментарии ошибкой вида «что-то пошло не так». Если же ошибка не пропала, то поле ввода комментария будет бесконечно «радовать» отпрыгиванием курсора куда-нибудь (как правило, в начало текущего абзаца).
Ну, веб был задуман именно чтобы сервер выдавал HTML. Потом что-то пошло не так.
Нужно уметь выбирать и применять технологию по мере уместности, а не потому что что-то модно, а что-то вечно.
Про версионирование, а если на SSR юзер оставит вкладку открытой на неделю, а разраб поменяет шаблон формы и изменит обработчик - добавит поле или поменяет путь до него - форма как должна узнать на старой вкладке что она старая? Эта проблема присуща обоим подходам и решается в обоих подходах одинаково. Нет её только если приложение абсолютно монолитно и предназначено для прикладных оффлайн задач. Калькулятор, excel, word... - какой оффлайн в вебе? (электрон извини, ничего личного 🫡)
У CSR есть ряд плюсов.
Во-первых сложное динамическое взаимодействие на чистом SSR выстроить нереально сложно. В любых современных SSR проектах есть острова клиентского рендера там, где много связей и сложный пользовательский путь.
Во-вторых CSR экономит трафик. Не приходится гонять кучу разметки по сети. А бандлы джаваскрипта весят меньше, если написаны не макаками. По итогу мы гоняем только json который легче + может кэшиться на уровне клиента через query cache плагины (tanstack query, rtk query...)
В-третьих (что там автор про производительность говорил?), по названию подхода очевидно, что в рендере представления участвует только клиент - мы снимаем с сервера эту задачу, оставляя под его ответственность только передачу бандла (что часто отводится вообще отдельному веб-серверу) и (непосредственно на backend) dto.
Ну а если вы писали SSR - вы уже фуллстек. Неважно куда вас забросит судьба - на фронт или бэк. Хороший программист грамотно мыслит везде.
А вот интересно, как рендеринг на стороне сервера отобразит постепенную загрузку чего либо, например когда на бэке идёт долгий расчет? Или как будет работать denounce? Пользователь будет смотреть на пустую страницу или опять-таки загружать тот же JavaScript.
В том же React есть возможность разделить бандл, чтобы была ленивая загрузка компонент, когда они потребуются.
Ощущение, что статью писали люди, которым нужно было просто написать очередную статью, чтобы оправдать свои подходы, не разбираясь в альтернативах.
Я как-то работал над проектом на Vaadin. Штука прикольная, но жутко тормозная. Зато "веб-приложение на Java, без HTML и JS" - это ли не мечта джависта?
Нуу, в целом конечно да... О некоторых проблемах я и не задумывался... Но тут скорее просто нужно смотреть по ситуации а не везде лепить что то одно, будь то SSR или SPA. Например мне нужно было создать не сложный интернет магазин, то я хоть и люблю Vue, но заюзал Livewire с Laravel и это вышло быстро и по кайфу. Страница рендерится на сервере, потом клиент нажимает кнопочку, я из Livewire компоненты, через джс, напрямую вызываю функцию в PHP классе этого компонента (не, там кнш ясен пень, полк а потом на сайте livewire делает update запрос на сервер, но оно так ощущается легко), и ты вот делаешь валидациб формы, прямо в php, и если ошибки, прямо их выводить в хтмл, и все это без перезагрузки livewire динамически подменяет на отреднеренную сервером новую форму с ошибками например. И выходит что вроде бы SSR, но работает как SPA, динамично и без перезагрузок. Единственный минус, это пинг, обновления происходят не моментально, и если сделать простой счётчик, то на Vue каком нибудь он будет работать моментально, а тут нажимаешь плюсик, делается запрос на сервер, там он обрабатывается, добавляется еденичка, сервер рендерит новый счётчик, отвечает клиенту текущим состоянием и отреднеренным хтмл, livewire его подставляет и запоминает состояние. И это все накладные затраты. Но когда это не критично, прям по кайфу. Или вот сейчас работаю на работае с проектом где бекенд Spring, а фронт на Next.js и при этом все чем занимается бекенд это отдает сложные many to many и не только связи, на фронтенд, что бы отрендертть табличку... И поост столько всего нужно по итогу писать, кучу DTO, кучу типов и на бекенде и на фронте, запросы, управлять этими отношениями на фронте, что вот мы получили проекты, теперь надо бы получить документы этих проектов, и просто... Кошмар... И для этой задачи тот же Livewire был бы намноооооооооооооого проще и оптимальнее, можно было бы просто взять Laravel модель, и просто вывести... А в итоге такое дикое усложнение просто потому что... Вот просто ошибка что технологии применяют, потому что это модно, а не там где реально нужно... И SPA не зло, много где это оч классно, и насчет кнопки back я не понял прикола если там просто history api юзается
Проблемы, которых у меня больше нет, потому что я использую рендеринг на стороне сервера