AJAX как технология окончательно сформировалась к 2005 году. В 2006 году W3C выпустил первую предварительную спецификацию объекта XMLHttpRequest в попытке создать официальный веб-стандарт. В 2009 году Google выступил с предложением сделать AJAX-страницы доступными для поисковиков. Тогда они не могли интерпретировать JavaScript, поэтому был предложен ряд практик, которые гарантировали, что поисковые системы смогу индексировать AJAX-приложение.
Веб-мастерам приходилось генерировать HTML-версию своего сайта, а со страниц с адресом ?_escaped_fragment=page отдавать срендеренную HTML-версия страницы с отработанным JavaScript'ом. По этому поводу существует подробное руководство от Яндекса и Google.
Однако с октября 2015 года Google отмечает свое руководство как устаревшее, нерекомендуемое (deprecated). Запись в блоге Гугла утверждает, что поисковый паук способен интерпретировать веб-страницы точно так же, как современные браузеры.
Практика
Итак, в наличии одностраничный сайт на AngularJS. Нужно с минимальными телодвижениями обеспечить его индексацию в Google и заодно проверить, действительно ли Google исполняет весь JavaScript-код.
Первым делом включим HTML5 History API Mode для UI-router:
angular.module('app', ['ui.router'])
.config(function($locationProvider) {
$locationProvider.html5Mode(true);
});
Теперь нужно настроить nginx так, чтобы все запросы отправлялись на index.html:
location / {
try_files $uri $uri/ /index.html =404;
}
Собственно, всё. Этого достаточно, чтобы Google начал индексировать сайт. В качестве пруфа могу привести свой личный проект seo11.ru.
Это SPA приложение на Angular 1.5, но все страницы проиндексированы, даже без sitemap.xml.
Контент страниц вставляется через ui-view, но он без проблем доступен Google-пауку:
С помощью $stateProvider для каждой страницы сайта прописаны уникальные title и description:
<title data-ng-bind="title">SEO 1:1</title>
<meta name="description" content="{{description}}">
Работают оба варианта:
Google отрабатывает страницу полностью, ровно так, как это делаешь ваш браузер. Вплоть до того, что текст в этом блоке доступен для поиска:
<p ng-show="isFirefox">Если вы пользуетесь браузером Firefox...</p>
А в этом блоке не доступен:
<p ng-if="isFirefox">Просто нажмите на подсвеченную стрелку...</p>
Разница в том, что ng-show просто добавляет display: hide к элементу, а ng-if вырезает элемент прямо из DOM.
А Яндекс?
Робот Яндекса тоже может индексировать JavaScript, но пока в рамках эксперимента. Об этом подробно написано в блоге. К сожалению, работает это не для всех сайтов и в настоящий момент нельзя быть уверенным, что ваш JS-сайт будет проиндексирован.
Увы, но в данном случае единственное решение, которое можно предложить для корректной индексации сайта, — это использование HTML-копий по схеме, о которой упоминалось ранее.
Однако тратить на это значительные ресурсы не целесообразно, т.к. рано или поздно Яндекс будет полноценно исполнять JS-код для всех сайтов (если раньше не загнется).
На сегодняшний день наиболее простым способом генерации HTML-версии сайта является использование headless-браузера для ренгеринга страниц, например, PhantomJS. Можно делать это на лету или же отдавать кэшированные заранее страницы (есть даже специальные сервисы, например prerender.io).
Лично я использую плагин html-snapshots, который запускается в Gulp'ом на этапе сборки проекта.
Комментарии (69)
MrCheater
01.11.2016 18:36В 2016 уже есть фреймворки, которые могут в нормальный SPA с серверным рендерингом. Например React (http://redux.js.org/docs/recipes/ServerRendering.html) и Angular 2 (https://github.com/angular/universal).
Сама попытка делать пререндеринг сайта через PhantomJS это пережиток прошлого и ошибка природы
evnuh
01.11.2016 19:50+1Не все сервера работают на nodejs, кстати. Как быть тогда, не используя ошибку природы в виде пререндеринга?
MrCheater
01.11.2016 21:07+3Сервер на nodejs целиком писать необязательно. Достаточно написать небольшую прослойку для рендеринга на nodejs. API, работа с БД и прочими штуками может быть реализована на каком угодно языке программирования
napa3um
02.11.2016 08:43+3В современном вебе SPA уже в PWA превращается, а луддиты всё ещё держатся за серверный рендеринг. Пререндеринг с помощью PhantomJS — не пережиток прошлого, а временный инструмент (костыль) для поддержки устаревших методов пауков, которые будут актуальны ещё максимум год. Нет никакого смысла глубоко внедрять серверный рендеринг в архитектуру своего приложения.
PaulMaly
02.11.2016 23:04+2Ну а зачем внедрять глубоко? Front-end сервер на ноде может на 90% совмещать код самого SPA, это называется Изоморфное (универсальное) приложение. Оверхеда по коду почти нет и можно это воспринимать как такое же клиентское окружение, как и браузер. При этом данный концепт вполне можно совместить с PWA. Два сапога — пара. Ну а поддерживать серверный рендеринг имеет смысл далеко не только для краулеров.
napa3um
02.11.2016 23:09Изоморфизм рано или поздно «протечёт». PWA и изоморфизм — это оксюморон (и даже 10% оверхеда этого не стоят). Помнится, мы это с вами уже обсуждали в другой аналогичной дискуссии, с тех пор моё мнение не изменилось. Ваше, полагаю, тоже, потому переубеждать друг друга, наверное, нам особого смысла нет :).
PaulMaly
03.11.2016 16:58+2Спору нет. Однако хотелось бы узнать, откуда у вас такая уверенность в том, что изоморфность «протекает»? Из опыта или чисто логически? Лично у меня опыт таких приложений еще с тех времён, когда и термина еще не было, а нода пару лет как появилась. И ни разу ничего не «текло». Лично мое имхо, такие вещи нужно просто научиться делать, первое время конечно затратнее, но открывает уникальные возможности.
napa3um
04.11.2016 08:37Личный опыт и логический вывод. «Течёт» не приложение, а абстракция, через те 5%, которые остаются от «95% общего кода». Стоимость протечки, на мой взгляд, больше, чем 5%, но я не смирился бы и с 1%. Клиент в большинстве реальных случаев «рисует» гуй SPA/PWA быстрее, чем адекватно нагруженный сервер. Только страницы для однократного захода пользователя (лэндинги) имеет смысл реализовывать серверным рендерингом, но там и не предполагается сложного роутинга и логики, обычно: если пользователь остался на сайте, решив залогиниться, то ему загружается SPA/PWA.
muxa_ru
04.11.2016 12:25> Клиент в большинстве реальных случаев «рисует» гуй SPA/PWA быстрее, чем адекватно нагруженный сервер.
Это сферический клиент в вакууме, у которого в единственной копии браузера запущена единственная страница.
А реальный клиент, у которого в браузере висят десятки вкладок в каждой из который вертится «гуй SPA/PWA» может показать совсем другие результаты.napa3um
04.11.2016 13:01А может и не показать.
sumanai
04.11.2016 14:19Клиент в большинстве реальных случаев «рисует» гуй SPA/PWA быстрее, чем адекватно нагруженный сервер.
Даже мобильный? Мой SGS2 четырёхлетней свежести думаете будет быстрее?
А ведь пользователей с мобильных уже больше, чем с ПК.napa3um
04.11.2016 14:25Даже мобильный, если приложение (SPA/PWA) уже загружено. Если не загружено — то пользователь ещё на лэндинге, а если решил использовать приложение — то без загрузки ему всё равно не обойтись.
sumanai
04.11.2016 14:28А проверяли? А эта самая загрузка не будет ли слишком долгой, что даже самый терпеливый пользователь плюнет на всё и закроет страницу? Вам ведь нужно уложится в 3 сек, дальше большинство пользователей закроет страницу, а на мобильном мобильное же соединение уже кушает на свои задержки секунду-другую.
napa3um
04.11.2016 14:30Ещё раз перечитайте мой комментарий выше. Если нужно за наносекунду удержать внимание нового пользователя, то это лэндинг, не PWA. А если пользователь возвращается на сайт, то всё приложение у него УЖЕ загружено, и оно, естественно, гораздо быстрее догрузит новые данные без загрузки дополнительной разметки гуя и её парсинга, меняя информацию только в прибинденных свойствах.
sumanai
04.11.2016 15:00Лендинги же бесполезны? И где например лендинг у хабра? Тут каждая страница может быть посадочной, из поиска.
А кеш у мобильных весьма ограничен. Я не понимаю тех, кто считает, что их сайт- единственный, который посещается с этого устройства. Да при заходе на любой другой данные вашего приложения вымоются из кеша.
и оно, естественно, гораздо быстрее догрузит новые данные без загрузки дополнительной разметки гуя и её парсинга,
А вот не вижу ничего естественного. Как я уже писал, некоторые SPA у меня работают медленнее, чем аналогичные по содержанию обычные страницы.napa3um
04.11.2016 15:07Вы меня обвиняете в неоптимизированности Хабра или того SPA-приложения, которое у вас тормозит сильнее изоморфного? Воздержусь от комментариев. И от дальнейшей дискуссии — мне кажется, вы уже выразили своё мнение и наверняка поняли моё. Оптимизируйте свои сайты так, как считаете нужным, у изоморфной архитектуры вполне могут быть свои плюсы в каких-то проектах, я не призываю вас обращаться в другую религию.
PaulMaly
05.11.2016 01:32+1Ну судя по вашим доводам, выводы вы делаете все же логического, а не практического плана. Если бы вы действительно писали такие приложения, то поняли бы, что те «5%» не могут течь по определению, потому что как раз они и логически и архитектурно четко разделимы. Вот с «95% общего кода» проблемы случаются, но все они решаемы. А главное решения эти имеют свойство нарабатываться. А постановка вопроса о том, что клиент «рисует гуй» вообще не верная. Только он его и «рисует», даже когда с сервера приходит готовый html. Другое дело фронтенд-сервером вы можете управлять, а +100500 видами клиентов нет. Поэтому дополнительная гибкость в виде изоморфности кода приложения дает больше возможностей по их обслуживанию. Ну и опять же помнится в свое время «адекватно нагруженный» твиттер таки перешел обратно на северный рендеринг. Видимо их клиенты не «рисовали гуй» в реальных случаях быстрее сервера. Опять же я не призываю возвращаться на сервер-сайд, но имея «серверный браузер» в виде ноды грех не пользоваться таким преимуществом.
napa3um
05.11.2016 06:59Они текут по определению как раз, если вам нужно учитывать хоть что-то, связанное с самой изоморфностью (5%, по вашей скромной оценке), а не с бизнес-логикой приложения. «Течь» в терминах Спольски, а не в терминах утечек ресурсов, если вы понимаете. Судя по вашим доводам, вы большой фанат изоморфного кода.
PaulMaly
08.11.2016 23:45+1Перешли в какие-то абстрактные дали «течет-не-течет». Еще раз повторю, что по моему опыту изоморфные приложение «не текут» в любых терминах, конечно если хорошо спроектированы и написаны (если нет, тогда протекать может что угодно и память и ресурсы и чего хочешь). Как и любой код вобщем-то. Но лично мое имхо, как раз у изоморфного подхода вариантов «протечь» значительно меньше, потому что он подходит к приложению консистентно.
napa3um
08.11.2016 23:51Вы не поняли «абстрактные дали», но утверждаете, что не течёт даже в них. Ознакомьтесь с http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html, может, поймёте, о чём он (не ахти какие примеры он приводит, но идею, возможно, уловите). Моё личное имхо, что изоморфный код УЖЕ протёк, до своего написания, самим фактом того, что мне этот изоморфизм при написании придётся держать в уме. Но я это в контексте данной дискуссии, конечно, утрирую, в жизни всё прозаичнее и с изоморфными проектами тоже имею дело (и с не самыми плохими проектами даже по моим идеалистичным меркам «отрицателя изоморфизма»).
Мы уже многократно обменялись информацией о своих вкусах в архитектурных вопросах, и не думаю, что в данной дискуссии мы сможем с вами синтезировать какую-то новую истину.PaulMaly
09.11.2016 00:42Да пожалуй. За ссылку спасибо, правда ничего особо интересного там не прочел. Довольно банальные рассуждения о несовершенстве этого мира. Ну и еще конечно чувак хотел придумать какой-то «закон» и он его придумал. ))))
napa3um
09.11.2016 09:07Да, мне этот тип с его «философией для бедных» тоже не очень. Но его тексты довольно расхожи в ИТ-кругах, потому ссылаться на него иногда бывает проще, чем повторять банальности.
M-A-XG
01.11.2016 20:22-2Не все браузеры поддерживают history API, тем более корректно.
Поэтому должна быть доступна и обычныя страница.
Ну и плевать на Яндекс, пока он приносит большинство трафика — тупорыло.
AndreyRubankov
01.11.2016 21:09+6Из этого топика я понял, что Гугл умеет гугловый AngularJS (прям удивительно!), Яндекс не умеет js, а у вас есть сайт, который вы пиарите без «я пиарюсь».
jbubsk
02.11.2016 00:07+1Не просто пиарится без «я пиарюсь», а ещё судя по тэгу и 25 кадр куда-то запихнул со скрытой рекламой… То-то я сразу захотел поесть и купить пылесос.
muxa_ru
01.11.2016 22:10Но, чёрт возьми, зачем?
taujavarob
01.11.2016 22:26+2>Но, чёрт возьми, зачем?
А как?
DenimTornado
01.11.2016 22:39а без SPA, если для SEO
sumanai
01.11.2016 23:30+2С SPA, но при запросе первой страницы отдавать нормальный HTML. Ботам без JS при этом всегда будут отдаваться нормальный HTML.
Это к тому же ускорит первый заход у пользователя- вместо запуска всего приложения и последующей отрисовки данных браузеру нужно будет лишь отобразить начальный экран из простого HTML, а дополнительный яваскрипт навесить в фоне, и дальше работать как SPA.
taujavarob
02.11.2016 16:28+1sumanai >С SPA, но при запросе первой страницы отдавать нормальный HTML. Ботам без JS при этом всегда будут отдаваться нормальный HTML.
Кто будет рендерить этот «нормальный HTML» на сервере? Кто и как?
Пример: у меня 1 000 000 анкет, которые я должен «скормить пауку».
Это может быть современная SPA страница, которую я отдаю пользователю по запросу его броузера. — В этом случае я рендерю её прямо в броузере (используя JS).
Кто, где и как мне отрендерит её для «пауков» (Для Гугла, Яндекса, Бинга и прочих)?
И таких «нормальных HTML» у меня 1 000 000. Миллион!!!muxa_ru
02.11.2016 16:41А кто прямо сейчас генерит html в примере из исходного постинга?
Вот страница — /about
Вот сгенерённый под неё html — /views/about.html
Чудес не бывает, на сервере всё равно кто-то сидит и что-то генерит.taujavarob
02.11.2016 17:29+1muxa_ru >Чудес не бывает, на сервере всё равно кто-то сидит и что-то генерит.
Одно дело генерить: /views/anketa.html?id=123456 на сервере.
Другое дело отдать «пустую страницу» на клиент /views/anketa.html?id=123456
где JS, используя Ajax, стянет всё в формате JSON с сервера для id=123456 и отрендерит страницу.
Такие вот SPA в 2016 году.
muxa_ru >Чудес не бывает, на сервере всё равно кто-то сидит и что-то генерит.
В настоящем SPA на сервере никто не генерит страницы. Отдают «почти пустую» на клиент и на клиенте JS всё и «рисует» — всё рисует, в том числе и about.html
В настоящем то SPA!
Имхо, конечно, имхо.
muxa_ru
02.11.2016 17:43> в формате JSON
А формат JSON кто сгенерирует?taujavarob
02.11.2016 19:41+2muxa_ru >А формат JSON кто сгенерирует?
Хороший вопрос! ;-)
Но дело в том, что тот кто JSON генерирует не отдаёт его «пауку». Ибо это «сырец», а «пауку» нужна реальная страница с данными, а не «сырой JSON».
sumanai > Нет никаких проблем в генерации HTML на сервере на лету, двадцать лет так делали, и горя не знали.
Тогда не было SPA — страницы перегружались — это ужасно!
Сейчас есть SPA — это просто прелестно!
Но возникла проблема — НЕ дублировать код — типа один для броузера (на клиенте), другой для «паука» (на сервере).
НЕ дублировать код.
В настоящее время эта проблема НЕ решена. — Какие-то подвижки в решении наметились, но до окончательной победы ещё похоже годы и годы.
А костылей да, много предлагают всяких. Костылей то.
Имхо, конечно, имхо. (С)sumanai
02.11.2016 19:48+2Тогда не было SPA — страницы перегружались — это ужасно!
Тогда был аякс, и при желании много что можно было делать без перезагрузки. Да и сейчас можно. Вот я сейчас отправил этот комментарий, а потом отредактировал, добавив эту запись. И всё без SPA и без перезагрузки страницы.
И не вижу ничего ужасного в перезагрузке страницы. У меня порой эти новомодные SPA работают медленнее, чем загрузка аналогичной по наполнению страницы с нуля.
SPA обязателен там, где есть например прослушивание музыки- вот тут перезагрузка смерти подобна. А в остальных случаях SPA делают потому, что это модно, стильно, молодёжно.
НЕ дублировать код.
Не дублируйте.
Шаблоны должны быть отдельно, и они должны использоваться что браузером, что сервером.
А то, что код их различен- да ничего страшного, этот слой не должен меняться часто. Меняться должны шаблоны, а они должны быть общими.
muxa_ru
02.11.2016 19:56> Тогда не было SPA — страницы перегружались — это ужасно!
Я по несколько раз на дню жму обновление страницы в ютуб-аналитике.
Ну слетает у него цветовая схема для графиков по время всего этого JSON-дёрганья. А после обовления страницы все привычные цвета на месте.
faiwer
02.11.2016 20:11+2Тогда не было SPA — страницы перегружались — это ужасно!
Сейчас есть SPA — это просто прелестно!По правде говоря, сделать SPA с теми же плюшками, что и у классического сайта ? не тривиально. И часто на это не заморачиваются. Видимо ввиду того, что ряд вещей не используют сами, и не думают, что они могут использоваться кем-то другим.
Пример. Ссылки. Обычный сайт позволяет перейти сразу на нужную страницу по её ссылке. Скопировать же ссылку на страницу можно через контекстное меню, даже не переходя по ней. Никто не мешает в SPA делать так же. Однако очень часто не делают. Что сильно раздражает.
Или скажем якоря. Можно дать ссылку сразу на нужный раздел большой страницы. В той же вики регулярное явление. Такое уже сложнее сделать работающим асинхронно. Но можно. Чаще всего никто не заморачивается. А зря.
Ещё отмечу, что для больших SPA обязательно нужно грамотно продумывать бандлы и вообще загрузку всех зависимостей по необходимости. Чаще всего на это забивают. Недавний пример ? тинкьковский сайт, тот самый epic fail на 3+ MiB. Хотя они вроде сказали, что они заморочились. Но 3 MiB скриптов для главной страницы, WAT? Сейчас это уже чуть ли не норма. 3 MiB одних только скриптов. Сразу. После загрузки! Да, можно так не делать. Но люди идут по пути наименьшего сопротивления. И получаются все эти огромные перегруженные монстры.
Полагаю, что если крепко повспоминать, то таких вот нюансов можно с десятка полтора вспомнить. И всё будет сводиться к тому, что обойти проблему можно, но не всегда легко, и в итоге многие проблемы игнорируются. В то время как в классическом случае, ты или вынужден их решать (хочешь-не-хочешь), или они решаются архитектурно (само по себе).
Сделать сайт по классической схеме чаще всего просто проще и быстрее. Да и готовых решений без монад, редьюсеров, webpack-а, redux-а, immutable, transpile и пр. выше крыши.
taujavarob
02.11.2016 20:42-1sumanai > И не вижу ничего ужасного в перезагрузке страницы.
Привычка. Наверно. Но это ужасно.
muxa_ru > Я по несколько раз на дню жму обновление страницы в ютуб-аналитике.
Хм. Печально.
faiwer > Сделать сайт по классической схеме чаще всего просто проще и быстрее.
Мало того, сайтов по классической схеме большинство в инете! Большинство.
А вот настоящих SPA сайтов мало. Просто мало. Очень мало. Печально.
Имхо, конечно, имхо. (С)
PaulMaly
02.11.2016 23:15-1Да вполне все решается. Даже название уже пару лет как придумали чуваки из AirBnB: изоморфные js приложения. Не тривиально конечно, хотя когда появились SPA, специалисты работавшие до этого по схеме с толстым сервером и тонким клиентом, тоже по началу офигевали. Да и сейчас не все архитектурные вопросы SPA решены.
taujavarob
03.11.2016 16:29PaulMaly >Не тривиально конечно, хотя когда появились SPA, специалисты работавшие до этого по схеме с толстым сервером и тонким клиентом, тоже по началу офигевали. Да и сейчас не все архитектурные вопросы SPA решены.
Да, слово «изоморфные» появилось. Верно. Но проблемы не решены вовсе. Мало того — там ещё «конь фактически и не повалился».
Кстати, а как Google «раскручивает сайт» со SPA? -, например, в случае с React его пауку на вход подаётся «белый лист» с одним бандлом к этому листу. И всё. — Крутись как хошь то!
Как дать понять пауку что индексировать а что нет? — Текст то при запуске JS возникает (может возникать) то.
И вот, в 2016 году — всё как по старинке — пауку даём отрендереную на сервере страницу, а броузеру вариант в виде SPA. — Со всеми вытекающими отсюда проблемами.
PaulMaly
03.11.2016 17:05+2Не знаю как вы в 2016 году, а мы в том же году пишем изоморфные веб приложения поверх микросервисов. Отдаем на все синхронные запросы к фронтенд-серверу полностью готовое для браузера приложение (html + клиентский код), которое в браузере с поддержкой js продолжает работать как SPA, вплоть до следующего синхронного запросы (например юзер перезагрузил страницу сам). Причем некоторые фичи SPA работают в зависимости от поддержки браузером и фолбеком на сервер, если это возможно конечно. При всем при этом общего кода между клиентским и серверным фронтендом в районе 90-95%. Проблемы есть, но они чисто специфические и это того стоит.
taujavarob
03.11.2016 17:48PaulMaly > Не знаю как вы в 2016 году, а мы в том же году пишем изоморфные веб приложения поверх микросервисов.
Не, мы как все — нам надо чтобы Гугл (и прочие) часть наших страниц индексировал, а станицы где у нас редактор (частично там и SPA) то и не трогал.
Код так и разбит. — И вот это неверно, наверное. Но, работает. ;-)PaulMaly
03.11.2016 18:29Ну так нет никакой проблемы запретить Гуглу индексировать часть урлов. Изоморфные приложения с этим прекрасно справляются)))
taujavarob
03.11.2016 18:48PaulMaly > Ну так нет никакой проблемы запретить Гуглу индексировать часть урлов.
Часть да. Можно. Мы так и сделали. Дали ему часть урлов для индексации. Которые рендерим на сервере.
Если же мы захотим рендерить всё на клиенте — Гугл (и остальные) — обломятся.
Об этом и речь то!
PaulMaly
03.11.2016 20:56+1Ну моя то речь не об этом, а о том, что серверный рендеринг может исполняться тем же кодом, что и клиентский и вообще на ~95% фронтенд-сервер может содержать и исполнять общий код веб-приложения. В этом случае описанные проблемы отпадают сами собой.
То есть, если имеем навороченный клиент (современный браузер, включенный js и тп), отдаем ему страницу по текущему урл и код клиентского приложения, и дальше все работает как в обычном SPA. Если имеем примитивный клиент (без js, краулер и тп) тогда этот клиент делает исключительно синхронные запросы к серверу на которые сервер всегда отвечает готовой отрендеренной страницей. Все.
Дальше хотим блокируем определенные урлы, хотим не блокируем.taujavarob
03.11.2016 21:47PaulMaly > Если имеем примитивный клиент (без js, краулер и тп) тогда этот клиент делает исключительно синхронные запросы к серверу на которые сервер всегда отвечает готовой отрендеренной страницей.
Я слыхал, что появились такие технологии — но вот насколько они уже зрелые?PaulMaly
05.11.2016 01:44+2NodeJS существует по меньшей мере 7 лет. На нем полностью реализованы тысячи проектов. Иными словами вы уже 7 лет можете рендерить html в браузере и на сервере с помощью одного и того же кода на js. Вот и все технологии. Да конечно, с появлением таких штук как React с его серверным рендерингом все стало проще, плюс термин придумали и уважаемые библиотеки стали поддерживать не только браузер, но и ноду, и наоборот. Более того, при изоморфном подходе вам даже бекенд на ноду переписывать не надо, если он у вас к примеру на PHP/Python/Ruby/etc. Пусть остаются.
taujavarob
08.11.2016 20:37PaulMaly > NodeJS существует по меньшей мере 7 лет.
Верно. Но изоморфность это совсем модная штука.
PaulMaly > Более того, при изоморфном подходе вам даже бекенд на ноду переписывать не надо, если он у вас к примеру на PHP/Python/Ruby/etc.
И всё же я подумал — а кому нужна эта изоморфность?
«Обычный» рендер страницы на сервере — на порядок (в 10 раз) быстрее изоморфного рендера страницы на сервере. — Так что пауку и юзеру быстрее отдать уже «обычным образом» отрендеренную страницу.
А вот редактирование (формы) или страницы типа «админки» и прочего такого же вида — то есть страницы, которые пауку от Гугла (и прочим паукам) не надо вовсе индексировать — те вполне могут быть отрендерены на клиенте.
Ниша изоморфного рендера страницы на сервере (с запуском на сервере типа «броузера» в котором запускается JS) очень мала (до призрачности), по крайней мере по состоянию на конец 2016 года.
Имхо, конечно, имхо.PaulMaly
08.11.2016 23:37> Верно. Но изоморфность это совсем модная штука.
Да нет, это термин новая и модная штука. Сама идея довольно очевидная — если есть единая среда исполнения на клиенте и сервере почему этим не пользоваться?
> «Обычный» рендер страницы на сервере — на порядок (в 10 раз) быстрее изоморфного рендера страницы на сервере. — Так что пауку и юзеру быстрее отдать уже «обычным образом» отрендеренную страницу.
Я вас умоляю, откуда такие глупые предрассудки? Чем рендер на стороне сервера с помощью того же PHP отличается от рендера NodeJS. Более того, гарантирую нода отработает запрос быстрее в большинстве случаев. Да и вообще не понятно, что значит «обычным образом».
> А вот редактирование (формы) или страницы типа «админки» и прочего такого же вида — то есть страницы, которые пауку от Гугла (и прочим паукам) не надо вовсе индексировать — те вполне могут быть отрендерены на клиенте.
Не во всех проектах есть такие страницы, а значит по вашей логике для них нужен исключительно серверный рендер, но это не так. Нет никакой причины не переносить часть задач на клиента, который эти задачи может взять на себя и исполнить. Это и есть изоморфность в данном контексте — сервер может делать всю работу, но эту же работу может делать и клиент, если может.
> Ниша изоморфного рендера страницы на сервере (с запуском на сервере типа «броузера» в котором запускается JS) очень мала (до призрачности), по крайней мере по состоянию на конец 2016 года.
Что это еще за «ниша» такая? Вы не понимаете, что абсолютно любой проект можно сделать таким способом? От навороченного веб-апп и заканчивая тупым новостным порталом. При этом мы получаем seo-friendly, user-friendly и даже mobile-app-friendly прямо из коробки.
taujavarob
09.11.2016 20:34PaulMaly > Сама идея довольно очевидная — если есть единая среда исполнения на клиенте и сервере почему этим не пользоваться?
Она появилась совсем недавно. Едина среда.
PaulMaly > Я вас умоляю, откуда такие глупые предрассудки?
Да все об этом пишут.
PaulMaly > Чем рендер на стороне сервера с помощью того же PHP отличается от рендера NodeJS. Более того, гарантирую нода отработает запрос быстрее в большинстве случаев. Да и вообще не понятно, что значит «обычным образом».
Не скажу за PHP — у меня Java на сервере.
«Обычным образом» — это написать просто java-класс, на сервере исполняемый. — В данном случае сервлет, то есть это java-класс получаемый из исходной JSP страницы, которая пишется на особом языке фактически. Пишется и компилируется налету в бинарный исполняемый на сервере java-класс (типа по аналогии как JSX в JS-код).
Конечно это всё несомненно работает в 10 раз быстрее чем запуск на сервере треда с JS-движком в котором напускается JS-код для рендера на сервере страницы.
PaulMaly > Не во всех проектах есть такие страницы, а значит по вашей логике для них нужен исключительно серверный рендер, но это не так.
Это так. Смотрите пример — этот хабр.
На сервере происходит рендер страницы — текста статьи и коментов к ней. Далее всё выгружается на клиент — где происходит рендер уже на клиенте ТОЛЬКО при добавлении комента. — Это классика реализации.
PaulMaly > Что это еще за «ниша» такая? Вы не понимаете, что абсолютно любой проект можно сделать таким способом? От навороченного веб-апп и заканчивая тупым новостным порталом. При этом мы получаем seo-friendly, user-friendly и даже mobile-app-friendly прямо из коробки.
Нельзя. Если seo-friendly — то только «обычным рендером» на сервере — так быстрее в разы, чем изоморфный рендер.
Да — сервер надёжно и быстро всё отрендерит, чем неизвестный клиент.
Да и без запуска JS в «броузере» на сервере все пауки корректно индексируют страницу.
Твиттер, бают, попытался всё рендерить на клиенте — отказались — на сервере быстрее и надёжнее.
Я не вижу пока никакой причины использовать изоморфный рендер. Только из-за любознательности. Пока не для продакшен. Имхо.PaulMaly
10.11.2016 00:47> Она появилась совсем недавно. Едина среда.
Единая стеда — это NodeJS и он появился минимум 7 лет назад. Не так уж и недавно, особенно учитывая какой кусок продакшен проектов он уже успел откусить.
> Да все об этом пишут.
Это не ответ. Учитывая что изоморфный рендер мало отличается от обычного серверного рендера, у меня есть сомнения на этот счет.
> «Обычным образом» — это написать просто java-класс, на сервере исполняемый. — В данном случае сервлет, то есть это java-класс получаемый из исходной JSP страницы, которая пишется на особом языке фактически. Пишется и компилируется налету в бинарный исполняемый на сервере java-класс (типа по аналогии как JSX в JS-код).
О, ну вы либо динозавр либо из энтерпрайза.))) Вообще Java is good, но разработка «обычным образом» на Java сильно сложнее, дольше и дороже, даже чем изоморфным на JS, хотя многие критикуют изоморфность как раз в этом ключе, мол зачем запариваться и тратить время/деньги. По дороговизне с Java'ой наверное никто не сможет конкурировать, разве что писать сервер на C/C++))))
> Это классика реализации.
Конечно классика, толстый сервер, тонкий клиент. Но это совсем не интерактивно и не подходит современным веб-приложениям. Однако если Хабр переписать изоморфным способом, хуже он не станет, только лучше.
> Нельзя. Если seo-friendly — то только «обычным рендером» на сервере — так быстрее в разы, чем изоморфный рендер.
Что значит нельзя? Похоже вы не догоняете, что изоморфный рендер ничем не отличается от чисто серверного. Выключите JS на клиенте и у вас чисто серверный рендер. И никаких «быстрее в разы» тут нет. Зато есть отсутствие дублирования кода на сервере и на клиенте и еще много полезных вещей из коробки.
> Твиттер, бают, попытался всё рендерить на клиенте — отказались — на сервере быстрее и надёжнее.
Ну так это как раз мой пример из одного из тредов выше, где комментаторы говорили, что рендерить надо исключительно на клиенте. Я же говорю, что рендерить надо уметь и там и там, но делать это с умом. Если синхронный запрос, то по-любому рендер на сервере, когда код попал на клиент, мы можем решить стоит ли доверять ему рендер, способен ли он на это, или же продолжать все делать через сервер. Ничто не мешает сделать приложение настолько умным, чтобы оно могло решать в каждый конкретный момент имеет ли смысл продолжать рендерить на клиенте (например последняя страница рендерилась медленно из-за нехватки памяти) или же отдать рендер на сервер, хотя бы на время. Вы просто не представляете какие удивительные возможности дает изоморфный подход. Классической реализации это даже не снилось.
> Я не вижу пока никакой причины использовать изоморфный рендер. Только из-за любознательности. Пока не для продакшен.
Еще раз, по сути своей изоморфный рендер ниче не отличается от чисто серверного. Отличается лишь подход к написанию кода и разделению зон ответственности между чисто клиентом и чисто серверными вещами.
taujavarob
10.11.2016 15:32>по сути своей изоморфный рендер ниче не отличается от чисто серверного. Отличается лишь подход к написанию кода и разделению зон ответственности между чисто клиентом и чисто серверными вещами.
ок. ;-)
sumanai
02.11.2016 19:02+2Кто будет рендерить этот «нормальный HTML» на сервере? Кто и как?
Да хоть TWIG на PHP. Ладно, шутка. Генерировать должна тот же слой View, что и отдаёт JSON, только с другим драйвером, отдающим HTML.
Нет никаких проблем в генерации HTML на сервере на лету, двадцать лет так делали, и горя не знали. Потом улучшили аяксом, и всё стало вообще прекрасно.
Но кто-то решил сэкономить и выкинуть серверный рендеринг, и огребли проблем с ПС, с медленным стартом, с пользователями без JS. У них мельчайшая ошибка в JS может остановить работу всей страницы, и пользователь будет лицезреть белый экран.
zapolnoch
02.11.2016 22:04Если вы читали текст, то с ПС как раз никаких проблем нет. Google уже год нормально все индексирует, Яндекс со дня на день подтянется. А до тех пор есть PhantomJS.
sumanai
03.11.2016 05:17Google уже год нормально все индексирует
Когда я писал «огребли проблем с ПС», я имел в виду самые первые SPA. Да и сейчас вы признаёте, что Яндекс пока не работает. Кроме яндекса и гугла есть и другие поисковые системы. Я вот не знаю, как на это всё будет реагировать тот же веб-архив.
Ну и остальные проблемы никуда не деваются.
asave
08.11.2016 10:17+2Очень странное предложение забить на Яндекс до времен, когда он поумнеет. Вдвойне странно, что все это идет от сеошников.
muxa_ru
08.11.2016 13:53Вдвойне странно, что все это идет от сеошников.
Вот это вообще не странно. Если убедить конкурентов набить на Яндекса, то попастьв топ станет проще. :)asave
08.11.2016 14:13Убедить конкурента сделать невесть зачем SPA-версию, да так чтобы он при этом поверил что от потери яндекс-трафика он только выиграет? Если человек настолько талантлив в промывке мозгов, зачем ему SEO?
markmariner
11.11.2016 14:39А как вы описываете стейты в $stateProvider, чтобы менять title динамически?
E_STRICT
Опыт перехода сайта на Single Page Application с упором на SEO