Comments 12
И на любое действие перезагружать всю страницу целиком с сервера? Даже если там всего несколько элементов изменилось? Или всё же удобнее и быстрее, просто получить с севера небольшой json с нужными данными?
Я пару раз применял в подобной ситуации такой подход: возвращал с сервера сразу html и менял содержимое элемента-контейнера. Но такой способ, конечно, для совсем уж простых случаев, типа отправки формы.
Браузер умеет preload и transition. Ровно то что сделает реакт, только нативно. А там где надо на странице что-то мутировать - справится htmx. И сложность этих решений в разы меньше.
А ещё лучше получить сразу небольшой фрагмент HTML.
Вы забыли про Ajax? Или не знали? (Что будет удивительным, конечно)
HTML - это просто текст
JS — тоже. В реальности в runtime cуществуют не "просто HTML", а DOM-представление содержимого страницы, которое внезапно может иметь кучу состояний, переиспользоваться между разными страницами, а пользователю может не нравится перезагружать всю страницу в ответ на изменение одного из фильтров в поиске или приходе нового сообщения на форуме.
"HTML - это просто текст", офигенно, а Vulcan API — это просто пиксели.
Дальше автор перекладыват проблемы NextJS и Server Components React на весь фронтенд.
Давно уже нет.
Для решения этого вопроса команда React предложила React Server Components, которые позволили снять проблему «как выбирать данные в React?», донимавший команду на протяжении всех 2010-х.
Серверный рендеринг на Реакт был чуть ли не с первой версии, никаких проблем с выборкой данных для него не было со времен изобретения Promise.
Открою вам секрет, большей части веб-приложений серверный рендеринг на хер не упал. Вот вообще. Oн нужен по большей части для индексирования поисковиками, и даже тогда нужен далеко не на всем сайте. Всерьез он остался по-моему только в e-commerce, но там ваш стек разработки часто уже определён за вас Shopify, Magento и кучей других SAAS решений или полуготовых коробочных решений.
А последние версии NextJS и Server Only Components React и правда говно. Если уж так нужен полноценный SSR и SPA, то есть куча конкурентов получше.
"HTML - это просто текст", офигенно, а Vulcan API — это просто пиксели.
Там же смысл в том, что сервер не занимается рендерингом, он выдаёт просто текст, а не отрендеренную страницу.
Давайте так. Что проще: написать сервер на Python, сразу генерирующий HTML, или написать API на Python и клиент на JS? Пишите хоть на ванильном JS, это всё равно будет сложнее первого варианта. И я даже не упомянул настройку CI/CD пайплайнов...
Но это совсем не лишний слой, на сервере постоянно генерировать хтмл это путь назад в 2000, и в плане скорости интернета мы по всей видимости тоже делаем откат, хотя казалось бы...
Вы слышали про ошибку невозвратных инвестиций? Делать шаг назад когда понимаешь что шагеул не туда - вполне разумно. А вот двигаться в направлении катастрофы когда знаешь о ней, безрассудство.
В 2000-х генерировали страницы целиком, а сейчас же можно генерировать только нужные фрагменты. Хотя, это уже давно можно было делать.
Для сервера нет принципиальной разницы что генерировать - html или json. Но для браузера второй вариант более ресурсоёмкий.
Понимаю, что этот пример написан "для демонстрации простоты", но почему не написать вот так ради соответствия стандартам?
LIST = "</li><li>".join(boroughs)
WEBPAGE = "<h1>NYC Boroughs</h1><ul><li>" + LIST + "</li></ul>"
Рендеринг — это не про сервер