Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 186
По идее нужен Кен Томпсон и аналог Go, который заменил C++.
Точно подмечено. Разница лишь в том, что Go создавали инженеры для решения бизнес-проблем Google. А современные веб-абстракции часто создаются вендорами (Vercel и ко) просто для продажи своей инфраструктуры. Упрощать им невыгодно.
Go, который заменил C++
Не напомните, в какой момент это произошло?
В котором хайлоад проекты переписали с С++, особенно заметно в трейдинге и гемблинге. Мой опыт подтверждает
У Go, конечно же, есть ниша, из которой он подвытеснил другие языки. Но утверждать, что он заменил собой C++ вообще, я бы не стал. Я вообще с трудом могу представить себе язык, который бы вытеснил C++ изо всех ниш, умудрившись при этом самому не стать драконом.
Я вообще с трудом могу представить себе язык, который бы вытеснил C++ изо всех ниш, умудрившись при этом самому не стать драконом.
Ну пока что мне кажется, что Rust очень меееееееедленно, но постепенно и планомерно это действительно делает и действительно является альтернативой.
Посмотрите на языковые конструкции Rust, ну это совершенно не читаемо... На C++ можно писать код, который будет понятен человеку с улицы. Мы для кого пишем программы - для компьютера (тогда можно и на ассемблере писать) или для человека?
Признаться я не знаю ни Rust, ни C++ (только ANSI C). И вот как человеку со стороны, именно C++ кажется довольно стрёмным, непоследовательным и непонятным (особенно всякие темплейты, анонимки и проч.).
Конечно, опыт не нулевой, но вот это "по верхам", думаю, можно приравнять к "не знаю".
Так что как "человек с улицы" (понимание JS/TS/C#/Java/PHP не считается) я бы всё же C++ указал как самый нечитаемый и непонятный язык, даже при условии что это вроде как наследник С, который я более-менее понимаю.
При этом C++ куда более читабельный чем Rust, даже если брать стандарт C++23.
Если всё таки сделать небольшое усилие над собой и постараться выучить основные конструкции и концепции языка, то C++ как раз покажется вполне логичным языком.
C++ куда более читабельный чем Rust, даже если брать стандарт C++23
Вот как раз наслоения стандартов и делают ещё него монстра.
Я 7 лет на c++, 15 лет менеджмента, 3 года c#, PHP (исключительно из LLM потому что PHP мне противен) и чисто для пет Rust. Вот Rust больше всего нравится. А на плюсы смотреть страшно.
При этом C++ куда более читабельный чем Rust
Ну... std::vector<bool> действительно читаемый...
Rust очень меееееееедленно, но постепенно и планомерно это действительно делает и действительно является альтернативой.
Очень медленно. Бесит
Хотя, может LLM поможет преодолеть пресловутую ступень обучения Rust
Золотые слова. «Создать себе проблемы, чтобы героически их решать» – это сегодня девиз индустрии.
Выстраивание 15 слоев абстракций вокруг вывода строки HTML стало нашей зоной комфорта. Бизнес за это платит временем и дорогими серверами, а мы – выгоранием, пытаясь собрать этот карточный домик из Webpack, гидратации и бандлов.
Спасибо за крутой и очень жизненный комментарий)
«Создать себе проблемы, чтобы героически их решать» – это сегодня девиз индустрии.
Примерно с такой же мотивацией 12 лет назад я решил больше не тратить своё время на фронтенды. Я думал, что это просто направление молодое, и что оно со временем устаканится и примет более здравый с инженерной точки зрения вид. Но проходят годы, а его состояние только ухудшается.
А чем ща занимаетесь?
Последние 12 лет занимался бэкендами, десктопом и эмбеддедом.
Эмбеддед в среднем сильно отстаёт в плане практик и инструментов (IDE относительно примитивные, DevOps начисто отсутствовал в достаточно серьёзных конторах, где я работал).
С десктопом ситуация лучше, но когда айти ушло в веб, на десктопе осталось много тех, кто не осилил переход и кто долгое время по факту демпинговал рынок труда, что плохо сказалось на этой области в целом.
В бэкенде сейчас самая приятная для инженера обстановка: много интересных и сложных задач, развитые инструменты и зрелые практики.
Ещё есть мобильная разработка. З/п выше, чем в бэкенде, но на счёт инструментов/практик я вообще не в курсе.
И ещё есть геймдев, в который все хотят войти (потому что все любят игры), и это плохо сказывается на зарплатах. Но играми я тоже никогда не занимался.
Фронтенд действительно не устаканился - но это не потому что люди глупые, а потому что задача объективно сложная: UI по природе stateful, event-driven, асинхронный, и при этом должен работать в браузере - среде, которую ты не контролируешь.
Но "создать проблемы чтобы решать" - да, Webpack -> Vite -> Turbopack, Redux -> MobX -> Zustand -> Signals - часть этой чехарды действительно лишняя.
"со временем устаканится" - это ожидание из мира бэкенда, где HTTP/SQL/REST стабильны десятилетиями. Фронтенд ближе к gamedev (?) по природе - там стабильности не будет.
И на фронт-энде все быстро устаревает - для молодых, но не для тех кто не хочет переучиваться каждый год. Лучше, пусть LLM следит за модой!
фронтенд привлекает людей с низким порогом входа...
и при этом все стало работать хуже
«Фу, перезагрузка страницы – это прошлый век!»
Мы просто трансформировали тонкого клиента в толстого. И в этом огромные преимущества для серверной инфраструктуры. Статический хостинг попробуй за 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 + CDN – это самая дешевая и неубиваемая инфраструктура.
И бесполезная ) Относительно, конечно. Это ведь справедливо только для статики. А если есть данные, то этому SPA всё-равно нужен сервер с базой и всё тем же рендерингом. И этот сервер так же будет уязвим для DDoS.
Разница ведь между старомодным серверным рендерингом и SPA лишь в формате генерируемых бэкендом данных - html vs json. И их объёме, соответственно. Но так ли критичен этот объём?
непонимаю зачем возвращают серверный рендеринг
Потому что у SPA значительно хуже позиции в поисковиках
Ну можно же для бота сгенерять статику основных страниц, а где нужен более динамичный функционал - там уже делать SPA.
Это отличный паттерн, если у вас четкое разделение: контентный сайт отдельно, а сложный ЛК – отдельно за авторизацией.
Но что делать, если это интернет-магазин, СМИ или портал, где контент перемешан с интерактивом (динамические цены, фильтры, корзина, сложный поиск)? Генерить статику для ботов и параллельно собирать SPA для живых людей – это буквально делать двойную работу и поддерживать две кодовые базы для одних и тех же страниц.
Именно из-за этой боли с пререндерами индустрия в свое время так радостно и бросилась в SSR (Next/Nuxt), чтобы писать код один раз. Но в итоге мы получили не "лучшее из двух миров", а сложность обоих подходов в квадрате.
Не так давно так и развлекались. Для людей ssr, для ботов html
Нечто подобное уже есть в nextjs. Правда работает в связке с SSR streaming, а не CSR. На уровне конфига задаются юзерагенты, для которых сайт генерируется в блокирующем режиме, при котором вся мета информация кладется строго в head, в отличие от SSR Streaming.
Но это другое…
Не очень понятное возражение, если честно. То, что пишет @MrEfrem, мотивировано лично для меня следующим: какого хрена SEO должно влиять на архитектурный выбор? Страницы для людей, не для ботов. То, что без поисковиков люди не увидят страниц оправдывает подгон архитектуры под SEO не больше, чем попытку изрезать колёса, чтобы они вошли в стандартную коробку доставщика, без которой на маркетплейсе не продать.
Почему нельзя поставить в пайплайн стандартный браузер, который бы подключался при приходе в гости краулера, и полностью отвязаться от архитектурной заточки под поисковики? В чём тут двойная работа? Во времени разработки? Так браузер пишете не вы. Во времени рендеринга? Так в норме доля краулера в трафике мала по сравнению с юзерами.
Ещё раз: при словах «мы это всё взваливаем на горб только потому, что так хочет Гугл», по идее, должна бы загораться красная лампочка в голове. А тут целая ветка, и все обсуждают, как так и надо )
Почему нельзя поставить в пайплайн стандартный браузер, который бы подключался при приходе в гости краулера
В какой (чей) пайплайн его поставить? К чему он должен подключаться?
Если, как тут говорят, Google пессимизирует страницы, которые ему приходится рендерить, из-за накладных расходов на рендеринг, может взять эти расходы на себя напрямую, а не путём подгона архитектуры под SEO? Вместо удобства пользователей и разработчиков? Идея в этом. Как сделать технически — не знаю, это не мой профиль. nginx поддерживает плагины?
Об этом и статья. Примерно к этому сейчас и пришли. Только используют не браузер (он весь и не нужен), а лишь его движок. Это всё-равно подгонка архитектуры под SEO. Для этого всё-равно нужна дополнительная программа на сервере или отдельный сервер, дополнительная логика обработки запросов. В плане удобства тут не всё так однозначно.
Это ж какие нужны мощности у гугла, чтобы каждый сайт через браузер прогонять
Забудьте про СЕО - впереди ИИ-поисковики, пользователь получает ответ на поисковой вопрос в ИИ-чате.
Кто хочет тупеть - пусть пользуется. Меня по старинке всё устраивает. Утки вперёд!
GEO сейчас как раз работает над SEO, так что SSR все ещё необходим
Это не отменяет того, что парсеру нужен готовый HTML от сервера. Разница лишь в том, что теперь в поисковиках есть ИИ-сводка, которую ранее тупые боты уже спарсили и продолжают это делать.
SEO не уходит, оно просто видоизменяется.
Это только усугубляет проблему, так как ИИ тоже собирают информацию и разбираться в SPA не хотят.
Статический хостинг попробуй за DDOS-ить в отличие от Apache/Nginx + PhP-Fpm
ненене, давайте не будем сравнивать лопату с экскаватором. Вот у нас есть фронт на react или vue (одинаковый что для PHP, что для next/nuxt), вот бэк на REST или GraphQL, который отдаёт JSON. И вот тут пых задудосить намного сложнее, чем next/nuxt
Так я могу заддосить ваш Апи. Разве нет?
Можете. Но статику фронта вы в любом случае скачаете со всеми преимуществами CDN. И туда даже может быть сразу встроен статический контент.
А отказоустойчивость api - это проблемы их архитектуры со своими решениями.
Но ведь там преимущества разве что в распределённости только. На CDN ведь статику выдают такие же условные Apache/Nginx. А их запросами статики разве реально заддосить?
Apache/Nginx + php-fpm !== Apache/Nginx (sendFile). Тут php-fpm выступает как более узкое горлышко. А если ещё и делаете какие-то IO операции из php - то естественно ситуация становится ещё хуже.
В любом случае отдача чистой статики средствами одного веб-сервера будет дешевле. И статику можно кешировать на клиенте, прокси, и т.д. Я конечно уже не помню в деталях, может что-то подобное связанное с кешированием для php-fpm тоже есть.
В любом случае отдача чистой статики средствами одного веб-сервера будет дешевле.
Я, конечно, с php-fpm не работал (использую другой стек), но подозреваю, что и там это так же должно работать. Для статики php ведь и не нужен.
взрослые дяди очень давно всю статику раздают либо с CDN, либо со своих аналогов CDN - в общем, выделенных под это дело nginx-ов, которые ничем больше не занимаются. Ну может ещё TLS терминируют.
Тоже считаю, что старый подход был проще, понятнее и надёжнее. Для гибкости и интерактивности сейчас можно применять htmx.org или unpoly.com или связку alpine.js + alpine-ajax.js.org.
Опущены ИИ агенты, но ладно. И так сойдёт.
Помните 2010-е годы? Все писали на PHP.
Не совсем понял, что значит помните... А сейчас на чем сайты пишутся? Больше половины сайтов на Битриксах и Вордпрессах и прочем php...
Только они не пишутся, а кликаются, пишется только доп функционал к легаси на который страшно дышать
Да так про любую CMS можно сказать. Однако, в Бикриксе и Вордрессе, чтобы красивую структуру файлов шаблонов создать, типа такой:
приходится сильно попотеть. Особенно в Битриксе, где шаблоны компонентов обязательно в конкретной папке должны лежать.
Только они не пишутся, а кликаются, пишется только доп функционал к легаси на который страшно дышать
Это так. Но остальная половина пишется на Symfony и Laravel, которых выше крыши на проектах любого уровня. Первое - типикал кровавый ынтерпрайз, который может местами напихать Спрингу, а второе под всякие MVP, который уже отжал рынок у RoR и Django.
Ну кроме совсем микро-чего-то, где нынче властвует Go.
Есть еще одна проблема - как только ты на собесе все это рассказываешь(автор абсолютно прав) тебя считают застрявшим в прошлом и не дают работу. Умные в современном IT не нужны. Нужны "молодые трендовые профессионалы". И это грустно
Видимо, это были не те собесы. Как раз таки то, что ты понимаешь, где конкретно нужны данные технологии, делает из тебя специалиста. Думаю, если на собесе дадут задачу написать хелло ворлд, а кандидат пойдет собирать проект на Next.js, его не примут))
Можно порассуждать наверно, но если вы сразу пришли с установкой, что вы умный, а эти дураки только react/nextjs могут писать, то что ещё ожидать?
Никогда не понимал огромные 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 или ещё каким-нибудь смузи-словом.
Никто и не говорит, что библиотека jQuery должна заменить целый ЯП. Имелось ввиду, что из-за фичей современного JS, подходов к разработке, по большей части, отпала необходимость в jQuery. Что, в общем-то очевидно.
Необходимость в jQuery, в первую очередь, была обусловлена незрелостью и многословностью API JS. Вспомните сами эти document.getElementByClassName. $('.button') конечно же проще. И цепочка методов тоже хорошо. jQuery упрощал работу не только с DOM API. Но и с анимацией и сетевыми запросами.
Но! Зачем использовать $.ajax(...), если есть fetch, верно? Зачем использовать animate() и анимировать через JS, когда CSS анимации отлично работают. Да и querySelector упростил работу с DOM...
А по поводу модного подхода для манипуляций DOM... Ну я тут в корне не согласен: манипулировать напрямую DOM - плохая затея, если вас большего одного человека в команде. Можно и не понять, в какой момент и где происходят изменения.
P.S. Я не говорю, что сейчас не найдется задачи для jQuery, просто по большей части, надобность в нем отпала: из-за современных фич JS, библиотек реактивного рендеринга, компонентного подхода, их состояния и т.д.
Кажется в этом треде совсем забыли про одну важнейшую функцию jQuery.
Во далёкое время одна компания решила что стандарты для слабых и решила что будет реализовывать их так как считает нужным, что привело к тому что у разных браузеров одни и те же фичи были реализованы по разному. jQuery же позволял просто забить на это и писать один код для всех, а весь слой совместимости он брал на себя.
А мне кажется, в этом треде (как и по жизни) слишком много людей, неспособных увидеть в jQuery что-то помимо слоя совместимости (действительно, ныне неактуального) и поэтому кричащих про легаси. DOM API — вот где лютое легаси. Прямо открыть MDN, читать по алфавиту и плакать. Пример с Intersection Observer я привёл по соседству, с подробным разбором.
Я не люблю нитпикать цитаты и обычно так не делаю, но в данном случае это проще всего.
Никто и не говорит, что библиотека jQuery должна заменить целый ЯП
Было написано: «современный js действительно неплохо его заменяет». Я на это ответил, что их даже сравнивать нельзя. И это так и есть. И, главное, хоть самый-распресамый современный ES возьмите, это никак не повлияет на легаси-статус jQuery. Повлиять могут только изменения DOM API. Которых нет и не предвидится.
Необходимость в jQuery, в первую очередь, была обусловлена незрелостью и многословностью API JS.
Я не берусь судить про «обусловленную необходимость», то есть, про то, чем мотивировался John Resig. Факт, однако, в том, что это два абсолютно разных подхода. Как SQL и плоские файлы. В одном случае — декларативный запрос, в другом — императивщина с циклами и переменными. Можно ли сказать, что необходимость SQL была обусловлена незрелостью и многословностью плоских файловых систем? Наверно. Есть ли в этом смысл? Я так не считаю. Потому что, куда должны дозреть плоские ФС с их API'ями, чтобы вы пересели на них с языка запросов? Аналогично, пока DOM API остаётся императивным, желающие писать декларативные запросы будут вынуждены использовать что-то навесное.
Но! Зачем использовать $.ajax(...), если есть fetch, верно? Зачем использовать animate() и анимировать через JS, когда CSS анимации отлично работают.
$.ajax() не является частью DOM API и архитектурно это хелпер, что о нём говорить? Отдельно замечу, если бы свои fetch'и написали для DOM API, то jQuery действительно стал бы легаси. Но этого как раз и не случилось.
.animate() это как домкрат — предполагается, что вы используете его не при повседневной езде, а только в случае ремонта в дорожных условиях (но на этот случай он быть обязан). В данном случае — когда CSS что-то не поддерживает. А не поддерживает он, например, подключение JS-библиотек для сложных вычислений параметров следующего кадра. Нужда в них бывает очень редко, но когда бывает, нужно иметь возможность эти библиотеки подключать декларативно. Хотите пример? Трёхмерное облако элементов (например, тегов). Тригонометрия появилась в CSS относительно недавно, и как бы ещё вы сделали его вращение? И я не уверен, что такие особенности, как физическая инерция при вращении, могут быть переписаны на pure CSS (без .animate()). Более того, я даже не уверен, что пытаться переписать инерцию вращения облака тегов в терминах CSS — в принципе хорошая идея. Хотя, конечно, в большинстве случаев .animate() не нужен, а описание на CSS рулит. Но если нужен, это неправильно, когда вычисления запускаются каким-то отдельным таймером, а не из цепочки запроса.
манипулировать напрямую DOM - плохая затея, если вас большего одного человека в команде
Ну да, ну да. Это, конечно, так, когда ваш коллектив из 50 эффективных берёт готовые компоненты, которые пишут такие, как я. А булочки растут на деревьях ))
надобность в нем отпала
Нет, не отпала. Просто вы (не лично вы, конечно), цитирую, «изобрели PHP, но в 10 раз медленнее».
Поддерживаю. Я лично для своего пет-проекта написал собственный 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» не умеешь?
Куча кода для чего?
Для тех ситуаций, когда задачи посложнее маленького личного сайтика.
Когда куча разной сложной логики с кучами компонентов.
И в таких ситуациях суммарный код приложения с тем самым большим и толстым фреймворком оказывается внезапно намного проще и короче.
А если пытаться это все имитировать на чистом JS то внезапно получается так, что ты переизобретаешь тот самый фреймворк и пишешь его с нуля в виде своего личного/корпоративного велосипеда, у которого не будет ни документации ни экосистемы, ни тестирования огромным сообществом со всего мира, ни дополнительных компонентов от сторонних разработчиков
а мы (современные прогеры) не хотим ничего писать сами
Мы, современные прогеры, пишем не маленькие личные сайтики, а большие приложения с со сложной бизнес логикой.
И нам вполне хватает работы по написанию этой самой бизнес логики, чтобы не переизобретать велосипеды и не делать каждый раз в каждой компании еще один аналог допустим Vue и допустим библиотеки компонентов к нему вроде например Element Plus.
Я имел дело с гибридными приложениями где часть была написана как раз на чистом JS (частично вообще чистый, частично JQuery) а часть на Vue (бэк кстати как раз на PHP) и было очень наглядно видно насколько чистая JS/Jquery часть больше, сложнее и запутаннее.
И при этом еще была обвешана велосипедами вроде самописных компонентов.
Только не спрашивайте откуда такое берется, одно слово - legacy.
Мерять потребности современных прогеров исключительно написанием маленьких личных сайтиков и hello world откровенно тупиковый путь.
Потому что это только так кажется что вот просто выпадающий список - что тут возиться-то? А завтра нужно в него данные подгружать динамически причем не простым запросом к серверу, а сложным в зависимости от других компонентов. Послезавтра нужно делать уникальный сложный шаблон для каждого элемента этого выпадающего списка. И само собой все это нужно стилизовать в по заданному дизайнером макету в рамках единого стиля. И подружить с другими данными и другими компонентами на странице. И так далее и далее десятки самых разных случаев на каждый из которых навешивается свой уникальный велосипед из чистого JS-кода или десятки разнородных библиотек от разных авторов с разными подходами к стилизации и api.
Подписываюсь.
Большая часть моих микросайтов - голый хтмл. Собрал себе бойлерплейт чтобы сразу был манифест для работы иконкой на телефоне и оффлайн, иконки (под замену, но сразу есть), ещё немного мелочей. 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) отдельных компонентов это уже большое зло для любого устройства, даже с достаточно быстрой сетью. Ну и соответственно не масштабируется и не реактивное...
SSI?
так там опять сборка и вот это все - вместо нормального html и js
Ну так сборка и позволяет избавиться от сложности. Я тоже могу делать просто HTML страницу и даже так делал. Но потом в этой каше сложно разобраться. Можно поделить на фрагменты, которые будут отвечать за каждый отдельный элемент интерфейса. Банально, разнести в разные файлы заголовок страницы с меню и футером. Просто потом возникает вопрос как потом собрать всё в кучу. Одним из первых моих решений было использовать PHP. Да. Банально инлудил файлы. Тогда естественно никакой сборки не было.
В любом случае, какую-то сборку сейчас приходится применять. Ну не руками же создавать CSS со всеми совместимостями под разные браузеры? Можно какой-нибудь тайлвинд влепить и обвешаться гигантскими наборами классов для каждого элемента, как будь-то мы попали в 90-е годы, где у многих тегов были вереницы атрибутов.
Свой сборщик, своя система однофайловых компонентов, потом еще свою библиотеку для хранения состояния и свой роутер, свою библиотеку стандартных компонентов... и вот постепенно у нас уже самописный аналог React/Vue/Angular, непонятный никому кроме вас, без документации, не оттестированный миллионами пользователей со всего мира, не имеющий экосистемы сторонних компонентов и библиотек.... не дай бог мне оказаться на поддержке такого проекта, когда вы свалите в лучшие края и перестанете его поддерживать.
Впрочем так далеко сторонники создания собственных сборщиков и микрофреймворков не думают.
Именно. По этому я себя по рукам бью как только мне приходит в голову такая мысль. И беру нормальный фреймворк.
Наши приложению нужен роуминг, стор и реактивность, то мой костыль это зло. Но и тащить на сайт визитку или на что-то совсем маленькое, типа мини админки, весь этот мусор из больших фреймворков - нафиг не надо.
Одно меня печалит. Чем хорош реакт и иже с ним - возможность держать компоненты в отдельных файлах. Это чертовски удобно. Чтобы хедер страницы лежал отдельно, модалка авторизации отдельно, в файл все это вставлялось бы одной строкой. Особенно для работы с ИИ агентами - длинные файлы оно жрет не очень хорошо...
А что вам мешает использовать 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 точно, идёт ровно в противоположном от удобства направлении. Но я подозреваю, что разработчикам этих монстров абсолютно наплевать на пользователей, потому что есть маркетологи, которые постоянно всем объясняют, что чем больше системные требования, тем продукт лучше.
Важна скорость разработки. Тяп-ляп, в сроки уложились, збс. Что, у тебя конкретно тормозит? Ну купи комп помощнее, или нищеброд?
/ не про Вас конечно. Вам плюсую. Просто такая вот логика, по всей видимости.
Для того, чтобы у меня просто открывался ЛК Билайн, я был вынужден поставить отдельный Firefox из последних. И да, оно не просто тормозит, оно адово тормозит. Один сраный статичный сайт. Отдельный браузер, потому что в Хром это поделие уже не открывалось. И в этом отдельном браузере загрузка их сайта = по времени загрузки Вин 8 на этом ноутбуке.
Vue is даёт хорошую реактивность и не нужна нода. Как Беку мне нравится
Тем не менее современная разработка на Vue это калька с реакта. У них даже компоненты одинаковые, тот же tanstack. Ну и да, сплошной nuxt вместо next
Так-то реакт тоже можно без ноды юзать, через прямой импорт react и react-dom
jQuery в своё время создавался для расширения и унификации браузерного API в императивном стиле. Современный JS полностью его нивелирует, предоставляя полностью идентичный функционал. Пусть и не такой лаконичный и мб выразительный, но всё же.
Vue в своё время создавался как расширение браузерного API (поддержка кастомных тегов, события, биндинг и вот это всё) в более декларативном стиле. Современный JS его полностью нивелирует, предоставляя полностью идентичный функционал. Пусть и не такой лаконичный, но всё же.
Т.е. моё имхо, что ни Vue, ни React, ни проч. в современном мире не нужны и такой же атавизм, как и jQuery, т.к. оно уже всё есть из коробки в браузерах (я про ядро и изначальный смысл). Максимум что можно поставить -- это Lit для удобства и какой-нибудь Alpine для интерактивности.
Всё что за счёт чего ещё живут сабжевые Vue и React -- это (опять же, имхо):
Подозреваю, что подавляющее большинство фронтов не понимает, что можно без них писать кастомные компоненты с событиями, двусвязным биндингом и вот этим всем
У Vue/React помимо самого ядра -- довольно серьёзная экосистема вокруг, слишком много плагинов, пакетов и прочего.
В голос
почему sharp не собирается на Alpine Linux.
Ну не обязательно прям фолбечиться на пхп.
Можно взять Adonis, edge, alpine например
Это прекрасная статья, которая наконец озвучивает то, что копилось все эти годы: зачем начали усложнять веб?
И действительно: логика веба была проста и понятна всегда: есть программа с HTTP-сервером, который парсит запрос, выдаёт текст в виде plain/HTML/JSON/тд.. С каких пор там появился весь этот жир в виде бойлерплейтов, миддлвейров и прочего?
Зачем скачивать пользователю километры обфусцированных JS-скриптов, чтобы что? И зачем сервер нагружать лишними вычислениями?
Для админок, веб-приложений толстых и прочего. Там где раньше был Flash и Java-аплеты. Например биржевой веб-терминал статикой не сделаешь. Ну и чатик банально (хотя я делал на Ucoz с авто-рефрешем в 2009 и уже тогда это было устаревше). В общем применение то есть и много где.
Другое дело что не соразмерный инструмент тащат туда куда не нужно. Но как выше сказано - какой же ты сеньор если на реакте не пишешь, любители статики с простыми скриптами - это к джунам.
Ну а серверные компоненты нужны, помимо прочего, чтобы монетизировать реакт через облачные услуги. Грязный и болезненный способ, но теперь в документации реакта попробуй найти не фулстак версию, а create-react-app задеприкейтили. Комьюнити выросло, пора пожинать плоды.
Потому что на вебе начали писать не только личные микросайты и hello world, но и большие, сложные приложения с кучей бизнес-логики.
Кучей какой логики?
Да вполне банальной например интерфейсной выходящей за пределы личного микроблога который состоит из двух простеньких страниц - список записей и текст собственно записи. И который все здесь приводят в пример типичной задачи для программиста, по которой надо оценивать фреймворки.
Вот например есть форма. Полей на 20-30 разных типов. В первые 5 полей предзагружается набор данных на основе стартовых параметров, во вторые пять проставляются и подгружаются данные на основе комбинации введенных в первые пять полей, где-то еще на 10 полей ниже есть таблица (само собой не совпадающая ни с какой единичной таблицей в БД), в первой колонке выпадающий список который собирается запросом из нескольких таблиц на основании введенных выше данных, во второй колонке выпадающий список, зависящий от выбранного в первой, в третьей колонке поле для ввода в котором в зависимости от выбранных значений в первой и второй могут вводится данные разных типов - строка, число, выпадающий список. Само собой в этой таблице можно удалять и добавлять строки.
И это только часть интерфейса на данной странице, это только форма сбоку.
А с другого боку есть еще набор вкладок (не браузерных) внутри которой здоровая форма и еще вкладки, а внутри них еще здоровая форма и в ней еще таблица.
Удачи вам писать все это на ванильном JS без фреймворков, а потом поддерживать.
Я уже писал выше, что мне доводилось работать над гибридным проектом где часть была написана на JQuery, часть на ванильном JS, часть на Vue + Element Plus и было вот прямо очень наглядно насколько чище, короче, проще для понимания и быстрее получается код во Vue части.
А того что вы говорите - ну это 1% всех проектов.
На самом деле гораздо больше. Просто они как правило пишутся для профессиональных пользователей внутри компаний и не видны широкой публики. А так внутри одной не особо крупной компании могут быть десятки таких систем, в крупных сотни. И в этом "кровавом энтерпрайзе" работает как бы не большинство программистов - напрямую либо через подрядчиков.
В качестве условно известного широкой публике примера можно разве что почту привести - яндексовскую например или gmail (не только главное окно с письмами но и все экраны с настройками вроде почтовых правил например), и то корпоративные интерфейсы бывают намного сложней.
Очень странно, что это приходится обьяснять на Хабре. Я бы понял такое недоумение где-то на Пикабу, а не на сайте, который был раньше все таки ориентирован на техническую аудиорию.
Тогда вопрос уже переходит на плоскость того, что вообще означает фраза "сложные приложения". Если подразумеваются гиганты типа Facebook/VK/Pinterest и прочего, то тогда почему другие делают на этих инструментах "микросайты", ведь очевидно, что инстурмент под них не подходит?
Если подразумевается какой-то сервис, работающий на CRUD-операциях, то это лишний жир, без которого код не усложнится. И тогда аргумент превратится в очередное "разработка дорожает", но от мира веба.
Тогда два вопроса, просто чтобы развить тему:
- Не задумывались ли Вы о том, что проблема не в инструменте, а в прямоте рук? Иначе C/C++, PHP умерли бы с десяток лет назад. Суть-то в правильной архитектуре. Очевидно, что для сложного приложения нужно продумать грамотную структуру работы, иначе на полпути мы получим спагетти-код и жесткие циклы из условий и коллбеков. Тогда вопрос, а так ли нужен современный фреймворк или всё же нужен нормальный инструмент, который проявит себя с грамотным применением?
- Что такого магического есть у фреймворка, который позволяет делать сложные приложения с кучей бизнес-логики, чего не умеют классические решения? Вот чем принципиально отличается "сложное приложение" от несложного? Все говорят "для сложных приложений с кучей бизнес-логики", но никто не поясняет какой..
Тут комментировать только портить
То есть раздувание 10-строчного кода отдельным модулем с библиотеками, которых больше, чем строк этого кода?
habr.com/ru/articles/141477 :)
Этот рак индустрии имеет давнишнюю отправную точку.
"Поэтому, на этой неделе мы представим единую фабрику фабрик фабрик инструментов, чтобы каждую фабрику фабрик инструментов Вы могли произвести с помощью одной, объединенной фабрики. Фабрика фабрик фабрик будет производить только те фабрики фабрик инструментов, какие Вам нужны, и каждая из этих фабрик фабрик будет производить фабрику, основанную на Ваших требованиях к инструменту. Окончательный набор инструментов, полученных в результате этого процесса, будет идеален для вашего конкретного проекта. У Вас будет именно тот молоток, который вам нужен, и рулетка, подходящая именно под эту задачу, и все это по нажатию одной кнопки (конечно вам придется немного поработать с конфигурацией, чтобы заставить все это работать именно так как вам надо)."
Господь, жги.
Тогда вопрос уже переходит на плоскость того, что вообще означает фраза "сложные приложения".
Ответил здесь.
Что такого магического есть у фреймворка, который позволяет делать сложные приложения с кучей бизнес-логики, чего не умеют классические решения?
Они позволяют писать эту самую бизнес логику более простым, коротким, понятным и быстро работающим кодом и не переизобретать велосипеды для тех задач, которые одинаковы по всему миру и переиспользовать один и тот же код который тестируется миллионами пользователей по всему миру.
А так же они дают единые соглашения по структуре папок, файлов, общепринятым подходам и единую экоситему документации и разработчиков, которые эти соглашения знают.
Но вообще-то в наше время такие общеизвестные вещи можно спросить у любого ИИ.
Одна из главных проблем некста в том, что при серверном рендеринге вместо строкового шаблонизатора он использует объектную модель. Отсюда тормоза и потребление памяти.
Автор забыл ещё один момент. Что через 5-10 лет весь этот серверный код на прошлых версиях реакта станет экскрементами мамонта, которые никто не будет поддерживать без участия супер дорогостоящих инженеров. Цена поддержки будет космическая (хотя есть подозрение, что ИИ эту проблему нивелирует).
Абсолютно согласен. Экосистема React не позволяет написать код «один раз и навсегда». Я сам участвовал во вскрытии такого легаси: мобильное приложение известного ТЦ на юге РФ, написанное на React Native.
Приложение спокойно жило и работало годами, пока не вышел очередной апдейт iOS, сломавший всё. Чтобы просто заставить этот "современный" стек запуститься, нужно было мигрировать через 3 мажорные версии и разгрести ад зависимостей. Бизнес посмотрел на смету работ и просто похоронил приложение.
Вы правы: цена поддержки такого кода космическая, потому что ты платишь не за новые фичи, а за то, чтобы старый код просто компилировался.
реакт-нейтив поменял архитектуру, да, но обиднее всего всего когда зависимости реакта подтягиваются под версии macos, точнее руби... то есть старый проект на новой машине ты не заведешь)
Первопричина здесь то, что вендор диктует правила. Он заставляет обновлять систему. Если не двигаться вместе с комьюнити RN и через 3 года столкнуться с тем, что накопилось слишком много всего.. значит плохо понимали, что такое react-native. С ним нужно успевать шагать, вслед за обновлениями os. Да, у натива больше стабильности, вендор заинтересован в гладком отказе от легаси, но вести две кодовые базы - тоже такое себе удовольствие.
Воу воу, у вас перебор адекватности. Я уже отвык от такого.
Напомнило старую статью «Вы не Гугл», если помните такое.
Я занимаюсь парсингом сайтов и могу с абсолютной уверенностью сказать, что сайты на старом добром “никаких 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 =)
Вспоминаю древние времена Drupal 7, когда сделать Ajax запрос с обновлением части DOM было настолько просто, насколько это вообще возможно. А потом пришли джаваскриптизёры и наворотили в вебе такого, что просто не по себе становится, когда осознаешь, сколько всего там под капотом происходит для выполнения самых простейших задач.
Рекомендую взять Go + HTMX, и вы почувствуете, как будто вышли со свалки на опушку леса и вдохнули полной грудью чистейшего воздуха. А если ещё добавить Alpine.js для самой простой интерактивности, не требующей запросов на сервер, то вы покрываете практически всё что вам предложит этот монстр: Next.js
Откровенно странный подход - сравнивать системы по и пригодности для написания hello world или крохотного личного блога. Очевидно же, что все это создается для написания больших и сложных приложений с кучей запутанной бизнес-логики.
Для личного блога сейчас и программировать не надо, тот же wordpress поднимется и настроится с кастомными темами и плагинами без единой строчки кода. Если кому-то еще нужны в наше время личные блоги на отдельном сайте.
База.
Скрытый текст
У кого есть вакансия на middle+ frontend react next.js?
Вот поэтому я и создал вот это:
Старый добрый серверный рендеринг https://habr.com/p/869844/
А потом ещё вот это https://habr.com/ru/posts/941958/
Всё происходящее по этой части в индустрии было вызвано не какими-то реально полезными техническими нововведениями, а:
Внедрением подобных технологий для захвата и монополизации рынка с последующей целью монетизации (маркетинг, все дела).
Карьерные игры на местах с целью выжимать из работодателя бабло
Приведу цитату, она точно описывает всё происходившее:
В ит слишком. много. бабла. При таком количестве бабла компаниям сходят с рук любые ошибки, в том числе и содержание задротов, играющихся в технологии. Как только начнут считать деньги, всю эту плесень смоет
Нормальная реакция на всю свору технологий:
Я, как динозавр, привык, что если я делаю сайт — он прослужит лет 5, и если что — его можно будет через 5 лет спокойно подправить, а не переписывать с нуля. А этот «стек технологий» через 3-5 лет окажется ворохом непонятно работающих, неподдерживаемых и сбоящих механизмов. Потому что сами инструменты устаревают, форкаются, модифицируются с дикой скоростью — мы еще не поняли, нужен ли нам Grunt, а он уже устарел, вместо него Gulp, и так далее.
И чтобы все это работало, придется искать Babel «той самой версии 2017 года, когда ES9 еще не было», от npm отказаться, потому что половина библиотек переедет на другие сервера, а webpack окажется давно заброшен, «так как в стандарте еще в 2019-м появились нормальные инклюды». И вместо того, чтобы легко найти и поправить строчку в нужном файлике, придется искать детранспилятор Unbabel, распаковщик webunpack, и по крупинкам вычищать синтаксический сахар «еще того года».
Мимо PHP-шник. Сам пилю пет-проект более 10 лет, самопис от бека до фронта. Ни одного фремворка, ни одной библиотеки, только пара некритичных php-зависимостей (типа генерации sitemap).
Всё происходящее по этой части в индустрии было вызвано не какими-то реально полезными техническими нововведениями, а:
Внедрением подобных технологий для захвата и монополизации рынка с последующей целью монетизации (маркетинг, все дела)
сейчас бы монополизировать рынок опенсорсными библиотеками/фреймворками) особенно занятно читать такое от адепта церкви чат-ботов, производители которых как раз и стремятся к монополизации. шиза в чистом виде, где хочу вижу заговор, а где не хочу - прекрасное будущее)
Сейчас бы верить в то, что раз технология опенсорс, то она не влияет на рынок... Сейчас бы базовую экономику в "шизу" записывать, инвестиций и акций ведь не существует, правда?) Корпорации, видимо, эти технологии от чистого сердца пилят, добрые самаритяне)
Если вы хотите понять, как можно монополизировать рынок опенсорсными решениями, предлагаю изучить историю Chromium, как он отказался от поддержки NPAPI, к чему это привело и как "опенсорсный" Chromium привёл гугл к монополизации их V8.
вдруг громкое слово "монополизация" превратилось в тихое "влияет на рынок", как же так) про стремление к монополизации тех, кто производит ваших любимых чат-ботов, и вовсе никто не удосужился ответить - и правда, зачем) неудобно получится
И вдруг про монополизацию Google с V8 мы, конечно же, стыдливо умолчали, как же так) Что насчёт ботов, они мне неинтересны, к чему вы приплели это соломенное чучело, не понимаю.
Ну и я так полагаю, вы отклонили предложение изучить историю, ведь "неудобно получится")
Советую научиться читать до конца, где уже пояснена монополия.
P.S. - ну и минусовать, это очень сильный аргумент, сразу видно зрелость и взросление личности
В 2026 году и написать докерфайл — это, конечно же, непростая задача, которая определённо делает деплой сложнее)
А на алпайне много что не работает или странно работает. В любом серьёзном проекте рано или поздно на эти ограничения наткнётесь. Тот же OTP крайне не рекомендуется ставить на мюсли.
В целом, ваша проблема в том, что вы сравниваете голый язык и фреймворк.
Здесь было бы честно сравнить с кодом на голом NodeJS, который отдавал бы отрендеренные HTML-страницы, аля CGI/WSGI.
п.с. На хрена в нексте редис?
Не понятно, чем именно вы недовольны - php никуда не делся, продолжает существовать и развиваться. Вы спокойно можете продолжать писать web на php с server side rendering, vanilla js. Вам никто не запрещает.
Более того, он оброс очень удачными фреймворками, посмотрите что сейчас собой представляет тот-же Laravel.
Причина появления server components очевидна, ее никто не скрывал - это performance, который нельзя получить в SPA. Вы считаете вам не нужна такая гонка за клиентский опыт, для вас performance - не конкурентное приемущество? Отлично, не пользуйтесь rsc, вас никто не заставляет, у вас есть много альтернатив.
Технологии, методологии, протоколы, языки, фреймворки, библиотеки, тулы - хоть все и позволяет делать одно и тоже, но даёт разный результат, и путь к этому результату приходится преодолевать точно разный, разной тернистости.
Это всё здорово, конечно, но такое "конкурентное преиущество" стоит клиенту трафика и производительности, к тому же мы бонусом получили от React2Shell и падения половины Интернета в попытке её починить. Это длилось всего пару дней, но это очень показательный пример, как часть Интернета может стать уязвимой просто потому, что многим захотелось немного performance.
Никто, конечно, не заставляет пользоваться небезопасными решениями, которые объединяют фронтенд и бекенд, напрямую нарушая стандарт (!) клиент-серверной архитектуры. Но думаю, вы будете ОЧЕНЬ недовольны, если ваши данные условно сольют из-за уязвимости в инструменте или в важный момент упадёт один из ваших любимых сайтов.
Узявимости могут быть у всех, но чем сложнее технология, тем больше шанс того, что там лежит дыра в безопасности. Просто о ней не знают не потому что её там нет, а потому что её мало не заметит в переусложненном коде.
Да, наш FE отдел как раз закончил миграцию с Next на чистый React + Vite
Приложение стало работать в 4 раза быстрее ххххх
Заранее извиняюсь, если кого-то уже повторю (вероятность велика 170+ комментов на этот момент). Но, пока я их все прочитаю, мысль уйдет.
Я сам фигову тонну лет писал исключительно на php. Соглашусь со многими мыслями в статье, особенно про hello world. Единственно для меня непонятно зачем между nextjs и облаками от vercel ставить знак равно. Берём чистый сервер (читай впс), вместо php ставим node и все. Остальное же все один к одному (база, http сервер и прочая лабутень).
А по большому счёту соглашусь с основной мыслью. Пыха по сей день более чем достаточно для написания многих вещей. Но таких сценариев все меньше и меньше.
Есть же vuejs - гораздо проще и собирается мгновенно
Идеально.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы изобрели PHP, но в 10 раз медленнее: почему React Server Components – это архитектурный тупик