Comments 22
Из популярных фреймворков для SPA хочется отдельно выделить ReactJS.
Почему вы шаблонизатор называете фреймворком?
может хватит уже? Чаще всего под ReactJS предполагают связку react+react-router+redux, чем не фреймворк?
А вот тут ты сам упомянул ReactJS как фреймворк:
и ниже reactjs
https://habrahabr.ru/post/311172/
Сколько нужно времени, чтобы просто вывести на экран большой список, используя современные фреймворки?
и ниже reactjs
https://habrahabr.ru/post/311172/
Изоморфный рендеринг
Чем это плохо
не работает на проектах сложнее «hello world»
Это не правда, работает и на приложениях сложнее Hello world
… работы с динамически загружаемым контентом, управлением очередями запросов, websocket подписками на обновления данных;
Если эти вещи мешают рендерить где бы то ни было, значит у вас проблема с архитектурой приложения, потому что все эти вещи прямого отношения к рендерингу как таковому не имеют. Рендерится HTML код, с пустым состоянием что на фронте что на бэке. А потом это состояние заполняется из хранилища (store). И потом уже это все отдается клиенту. То как вы заполните хранилище, это уже другой вопрос. На бэке вы как правило генерится заполненый store и через props передается полное состояние всего приложения, потом это все отдается на фронт. Да и вообще весь этот изоморфный рендеринг по сути ни чем не отличается от классической схемы применяемой в web разработке хз с каких времен. Поменялись только языки, библиотеки и некоторые принципы проектирования. Но все это базируется на технологиях существующих десятилетиями, поэтому концептуально с точки зрения рендеринга PHP + Smarty так или иначе равно Node.js + ReactJS. Просто и в первом и во втором случае возникают немного разные проблемы. Но это ни как не влияет на все те технологии поверх которых все это работает.
В Renderjs.io в минусы первым пунктом жирным шрифтом нужно записать:
Cloud based сервис...
Трудности с изоморфным рендерингом у нас возникали начиная от отсутствия совместимой с браузером версии XMLHttpRequest в nodejs, необходимостью адаптироваться к jsdom (там много чего нет), необходимостью
эмулировать то, что есть в браузере, например определение гео позиции и т.д.
У нас такая схема, вьюшки, которые попадают во viewport браузера клиента рендерят заглушки и подписываются на данные, когда поступают данные — реакт заменяет заглушки данными. Пробовали изоморфно — просто не получилось. Возможно, вы более удачливы.
В любом случае, спасибо за комментарий.
Cloud based — возможно, как минус. Однако для маленьких проектов, прототипов, бережливых стартапов и т.д. это скорее плюс. Я бы не хотел делать то, что уже сделано. Но это мое мнение.
В любом случае, спасибо за комментарий.
эмулировать то, что есть в браузере, например определение гео позиции и т.д.
У нас такая схема, вьюшки, которые попадают во viewport браузера клиента рендерят заглушки и подписываются на данные, когда поступают данные — реакт заменяет заглушки данными. Пробовали изоморфно — просто не получилось. Возможно, вы более удачливы.
В любом случае, спасибо за комментарий.
Cloud based — возможно, как минус. Однако для маленьких проектов, прототипов, бережливых стартапов и т.д. это скорее плюс. Я бы не хотел делать то, что уже сделано. Но это мое мнение.
В любом случае, спасибо за комментарий.
XMLHttpRequest же есть в jsdom вроде.
Трудности с изоморфным рендерингом у нас возникали начиная от отсутствия совместимой с браузером версии XMLHttpRequest в nodejs
axios, superagent, isomorphic-fetch, etc.
необходимостью
эмулировать то, что есть в браузере, например определение гео позиции и т.д.
На самом деле такая необходимость может и не появиться. Все это сильно зависит от специфики приложения. Однако, если это действительно необходимо, ничто не может помешать вам найти готовую или написать свою абстракцию над «environment-specific api», которая изоморфно инкапсулирует в себя все отличия и выдаст идиный интерфейс. В качестве примера тот же Axios. Реально много чего есть готового на эту тему.
> В 2015 году Google официально отказался от поддержки выполнения javascript кода на своей стороне (https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.html).
Гугл отказался от старой схемы, требующей от вебмастеров организации специальных урлов (_escaped_fragment_) для динамического (AJAX) контента. Теперь вебмастерам не нужно специальным образом шаманить, чтобы их SPA/PWA был видимым для пауков — пауки умеют в клиентский JS и сами. И это написано по приведённой вами же ссылке.
Гугл отказался от старой схемы, требующей от вебмастеров организации специальных урлов (_escaped_fragment_) для динамического (AJAX) контента. Теперь вебмастерам не нужно специальным образом шаманить, чтобы их SPA/PWA был видимым для пауков — пауки умеют в клиентский JS и сами. И это написано по приведённой вами же ссылке.
По ссылке из поста написано, что Гугл замечательно индексирует SPA самостоятельно, никакие дополнительные сервисы не нужны для этого. yury_egorenkov что вы на это скажите?
Кроме Гугла есть и другие не столь продвинутые поисковики.
Видимо, не пробовали.
ВТБ 24(не имею никакого отношения ни прямого ни косвенно) как раз такой пример client-only сайта. Яндекс, Гугл, бинг, мейл — все индексируются.
view-source:https://www.vtb24.ru/?_escaped_fragment_=%2F
Замечание касалось исключительно поисковика от Гугла.
Они там хотят, что бы route был сделан через #!.. Если вы сделаете обычный — выполняться-индексироваться не будет. Мы делали большой магазин на SPA, мучались сначала с гуглом, потом с prerender.io — не получилось работать нормально. Возможно, кто-то более удачливый. Кроме того, соц. сети (fb, vk, twitter) и т.д. не выполняют js, что тоже весьма грустно. Хотелось бы, что бы все работало из коробки и никаких дополнительных приспособлений не требовалось.
Sign up to leave a comment.
За 5 минут сделать Single Page Application доступным для Google и Facebook