Comments 32
главное отличие в том, что мы больше не создаем "спагетти-код".
поперхнулся смузи
Мы используем проверенные временем принципы разработки UI и современные инструменты.
php'шному symfony 20 лет, реакту около 10, а серверному (ну так, чтобы в проде, а не в бложиках) и того меньше. ни современности, ни старых надежных принципов
про js и "проверенные временем принципы разработки" особенно смешно
А теперь добавьте нового комментария с клиента: нужно либо заново прописывать HTML-структуру в JavaScript, либо использовать хитрые трюки вроде скрытых шаблонов. Это был настоящий головняк, особенно если HTML-классы менялись.
/get_new_comment -> (HTML-block) -> element.innerHTML = result
Головняк - обалдеть. Не, ну можно конечно на каждый пук создавать DOM в браузере заново (и многие так и делали)
Результат мы все видели (жаль, что не все уже помнят, что этого можно было избежать):
SSR должен был вернуться и он вернулся. Жаль только, что в статье js рассматривается как единственный теперь язык (экосистема и тп).
В статье почему-то не написано самое существенное чем Next.js отличается от PHP. Каким образом стираются границы. Про единый код рендеринга как на сервере, так и клиенте. Про прозрачные для разработчика обновления данных на клиенте.
Писать "спагетти-код" на React тоже можно, ровно как и хорошо организовать код на PHP. А вот преимущества работы Next.js проекта как единого приложения с общим кодом одновременно на сервере и клиенте на PHP не получить, даже с htmlx.
Или все еще держитесь за PHP?
В самом PHP уже 100500 лет как не принято делать серверный рендеринг страниц. Более того, деление на фронт и бек добавляет гибкости, когда появляется возможность в как можно меньшем числе частей системы использовать такое г.. как JavaScript, и на бэкенде появляется большая свобода выбора между PHP, Go, .NET, Python, да хоть C++.
Кроме того, в проектах чуть сложнее магазинчика "У Васи", имеется тенденция делать несколько разных фронтендов, не только веб, но и нативные мобильные клиенты например. И вот нативным мобильным приложениям этот ваш серверный рендеринг не уперся от слова совсем.
Типичный стек включал серверный язык (PHP, Java или даже Perl)…
У людей как будто память стёрли. Никто не помнит ASP и что сайты писали на том же JavaScript (ну и VBScript ещё) что ли? Ещё Netscape выпускал сервер, где использовался JavaScript, там ещё тег был <SCRIPT RUNAT=SERVER>.
Скоро интересно появятся статьи: Это революционно! Можно писать приложения, которые работают без интернета и не в браузере!
>> А что вы думаете об этой тенденции?
Я лично думаю, что тенденция вообще идет в сторону отказа от JS, как от языка программирования, предназначенного для людей.
Так уж повелось, что код на JS исполняется браузерами. Быстро и хорошо исполняется. Отлично. Эта ситуация останется еще на десятки лет доминирующей.
Но заставлять живых людей писать на JS и даже придумывать целые "фреймворки" (не являющиеся таковыми) для этого?
Нет, это не магистраль. Магистраль - это судьба JS, как языка промежуточного представления кода. Как нового ассемблера.
Посмотрите, к примеру, на Symfony Live Components, библиотеку, позволяющую бэкенд-разработчику создавать сложные и "живые" интерфейсы, не написав ни строчки кода на JS вручную.
Это - и есть следующий магистральный путь. Кода мы берем настоящий язык программирования, с настоящей системой типов, пишем на нем, а уж во что оно там транслируется - стараемся не задумываться.
Между прочим, так примерно и развивается IT последние лет 50. Ничего нового.
Реакт на сервере - это старый добрый PHP.
По моему, вставки html в код - это не react, а jsx.
Чтобы его использовать, как любые другие библиотеки нужно сначала подключить, настроить сборщик. Для использования php подключать/собирать ничего не нужно, работать с php гораздо проще.
Не очень понял ни комикс, ни проблему.
Простите, не очень точно наверное выразился - я всё ещё не понимаю суть комикса (почему все остальные становятся сиреневыми?) и проблемы await.
systemd на самом деле ещё тот монстр, который вмещает в себя какое-то огромное количество функционала вплоть до лёгкой контейнеризации, что противоречит юникс идеалогии: "делай одну вещь и делай её хорошо". По хорошему systemd бы разделить на несколько программ, потому что большинство пользователей используют её только для работы со службами.
Systemd правда хороший пример монстра.
Нуу... Реактивность можно и на реальном DOM делать. От этого она не престанет порождать кучу глюков (с точки зрения конечного пользователя), не перестанет требовать в разы бОльшего времени на ручное тестирование (любое другое всегда было пустой тратой времени) для того, чтобы выявить хотя бы десятую часть тех багов с которыми столкнется end user (нет, это не корнер кейсы... ВНЕЗАПНО!).
Ответственные за сайт Озона годами не могут решить проблему рандомного отображения первой страницы (товаров с первой страницы) на страницах 13-15 и т.п.
Глубокую фильтрацию я еще 3 года назад перестал использовать - это было психоделическое нечто, работающее неизвестно как. Самый распространенный баг того времени - при последовательной отмене фильтров снизу вверх... ВНЕЗАПНО! получаем мЕньшее кол-во результатов, а то и вообще эпичный 0.
Но говно, к тому же мертвое - это jQuery и PHP. Не перепутайте!
P.S.: Возможно фильтрация сейчас уже работает нормально (использую только несколько верхних уровней), но со сломанной пагинацией сталкивался в прошлом году пару раз.
Фреймворки также стирают границу между фронтендом и бэкендом.
И это ужасно, потому что проекты превращаются в одну большую кашу без разделения ответственности. Да и при разделении бэкенда и фронтенда, мы можем менять ЯП. Не нравится PHP на бэке, можно переписать всё на Go, ASP, C++, Python, Node и т.д. Не нравится React на фронте, можно заменить хоть ванильным js.
Теперь один разработчик может реализовать функциональность "от и до": от запросов к базе данных до UI-интеракций.
Если бэкенд и фронтенд пишутся на одном ЯП, это не значит, что у них одинаковая специфика. Только знание ЯП не даёт понимание всех сфер, где он применяется.
Может показаться, что React Server Components с SQL-запросами похожи на старый добрый PHP с его смешением HTML, CSS и SQL.
Я рад, что описанные в статье js фреймворки добрались до уровня php дястелетней давности, но в современном php давно принято использовать OOП, шаблонизаторы, подходы по разделению логики по типу MVC и т.д. Как понимаю в реакте, даже OOП без костылей использовать нельзя поэтому сравнение с PHP очень странное.
Но главное отличие в том, что мы больше не создаем "спагетти-код".
Ещё как создаёте и даже порой более ужасный, чем создавали php программисты 10 лет назад. Когда увидел SQL запросы, вставленные в html теги, что воспринимается, как норма, ужаснулся куда катятся фулстек решения на js.
П.С. У js тоже есть хорошие решения, например нода для бэкенда, анагуляр для сложных и средних проектов на фронте и вуе для простых и думаю можно ещё десяток назвать хороших. Но статья - явный байт на холивар.
На работе пишу backend на php.
Для себя работаю на node js. - влюбился
React на сервере — это не PHP