Comments 102
По идее нужен Кен Томпсон и аналог Go, который заменил C++.
Давненько витают такие мысли. Нахреновертили так, что теперь сам черт ногу сломит. Боролись со сложностью так, что система борьбы со сложностью стала сама сложностью, которую не каждый руками просто так в своем проекте может написать.
Боремся с избыточными сущностями? А создали еще тысячи их. Если посмотреть что там под капотом и как это работает. Сколько вызовов функций просисходит чтобы сделать что-то элементарное, тогда как вообще, достаточно только одной?
Да, есть какой-то там процент где возможно так будет лучше. Но в большинстве кейсов, мне это напоминает работу ради работы. Создать себе проблемы, чтобы героически их решать.
И с грустью смотрю на то что нынче нужно, чтобы вообще начать что-то делать. Минимальный hello world. Раньше достаточно было включить комп, и уже можно писать программу (C64, ZX-Specturm). А теперь чем дальше, тем хуже и медленее. Чтобы что делать? Часто берут теперь здоровенную фигню, и разрабатывают на всем этом комбайне лэндос, который прекрасно отдается просто из файла веб-сервером без всяких скриптов. А сейчас фреймворк на фреймворке и фреймворком погоняет чтобы делать все то-же самое (в 90% случаев).
Золотые слова. «Создать себе проблемы, чтобы героически их решать» – это сегодня девиз индустрии.
Выстраивание 15 слоев абстракций вокруг вывода строки HTML стало нашей зоной комфорта. Бизнес за это платит временем и дорогими серверами, а мы – выгоранием, пытаясь собрать этот карточный домик из Webpack, гидратации и бандлов.
Спасибо за крутой и очень жизненный комментарий)
Зато посмотрите как прекрасно создаются рабочие места, порождая программных монстров в которых чтобы разобраться и поддерживать только нужен небольшой штат специалистов по всем этим технологиям из стэка. Отдельный человек чтобы деплоить, отдельный человек чтобы тестировать, несколько отдельных разработчиков для бэка и фронта. ВВП (прости господи) так и прет прям....
«Создать себе проблемы, чтобы героически их решать» – это сегодня девиз индустрии.
Примерно с такой же мотивацией 12 лет назад я решил больше не тратить своё время на фронтенды. Я думал, что это просто направление молодое, и что оно со временем устаканится и примет более здравый с инженерной точки зрения вид. Но проходят годы, а его состояние только ухудшается.
А чем ща занимаетесь?
Последние 12 лет занимался бэкендами, десктопом и эмбеддедом.
Эмбеддед в среднем сильно отстаёт в плане практик и инструментов (IDE относительно примитивные, DevOps начисто отсутствовал в достаточно серьёзных конторах, где я работал).
С десктопом ситуация лучше, но когда айти ушло в веб, на десктопе осталось много тех, кто не осилил переход и кто долгое время по факту демпинговал рынок труда, что плохо сказалось на этой области в целом.
В бэкенде сейчас самая приятная для инженера обстановка: много интересных и сложных задач, развитые инструменты и зрелые практики.
Ещё есть мобильная разработка. З/п выше, чем в бэкенде, но на счёт инструментов/практик я вообще не в курсе.
И ещё есть геймдев, в который все хотят войти (потому что все любят игры), и это плохо сказывается на зарплатах. Но играми я тоже никогда не занимался.
и при этом все стало работать хуже
Ну это и понятно. И это не говоря о производительности. Просто достаточно развернуть стэк вызовов. 20 вызовов чтобы в конце выполнить функцию, которая выполняется быстрее чем эта фигня из вызовов? Это сейчас нормальное явление. Мы греем воздух процессорами, которые 90% времени могут ничего не делать, только переходы, и не всегда даже условные.
А помните где-то у основоположников в какой-то книге был анализ, не помню у кого, что на каждые несколько строк обязательно да есть одна ошибка? Чем больше уровней и слоев, тем, следовательно, больше вероятность ошибок, просто за счет роста объема кода. И это даже не про скорость еще.
«Фу, перезагрузка страницы – это прошлый век!»
Мы просто трансформировали тонкого клиента в толстого. И в этом огромные преимущества для серверной инфраструктуры. Статический хостинг попробуй за DDOS-ить в отличие от Apache/Nginx + PhP-Fpm. Дак и к тому же накладные расходны гораздо меньше.
Я тоже непонимаю зачем возвращают серверный рендеринг. Идиотизм какой-то у них там в головах.
Отличный поинт про DDoS, честно говоря, я этот аспект даже не рассматривал в статье)
А ведь связка SPA + CDN – это самая дешевая и неубиваемая инфраструктура.
Вся шиза с возвратом рендеринга на сервер началась исключительно из-за SEO – и теперь SEO-адаптированные сайты просто стали модными и дорогими.
А как пришло к тому, что SEO стало актуальным сейчас? Проблема SEO существовала уже когда только пошли попытки рендерить что-то на клиенте. Казалось бы, сейчас поисковые краулеры должны быть поразвитей и спокойно поедать клиентский рендер. Но, выходит, нет?
Мне казалось, тема с Server Components больше выходит из того, чтобы обратно облегчить клиенты и ускорить полную отрисовку страницы. Или это и имеется в виду под "из-за SEO".
Гугл и яндекс умеют парсить SPA. Только спарсить готовый HTML гораздо легче, чем SPA. Запускать V8 в хедлесс хром для каждого маршрута SPA – дорого по серверному времени. Поэтому поисковики просто пессимизируют тяжелую статику, а бизнес ушел обратно в SSR.
Да, дурацкое SEO с этим придурочным лайтхаусом, где почему-то решили, что юзер не хочет пялиться на пустой экран пока скрипты загрузятся, распарсятся и исполнятся.
Динамика с адекватным cache-contol + CDN тоже неубиваемая штука
непонимаю зачем возвращают серверный рендеринг
Потому что у SPA значительно хуже позиции в поисковиках
Ну можно же для бота сгенерять статику основных страниц, а где нужен более динамичный функционал - там уже делать SPA.
Это отличный паттерн, если у вас четкое разделение: контентный сайт отдельно, а сложный ЛК – отдельно за авторизацией.
Но что делать, если это интернет-магазин, СМИ или портал, где контент перемешан с интерактивом (динамические цены, фильтры, корзина, сложный поиск)? Генерить статику для ботов и параллельно собирать SPA для живых людей – это буквально делать двойную работу и поддерживать две кодовые базы для одних и тех же страниц.
Именно из-за этой боли с пререндерами индустрия в свое время так радостно и бросилась в SSR (Next/Nuxt), чтобы писать код один раз. Но в итоге мы получили не "лучшее из двух миров", а сложность обоих подходов в квадрате.
Не так давно так и развлекались. Для людей ssr, для ботов html
Нечто подобное уже есть в nextjs. Правда работает в связке с SSR streaming, а не CSR. На уровне конфига задаются юзерагенты, для которых сайт генерируется в блокирующем режиме, при котором вся мета информация кладется строго в head, в отличие от SSR Streaming.
Но это другое…
Не очень понятное возражение, если честно. То, что пишет @MrEfrem, мотивировано лично для меня следующим: какого хрена SEO должно влиять на архитектурный выбор? Страницы для людей, не для ботов. То, что без поисковиков люди не увидят страниц оправдывает подгон архитектуры под SEO не больше, чем попытку изрезать колёса, чтобы они вошли в стандартную коробку доставщика, без которой на маркетплейсе не продать.
Почему нельзя поставить в пайплайн стандартный браузер, который бы подключался при приходе в гости краулера, и полностью отвязаться от архитектурной заточки под поисковики? В чём тут двойная работа? Во времени разработки? Так браузер пишете не вы. Во времени рендеринга? Так в норме доля краулера в трафике мала по сравнению с юзерами.
Ещё раз: при словах «мы это всё взваливаем на горб только потому, что так хочет Гугл», по идее, должна бы загораться красная лампочка в голове. А тут целая ветка, и все обсуждают, как так и надо )
Забудьте про СЕО - впереди ИИ-поисковики, пользователь получает ответ на поисковой вопрос в ИИ-чате.
Кто хочет тупеть - пусть пользуется. Меня по старинке всё устраивает. Утки вперёд!
GEO сейчас как раз работает над SEO, так что SSR все ещё необходим
Это не отменяет того, что парсеру нужен готовый HTML от сервера. Разница лишь в том, что теперь в поисковиках есть ИИ-сводка, которую ранее тупые боты уже спарсили и продолжают это делать.
SEO не уходит, оно просто видоизменяется.
Это только усугубляет проблему, так как ИИ тоже собирают информацию и разбираться в SPA не хотят.
Статический хостинг попробуй за DDOS-ить в отличие от Apache/Nginx + PhP-Fpm
ненене, давайте не будем сравнивать лопату с экскаватором. Вот у нас есть фронт на react или vue (одинаковый что для PHP, что для next/nuxt), вот бэк на REST или GraphQL, который отдаёт JSON. И вот тут пых задудосить намного сложнее, чем next/nuxt
Так я могу заддосить ваш Апи. Разве нет?
Тоже считаю, что старый подход был проще, понятнее и надёжнее. Для гибкости и интерактивности сейчас можно применять htmx.org или unpoly.com или связку alpine.js + alpine-ajax.js.org.
Опущены ИИ агенты, но ладно. И так сойдёт.
Помните 2010-е годы? Все писали на PHP.
Не совсем понял, что значит помните... А сейчас на чем сайты пишутся? Больше половины сайтов на Битриксах и Вордпрессах и прочем php...
Только они не пишутся, а кликаются, пишется только доп функционал к легаси на который страшно дышать
Да мы больше про новые стэки, которые очень модны нынче в крупных компаниях, в которых писать на PHP или чем-то вообще маленьком - просто дурной тон. Как там говорят: "Ты находишься в зоне комфорта и это плохо, нужно сломать все и преодолевать проблемы через боль. Если ты преодолеваешь проблемы без боли - значит плохо преодолеваешь, недостаточно мотивирован". Вот и все дела. Один раз я пришел на собес, мне там начали эту всю херню разгонять, реши такую задачу, реши сякую, а вот если вот это, а вот если то. Хотя некоторые из них решались на голом SQL на стороне сервера и я об этом сказал, что лучше "не надо городить огород". Но, понимаете, так решать нельзя, понимаете, тут недостаточно стэков в решении. Недостаточно боли...
Есть еще одна проблема - как только ты на собесе все это рассказываешь(автор абсолютно прав) тебя считают застрявшим в прошлом и не дают работу. Умные в современном IT не нужны. Нужны "молодые трендовые профессионалы". И это грустно
Никогда не понимал огромные js (и аналоги) фреймворки. Куча кода для чего? Сделать красивые анимации и переходы без перезагрузок? Так половину от этого умеет css, а вторую чистый js. А так это надо разбираться и писать все это, а мы (современные прогеры) не хотим ничего писать сами, лучше подключим готовый фреймворк и используем парочку его функций. А то, что у клиента это все грузится в 5 раз дольше и жрет трафика в 10 - вообще не наша проблема.
Я до сих пор пользуюсь jquery. Мне говорят: дед, пей таблетки, это же устаревшее говнище. Но оно работает, не грузится по пол часа и даёт все нужные функции. Так в чем проблема?
А про бек - пхп не зря воскрес из мертвых. Кто будет запускать виртуалку с node или next, ради маленького личного сайтика, когда можно запустить любую бесплатную php cms на трёх конечном хостинге? Это как ставить под капот жигулей v12 двиг.
Ну написанное говорит только вам в минус
Касательно jQuery, современный js действительно неплохо его заменяет
За такие слова надо тыкать пальцем и позорить, как за незнание основ. Это не токсичность, а бизнес-необходимость. Иначе здравомыслящим людям заказов не видать, как своих ушей.
jQuery был когда-то написан на замену не JS, а DOM API. Не может «современный JS» заменять jQuery или наоборот. JS просто не имеет прямого отношения к браузерам. Именно поэтому он может исполняться на сервере или в игровом движке.
Что касается DOM API, он написан замшелыми сишниками (с мохом под мышками) и ДО СИХ ПОР тащит в современный функциональный язык (JS) императивный подход с циклами и переменными. jQuery это не легаси, а очень даже модный подход для манипуляций DOM, буде в них возникает нужда, на основе декларативных преобразований вместо прямых инструкций. Но каждый раз какой-нибудь умник, видя его, считает нужным ляпнуть про легаси. Это относится, в первую очередь, к автору статьи, который, вроде бы, начинал за здравие, когда писал про победу маркетинга над здравым смыслом, но потом закончил тем же slur'ом, которым оперируют маркетологи, позволив себе такую лексику как «легаси jQuery».
Большую услугу миру UI окажет тот, кто возьмёт за основу jQuery, добавит в него давно напрашивающиеся фичи (например, подзапросы) и назовёт это всё «DQL» (DOM Query Language), jQ.nuxt или ещё каким-нибудь смузи-словом.
Поддерживаю. Я лично для своего пет-проекта написал собственный php микро-фреймворк, чтобы не тащить тысячи файлов от известных фрейморков. И в нем, как часть, встроена базовая JS библиотека (не надо jquery) и CSS микро-фреймворк (не надо всякого 1.5 МБайтного тайлвинда и прочих бутсртапов).
И вообще, стараюсь переходить на концепцию "чем проще - тем лучше".
А я делал... делал свой микрофеймворк. А потом оказалось, что на Symfony оно гораздо быстрее работает. И не надо постоянно код переписывать. Просто обновляешь фреймворк и всё работает. Хотя тоже есть некоторые проблемы. И вот прямо бесит, что ORM без привязки к конкретной БД. Столько времени уходит, чтобы подружить базу с сущностями. Реально проще SQL писать.
Цель jquery была минимизировать отличия в работе с DOM у разных браузеров и предоставить удобный API для поиска и изменения контента на странице. Сейчас это во многом стало ненужным, современный js умеет всё то же самое "из коробки", где-то с практически таким же синтакисом, где-то с чуть другим, но очень похожим. Поэтому я когда делаю какие-то мелкие доработки для админки, уже делаю это на чистом js.
Так половину от этого умеет css, а вторую чистый js. А так это надо разбираться и писать все это, а мы (современные прогеры) не хотим ничего писать сами, лучше подключим готовый фреймворк и используем парочку его функций
Я бы предложил не путать «голый js» и «чистый js» (в контексте браузера). Голый js так же уродлив и отвратителен, как голый семидесятипятилетный бомж или голая курица. Возьмём такую замечательную вещь, как Intersection Observer API.
const callback = (entries, observer) => {
entries.forEach((entry) => {
// Each entry describes an intersection change for one observed
// target element:
// entry.boundingClientRect
// entry.intersectionRatio
// entry.intersectionRect
// entry.isIntersecting
// entry.rootBounds
// entry.target
// entry.time
});
};
const options = {
root: document.querySelector("#scrollArea"),
rootMargin: "0px", // CSS?! In MY js?! Нет пути!!! (Серьёзно, это ужасно.
scrollMargin: "0px", // А если захочется стилизации под HiDPI? Под 4К/8К?).
threshold: 1.0,
};
const observer = new IntersectionObserver(callback, options);
Если мне сказать: вот тебе самое отборное LSD, придумай, как запутать этот код ещё сильнее, я зафейлю. Это задача не для слабаков. А ведь в 99% случаев программист хочет что-то очень простое, например:
$('#scrollArea').on('appeared', (el) => el.addClass('appeared'));
Но самое злое зло тут даже не синтаксис. Самое злое зло тут спрятано под капотом. Как хорошо знает каждый, кто нырял в этот бассейн с дерьмом, браузер по контракту не обязан давать никаких гарантий относительно вызовов колбека. Колбек может быть вызван один раз или много с одним и тем же значением threshold'а, поэтому заворачивать его в гарды (wasVisible, isVisible) должна вызываемая сторона. Которую в этом случае хочется похабно назвать «принимающая сторона».
Почему такое происходит? Это не случайно. Когда какая-нибудь злобная корпорация (назовём её «Гугл») становится монополистом в развитии какой-нибудь платформы (назовём её «HTML»), она первым делом начинает всё запутывать так, чтобы, не дай бог, новые пейджи и брины не написали свой Гугл на коленке.
Так что, вполне нормально, что здравый разработчик спешит эту грязь обернуть в $().on(). Ненормально, что потом ему говорят: а почему у тебя не «чистый js»? Ты, наверно, неосилятор? Ты, наверно, писать на «чистом js» не умеешь?
Подписываюсь.
Большая часть моих микросайтов - голый хтмл. Собрал себе бойлерплейт чтобы сразу был манифест для работы иконкой на телефоне и оффлайн, иконки (под замену, но сразу есть), ещё немного мелочей. JQwery не нужен так как 90% того за чем его брали раньше уже есть в ванильном js. Статичный сайт одним index.html, в нужные моменты fetch к бэку за данными. Хостинг - хоть на гитхабпейджс за 0 рублей для фронта.
Реально для получения страницы в браузере требуется слишком дофига всего - сборка, jsx, babel, webpack, настроенные процессы девопс, огромный головняк.
Одно меня печалит. Чем хорош реакт и иже с ним - возможность держать компоненты в отдельных файлах. Это чертовски удобно. Чтобы хедер страницы лежал отдельно, модалка авторизации отдельно, в файл все это вставлялось бы одной строкой. Особенно для работы с ИИ агентами - длинные файлы оно жрет не очень хорошо...
Alpine.js в целом решает проблему, но очень хочется это видеть нативно в браузере без лишних танцев с бубнами. И, кстати, в php это как раз было отлично решено )
Как вариант - создать собственный сборщик, который на этапе "компиляции" объединяет все html в 1, безо всякого лишнего JS в результате
Навеяло ностальгию)
Помню, как в 2015 с помощью gulp подкидывал общие сквозные элементы🥲
Astro?
так там опять сборка и вот это все - вместо нормального html и js
идеально: в любом месте страницы пишу <Header /> и файл компонента, вместе со своими стилями и скриптами вставляется на нужное место и работает. Все это в ванильном html без всяких сборок, зависимостей, node modules и прочей мути.
пока криво решил моим личным костылем:
сделал папку components, в ней папка, например, /header в которой html, js и css файлы
это простая статика, то есть никакой сборки, ничего - просто эту папку выкладываем вместе с index.html рядом
в коде страницы можно написать <header />, а вмместо импорта - массив всех доступных компонентов на странице. и если мой костыль (50 строк кода) видит компонент то идет в папку и забирает файлы. HTML грузится отдельно фетчем, JS импортом.
для мелких проектов но с большой интерактивностью мне было норм. Ну то есть все в одном index.html уже было сложно - 1000+ строк и файлом становится сложно пользоваться, аналогично с одним app.js или одним style.css - огромные файлы плохо и не удобно править. А тут удалось всякие модалки/хедеры/прелоадеры вытащить и все работает.
решение тупое, но простое, очень понятное, совершенно нативное.
НО: все это на клиенте, соответственно 100500 (да даже 50) отдельных компонентов это уже большое зло для любого устройства, даже с достаточно быстрой сетью. Ну и соответственно не масштабируется и не реактивное...
Одно меня печалит. Чем хорош реакт и иже с ним - возможность держать компоненты в отдельных файлах. Это чертовски удобно. Чтобы хедер страницы лежал отдельно, модалка авторизации отдельно, в файл все это вставлялось бы одной строкой. Особенно для работы с ИИ агентами - длинные файлы оно жрет не очень хорошо...
А что вам мешает использовать vite + шаблонизатор?
Да лишний слой dev-layer, но дает DX не плохой, собрал статику, отправил на сервер.
Чтобы хедер страницы лежал отдельно, модалка авторизации отдельно, в файл все это вставлялось бы одной строкой.
Apache с mod_include умеет в Server Side Includes:<!--#include file="header.html"-->
Никогда не понимал хайпа вокруг некста, инстумент ок, для своей ниши, но все заявленные плюсы настолько перетянуты за уши. Filesystem based роутинг, тег image с оптимизацией для сайтов на тильде, prefetch в link туда же, недомидлвары, код сплитинг, который по факту разбивает на банды примерно так: 1 общий на пару метров и далее несколько десятков по 20-30кб, найс.
Версель просто пытается всеми возможными способами всех загнать к себе на хостинг, и они решили сделать ставку на фронтендеров, заявив громким лозунгом: теперь ты не frontend, теперь ты fullstack, теперь ты можешь писать api, теперь ты умеешь работать с базой, теперь next делает за тебя всю работу, ну все и повелись.
Такое чувство в комментах началась перепись лоускил типов, тут тебе и фреймворки не нужны, и jquery всему голова и сборщики фигня
Может наоборот? Разработчик по мере профессионального взросления перестает городить комбайны из всего, что модно, и начинает думать о чистой архитектуре?
Сперва нужно определиться, что вы понимаете под чистой архитектурой. Для меня это то, что описано дядюшкой бобом. Не более. У меня никак не получается натянуть сову на глобус и обосновать отказ от фреймворков, сборщиков и других тулзов чистой архитектурой.Если вам кажется, что вы такой крутой и можете на изян справится с проектом без существующей экосистемы, то поспешу разочаровать, скорее всего дело в том, что проект просто мелкий и в этом всем не нуждается. Фреймворки берут не по фану, а для того, чтобы решить проблему поддержки больших приложений через композицию компонентов, так как с этим ментально проще работать, а также для того, чтобы получить из коробки реактивность, возможно роутинг и http клиент. Сборщики нужны не по фану, а чтобы компилировать одни входные данные в другие, и не ломать приложение при импорте условного svg или css модуля, чтобы тайпскрипт превращался в js, чтобы писать на актуальном синтаксисе, но транспилировать его в тот, что будет поддерживаться желаемым набором браузеров, чтобы сплитить код на чанки или наоборот объединять их в общие, которые можно удобно кэшировать.
Мой посыл не в том, чтобы тащить в проект все подряд, там где это не нужно, а в том, что не надо пытаться маскировать тривиальность вашего проекта или собственное непонимание существующей сложившейся экосистемы разработки, тезисом о переусложнении и ненужности этой экосистемы.
Тут не наш профиль) Статью про блоги / контентные сайты тегнули Реактом зачем-то. И так понятно, что для этих задач даже Wordpress тяжеловат и лучше что-то совсем простое на статике делать с минимальным шаблонизатором и нативным js для кнопки "лайкнуть". И уж точно тут не нужен Next или другой мета-фреймворк.
Люди ругаются, что для простейших задач кто-то тянет инструменты уровня "из пушки по воробьям", и это оправданно. А для веб-приложений действительно нужен полноценный стек. Одно смущает - что кто-то этого действительно не понимает и ставит минусы, думаю тут просто недопонимание.
Разработчик использует инструмент, в котором типовые задачи уже решены. Зачем заново изобретать велосипед?
Пишу с точки зрения пользователя, а не разработчика. Статья абсолютно в точку. Современные технологии сайтописательства и вебдевелопмента приводят в бешенство. Не знаю, что творится в головах обитателей башен из слоновой кости, но если они думают, что удовлетворяют какие-то запросы пользователей, то нет, ничего подобного. Всё развитие веб-приложений (а сейчас любой самый убогий сайт - это веб-приложение размером с хорошую такую ОС), последние лет 10 точно, идёт ровно в противоположном от удобства направлении. Но я подозреваю, что разработчикам этих монстров абсолютно наплевать на пользователей, потому что есть маркетологи, которые постоянно всем объясняют, что чем больше системные требования, тем продукт лучше.
Vue is даёт хорошую реактивность и не нужна нода. Как Беку мне нравится
Тем не менее современная разработка на Vue это калька с реакта. У них даже компоненты одинаковые, тот же tanstack. Ну и да, сплошной nuxt вместо next
Так-то реакт тоже можно без ноды юзать, через прямой импорт react и react-dom
В голос
почему sharp не собирается на Alpine Linux.
Ну не обязательно прям фолбечиться на пхп.
Можно взять Adonis, edge, alpine например
Это прекрасная статья, которая наконец озвучивает то, что копилось все эти годы: зачем начали усложнять веб?
И действительно: логика веба была проста и понятна всегда: есть программа с HTTP-сервером, который парсит запрос, выдаёт текст в виде plain/HTML/JSON/тд.. С каких пор там появился весь этот жир в виде бойлерплейтов, миддлвейров и прочего?
Зачем скачивать пользователю километры обфусцированных JS-скриптов, чтобы что? И зачем сервер нагружать лишними вычислениями?
Для админок, веб-приложений толстых и прочего. Там где раньше был Flash и Java-аплеты. Например биржевой веб-терминал статикой не сделаешь. Ну и чатик банально (хотя я делал на Ucoz с авто-рефрешем в 2009 и уже тогда это было устаревше). В общем применение то есть и много где.
Другое дело что не соразмерный инструмент тащат туда куда не нужно. Но как выше сказано - какой же ты сеньор если на реакте не пишешь, любители статики с простыми скриптами - это к джунам.
Ну а серверные компоненты нужны, помимо прочего, чтобы монетизировать реакт через облачные услуги. Грязный и болезненный способ, но теперь в документации реакта попробуй найти не фулстак версию, а create-react-app задеприкейтили. Комьюнити выросло, пора пожинать плоды.
Одна из главных проблем некста в том, что при серверном рендеринге вместо строкового шаблонизатора он использует объектную модель. Отсюда тормоза и потребление памяти.
Автор забыл ещё один момент. Что через 5-10 лет весь этот серверный код на прошлых версиях реакта станет экскрементами мамонта, которые никто не будет поддерживать без участия супер дорогостоящих инженеров. Цена поддержки будет космическая (хотя есть подозрение, что ИИ эту проблему нивелирует).
Абсолютно согласен. Экосистема React не позволяет написать код «один раз и навсегда». Я сам участвовал во вскрытии такого легаси: мобильное приложение известного ТЦ на юге РФ, написанное на React Native.
Приложение спокойно жило и работало годами, пока не вышел очередной апдейт iOS, сломавший всё. Чтобы просто заставить этот "современный" стек запуститься, нужно было мигрировать через 3 мажорные версии и разгрести ад зависимостей. Бизнес посмотрел на смету работ и просто похоронил приложение.
Вы правы: цена поддержки такого кода космическая, потому что ты платишь не за новые фичи, а за то, чтобы старый код просто компилировался.
Воу воу, у вас перебор адекватности. Я уже отвык от такого.
Напомнило старую статью «Вы не Гугл», если помните такое.
Я занимаюсь парсингом сайтов и могу с абсолютной уверенностью сказать, что сайты на старом добром “никаких SSR RSC TSR NEXT REACT” - это самая неубиваемая и стабильная зона. Они просто работают, у них нет проблем. Они просты в поддержке, да и не требуют поддержки :)
Но такое понимание приходит только с опытом. Поначалу хочется всего модного и крутого. Потом, когда у тебя деплой падает и приходиться пол ночи гуглить (а ты просто опечатку на кнопке исправил), осознаешь, что может ну его нафиг.
P.S. Из современных SvelteKit очень хорош. Если не усердствовать, будет все как по старому, но по новому.
У меня внезапно возникла интересная мысль
Почему люди создали SPA? Потому что глупо загружать каждый раз одни и те же элементы: хедер, футер, меню и т.д. Кэширование страдает от того, что всё в едином HTML. Но зачем всё так переусложнять, если можно:
Рендерить базовый Layout с шапкой и футером
Внутрь Layout добавить банальный iframe
Менять src у iframe в зависимости от нажатой кнопки в меню
При этом страницы можно писать на любом фреймворке. Они абсолютно независимы. Основная страница в браузере лишний раз не перезагружается, перезагружается только iframe. В чем проблема такого подхода?))
P.S. я конечно немного утрирую. Но ведь помимо этого существует ещё море более лёгких решений, чем SSR с гидратацией и тому подобное
P.S.S. даже нашел статью на тему iframe: https://habr.com/ru/companies/oleg-bunin/articles/716084/?ysclid=mmb3pe6bbn488742420 оказывается, всё уже придумали 30 лет назад)) тема с postmessage звучит очень многообещающе
Так делали в web 1.0 )
Были раньше не iframe, а просто frame. Но начиная с html 5 - больше не поддерживается.
А вообще есть такие технологии, например Hotwire для Ruby или универсальный но более тяжелый htmx. Там на запрос ты отправляешь в ответ кусок html со всем что нужно. Можно большие куски, можно и поменьше, например сообщения чата. В Hotwire там можно определить как ответ использовать - заменить контент, добавит до, после и прочее такое.
Статья - сплошное передёргивание. Взять пример с 'Hello world' и по нему сделать вывод, что Next не нужен - гениально!
Но вы попробуйте организуйте командную стабильную разработку какого-нибудь достаточно сложного продукта с клиентским взаимодействием на jQuery. Можно даже примеры в студию - обсудим, сколько это реально стоит
Спасибо за комментарий! Вы правы: писать сложный интерактивный SPA в большой команде на ванильном JS или jQuery – это выстрел в ногу. Это будет стоить дорого и быстро превратится в легаси.
Пример с «Hello World» – это намеренная гипербола, чтобы подсветить базовый оверхед, который современный стек тянет за собой.
Как я и отмечаю в статье: фреймворки отлично дают архитектурный каркас для большой команды. Боль в другом – сейчас этот тяжелый стек начали тащить по дефолту вообще везде: в статичные лендинги, простые блоги и визитки. Фреймворк перестал быть осознанным решением под уровень задачи.
Интересно ваше мнение: где, по-вашему, сейчас проходит адекватная граница применимости того же Next.js? С какого масштаба проекта он начинает полностью окупать свой вес?
Я одного не понимаю, почему люди до сих не поняли - браузер это больше не штука для отображения статичных данных, это полноценная кроссплатформенная VM, с огромным функционалом, и самое главное, безопасная. То есть открывая сайт, мы понимаем, что он не подсунет кейлоггер, не отошлет все пароли на сервер. Любое такое приложение работает в песочнице. И это приложение не надо скачивать, вот оно, открой ссылку и используй. Именно отсюда растут ноги у всех этих сложных телодвижений - попытка упростить создание иногда суперсложной логики в приложении, которое пишется на языке, который никогда не был для этого предназначен, но поменять его уже не выйдет.
И в целом, это не плохо, с одной стороны, потому что во времена, когда пиком был phpbb, представить, что фигма будет полностью работать на клиенте с кастомным рендерингом и модулями на другом языке было невозможно. Но оно вот, здесь. В браузере уже даже GTA SA работает.
И я, в итоге, буду писать личный бложег на Next.js, даже если для него index.html за глаза. Знаете почему? Потому что я хочу когда-нибудь попасть в ту самую команду из 50+ разработчиков, которыми нужны строгие рельсы ;)
Но в целом, согласен. Недавно искал фреймворк для SPA, так они все на SSR повернуты сегодня. Делал проект на vite-шаблоне, в итоге..
Но по поводу зависимостей, автор так перечисляет, мол, тут у нас только PHP, а тут и нода и бандлер и тд. и тп.. Imho, во втором случае у нас только одна зависимость: node. А все остальное - это разные пакеты работающие на самой ноде. С тем же PHP (если не брать уже настроенный хостинг) все посложнее будет.
Сайт будущего это диалог с LLM.
Забавно что на Rust уже есть пара проектов - Leptos и Dioxus, которые решили скопировать модель React с серверными компонентами. Да так что у диоксуса тоже своё облако. Теперь и на Rust можно поиграть в серверный и клиентский код в одном файле. Только там следующий уровень сложности - попробуй отдебажить WebAssembly, собраный макросом с кастомным языком для тегов внутри Rust.
Используйте Go/Python/PHP на бэке и HTMX на фронте. Best of both worlds.
PHP (2010):
// index.php
// Без конфигов. Без сборки. Только код.
$db = new SQLite3('products.db');
$result = $db->query('SELECT * FROM items');
?>
<ul>
<?php while ($row = $result->fetchArray()): ?>
<li><?= $row['name'] ?></li>
<?php endwhile; ?>
</ul>Next.js RSC (2026):
// page.tsx (Server Component)
// Зависимости: Node.js, Webpack, Babel, PostCSS...
import { db } from './db';
export default async function Page() {
const items = await db.query('SELECT * FROM items');
return (
<ul>
{items.map(item => (
<li key={item.id}>{item.name}</li>
))}
</ul>
);
}обожаю подобные примеры) как часто всё, что вам нужно сделать с данными - это отрисовать из них <ul> с <li> внутри? в реальном мире каждый элемент массива запросто может быть самостоятельным компонентом с кучей внутренних состояний. очень хочется посмотреть, как вы с этим справитесь, используя первый подход)
и я не то чтобы защищаю сервер компонентс - нет, я тоже против них. просто примеры не нужно упрощать до безобразия, реакт сейчас даёт куда как больше удобства, чем php 16 лет назад)
Существует множество менеджеров, вынужденных доказывать руководству свою нужность, и употребление как можно большего количества модных слов это самый простой способ.
Параллельно существует множество инженеров с той же задачей, но реализуемой через усложнение своих решений. В том числе и для того чтобы никто кроме них в созданном ими хаосе не разобрался.
Плюс из последних лет — усложнение всего материального/железного ради усложнения ремонта.
Если ты делаешь просто – ты джун. Если ты делаешь сложно – ты сеньор.
У кого-то прочел мысль о том, что если ты делаешь сложно — ты мидл. А вот сеньор знает как сделать код мидла проще.
Со статьей согласен, все херня, дайте фигму на jquery с прегенеренной статикой
Похожий случай когда ради одного ajax запроса подтягивается целый jquery =)
Как мы изобрели PHP, но в 10 раз медленнее: почему React Server Components – это архитектурный тупик