Comments 69
В 2016 уже есть фреймворки, которые могут в нормальный SPA с серверным рендерингом. Например React (http://redux.js.org/docs/recipes/ServerRendering.html) и Angular 2 (https://github.com/angular/universal).
Сама попытка делать пререндеринг сайта через PhantomJS это пережиток прошлого и ошибка природы
Не все сервера работают на nodejs, кстати. Как быть тогда, не используя ошибку природы в виде пререндеринга?
В современном вебе SPA уже в PWA превращается, а луддиты всё ещё держатся за серверный рендеринг. Пререндеринг с помощью PhantomJS — не пережиток прошлого, а временный инструмент (костыль) для поддержки устаревших методов пауков, которые будут актуальны ещё максимум год. Нет никакого смысла глубоко внедрять серверный рендеринг в архитектуру своего приложения.
Ну а зачем внедрять глубоко? Front-end сервер на ноде может на 90% совмещать код самого SPA, это называется Изоморфное (универсальное) приложение. Оверхеда по коду почти нет и можно это воспринимать как такое же клиентское окружение, как и браузер. При этом данный концепт вполне можно совместить с PWA. Два сапога — пара. Ну а поддерживать серверный рендеринг имеет смысл далеко не только для краулеров.
Изоморфизм рано или поздно «протечёт». PWA и изоморфизм — это оксюморон (и даже 10% оверхеда этого не стоят). Помнится, мы это с вами уже обсуждали в другой аналогичной дискуссии, с тех пор моё мнение не изменилось. Ваше, полагаю, тоже, потому переубеждать друг друга, наверное, нам особого смысла нет :).
Спору нет. Однако хотелось бы узнать, откуда у вас такая уверенность в том, что изоморфность «протекает»? Из опыта или чисто логически? Лично у меня опыт таких приложений еще с тех времён, когда и термина еще не было, а нода пару лет как появилась. И ни разу ничего не «текло». Лично мое имхо, такие вещи нужно просто научиться делать, первое время конечно затратнее, но открывает уникальные возможности.
Личный опыт и логический вывод. «Течёт» не приложение, а абстракция, через те 5%, которые остаются от «95% общего кода». Стоимость протечки, на мой взгляд, больше, чем 5%, но я не смирился бы и с 1%. Клиент в большинстве реальных случаев «рисует» гуй SPA/PWA быстрее, чем адекватно нагруженный сервер. Только страницы для однократного захода пользователя (лэндинги) имеет смысл реализовывать серверным рендерингом, но там и не предполагается сложного роутинга и логики, обычно: если пользователь остался на сайте, решив залогиниться, то ему загружается SPA/PWA.
> Клиент в большинстве реальных случаев «рисует» гуй SPA/PWA быстрее, чем адекватно нагруженный сервер.
Это сферический клиент в вакууме, у которого в единственной копии браузера запущена единственная страница.
А реальный клиент, у которого в браузере висят десятки вкладок в каждой из который вертится «гуй SPA/PWA» может показать совсем другие результаты.
Это сферический клиент в вакууме, у которого в единственной копии браузера запущена единственная страница.
А реальный клиент, у которого в браузере висят десятки вкладок в каждой из который вертится «гуй SPA/PWA» может показать совсем другие результаты.
А может и не показать.
Может, но зачем рисковать?
Мне кажется, что вы, используя изоморфный подход, рискуете больше.
UFO just landed and posted this here
Даже мобильный, если приложение (SPA/PWA) уже загружено. Если не загружено — то пользователь ещё на лэндинге, а если решил использовать приложение — то без загрузки ему всё равно не обойтись.
UFO just landed and posted this here
Ещё раз перечитайте мой комментарий выше. Если нужно за наносекунду удержать внимание нового пользователя, то это лэндинг, не PWA. А если пользователь возвращается на сайт, то всё приложение у него УЖЕ загружено, и оно, естественно, гораздо быстрее догрузит новые данные без загрузки дополнительной разметки гуя и её парсинга, меняя информацию только в прибинденных свойствах.
UFO just landed and posted this here
Вы меня обвиняете в неоптимизированности Хабра или того SPA-приложения, которое у вас тормозит сильнее изоморфного? Воздержусь от комментариев. И от дальнейшей дискуссии — мне кажется, вы уже выразили своё мнение и наверняка поняли моё. Оптимизируйте свои сайты так, как считаете нужным, у изоморфной архитектуры вполне могут быть свои плюсы в каких-то проектах, я не призываю вас обращаться в другую религию.
Ну судя по вашим доводам, выводы вы делаете все же логического, а не практического плана. Если бы вы действительно писали такие приложения, то поняли бы, что те «5%» не могут течь по определению, потому что как раз они и логически и архитектурно четко разделимы. Вот с «95% общего кода» проблемы случаются, но все они решаемы. А главное решения эти имеют свойство нарабатываться. А постановка вопроса о том, что клиент «рисует гуй» вообще не верная. Только он его и «рисует», даже когда с сервера приходит готовый html. Другое дело фронтенд-сервером вы можете управлять, а +100500 видами клиентов нет. Поэтому дополнительная гибкость в виде изоморфности кода приложения дает больше возможностей по их обслуживанию. Ну и опять же помнится в свое время «адекватно нагруженный» твиттер таки перешел обратно на северный рендеринг. Видимо их клиенты не «рисовали гуй» в реальных случаях быстрее сервера. Опять же я не призываю возвращаться на сервер-сайд, но имея «серверный браузер» в виде ноды грех не пользоваться таким преимуществом.
Они текут по определению как раз, если вам нужно учитывать хоть что-то, связанное с самой изоморфностью (5%, по вашей скромной оценке), а не с бизнес-логикой приложения. «Течь» в терминах Спольски, а не в терминах утечек ресурсов, если вы понимаете. Судя по вашим доводам, вы большой фанат изоморфного кода.
Перешли в какие-то абстрактные дали «течет-не-течет». Еще раз повторю, что по моему опыту изоморфные приложение «не текут» в любых терминах, конечно если хорошо спроектированы и написаны (если нет, тогда протекать может что угодно и память и ресурсы и чего хочешь). Как и любой код вобщем-то. Но лично мое имхо, как раз у изоморфного подхода вариантов «протечь» значительно меньше, потому что он подходит к приложению консистентно.
Вы не поняли «абстрактные дали», но утверждаете, что не течёт даже в них. Ознакомьтесь с http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html, может, поймёте, о чём он (не ахти какие примеры он приводит, но идею, возможно, уловите). Моё личное имхо, что изоморфный код УЖЕ протёк, до своего написания, самим фактом того, что мне этот изоморфизм при написании придётся держать в уме. Но я это в контексте данной дискуссии, конечно, утрирую, в жизни всё прозаичнее и с изоморфными проектами тоже имею дело (и с не самыми плохими проектами даже по моим идеалистичным меркам «отрицателя изоморфизма»).
Мы уже многократно обменялись информацией о своих вкусах в архитектурных вопросах, и не думаю, что в данной дискуссии мы сможем с вами синтезировать какую-то новую истину.
Мы уже многократно обменялись информацией о своих вкусах в архитектурных вопросах, и не думаю, что в данной дискуссии мы сможем с вами синтезировать какую-то новую истину.
Не все браузеры поддерживают history API, тем более корректно.
Поэтому должна быть доступна и обычныя страница.
Ну и плевать на Яндекс, пока он приносит большинство трафика — тупорыло.
Поэтому должна быть доступна и обычныя страница.
Ну и плевать на Яндекс, пока он приносит большинство трафика — тупорыло.
Из этого топика я понял, что Гугл умеет гугловый AngularJS (прям удивительно!), Яндекс не умеет js, а у вас есть сайт, который вы пиарите без «я пиарюсь».
Но, чёрт возьми, зачем?
sumanai >С SPA, но при запросе первой страницы отдавать нормальный HTML. Ботам без JS при этом всегда будут отдаваться нормальный HTML.
Кто будет рендерить этот «нормальный HTML» на сервере? Кто и как?
Пример: у меня 1 000 000 анкет, которые я должен «скормить пауку».
Это может быть современная SPA страница, которую я отдаю пользователю по запросу его броузера. — В этом случае я рендерю её прямо в броузере (используя JS).
Кто, где и как мне отрендерит её для «пауков» (Для Гугла, Яндекса, Бинга и прочих)?
И таких «нормальных HTML» у меня 1 000 000. Миллион!!!
Кто будет рендерить этот «нормальный HTML» на сервере? Кто и как?
Пример: у меня 1 000 000 анкет, которые я должен «скормить пауку».
Это может быть современная SPA страница, которую я отдаю пользователю по запросу его броузера. — В этом случае я рендерю её прямо в броузере (используя JS).
Кто, где и как мне отрендерит её для «пауков» (Для Гугла, Яндекса, Бинга и прочих)?
И таких «нормальных HTML» у меня 1 000 000. Миллион!!!
А кто прямо сейчас генерит html в примере из исходного постинга?
Вот страница — /about
Вот сгенерённый под неё html — /views/about.html
Чудес не бывает, на сервере всё равно кто-то сидит и что-то генерит.
Вот страница — /about
Вот сгенерённый под неё html — /views/about.html
Чудес не бывает, на сервере всё равно кто-то сидит и что-то генерит.
muxa_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!
Имхо, конечно, имхо.
Одно дело генерить: /views/anketa.html?id=123456 на сервере.
Другое дело отдать «пустую страницу» на клиент /views/anketa.html?id=123456
где JS, используя Ajax, стянет всё в формате JSON с сервера для id=123456 и отрендерит страницу.
Такие вот SPA в 2016 году.
muxa_ru >Чудес не бывает, на сервере всё равно кто-то сидит и что-то генерит.
В настоящем SPA на сервере никто не генерит страницы. Отдают «почти пустую» на клиент и на клиенте JS всё и «рисует» — всё рисует, в том числе и about.html
В настоящем то SPA!
Имхо, конечно, имхо.
> в формате JSON
А формат JSON кто сгенерирует?
А формат JSON кто сгенерирует?
muxa_ru >А формат JSON кто сгенерирует?
Хороший вопрос! ;-)
Но дело в том, что тот кто JSON генерирует не отдаёт его «пауку». Ибо это «сырец», а «пауку» нужна реальная страница с данными, а не «сырой JSON».
sumanai > Нет никаких проблем в генерации HTML на сервере на лету, двадцать лет так делали, и горя не знали.
Тогда не было SPA — страницы перегружались — это ужасно!
Сейчас есть SPA — это просто прелестно!
Но возникла проблема — НЕ дублировать код — типа один для броузера (на клиенте), другой для «паука» (на сервере).
НЕ дублировать код.
В настоящее время эта проблема НЕ решена. — Какие-то подвижки в решении наметились, но до окончательной победы ещё похоже годы и годы.
А костылей да, много предлагают всяких. Костылей то.
Имхо, конечно, имхо. (С)
Хороший вопрос! ;-)
Но дело в том, что тот кто JSON генерирует не отдаёт его «пауку». Ибо это «сырец», а «пауку» нужна реальная страница с данными, а не «сырой JSON».
sumanai > Нет никаких проблем в генерации HTML на сервере на лету, двадцать лет так делали, и горя не знали.
Тогда не было SPA — страницы перегружались — это ужасно!
Сейчас есть SPA — это просто прелестно!
Но возникла проблема — НЕ дублировать код — типа один для броузера (на клиенте), другой для «паука» (на сервере).
НЕ дублировать код.
В настоящее время эта проблема НЕ решена. — Какие-то подвижки в решении наметились, но до окончательной победы ещё похоже годы и годы.
А костылей да, много предлагают всяких. Костылей то.
Имхо, конечно, имхо. (С)
UFO just landed and posted this here
> Тогда не было SPA — страницы перегружались — это ужасно!
Я по несколько раз на дню жму обновление страницы в ютуб-аналитике.
Ну слетает у него цветовая схема для графиков по время всего этого JSON-дёрганья. А после обовления страницы все привычные цвета на месте.
Я по несколько раз на дню жму обновление страницы в ютуб-аналитике.
Ну слетает у него цветовая схема для графиков по время всего этого JSON-дёрганья. А после обовления страницы все привычные цвета на месте.
Тогда не было SPA — страницы перегружались — это ужасно!
Сейчас есть SPA — это просто прелестно!
По правде говоря, сделать SPA с теми же плюшками, что и у классического сайта ― не тривиально. И часто на это не заморачиваются. Видимо ввиду того, что ряд вещей не используют сами, и не думают, что они могут использоваться кем-то другим.
Пример. Ссылки. Обычный сайт позволяет перейти сразу на нужную страницу по её ссылке. Скопировать же ссылку на страницу можно через контекстное меню, даже не переходя по ней. Никто не мешает в SPA делать так же. Однако очень часто не делают. Что сильно раздражает.
Или скажем якоря. Можно дать ссылку сразу на нужный раздел большой страницы. В той же вики регулярное явление. Такое уже сложнее сделать работающим асинхронно. Но можно. Чаще всего никто не заморачивается. А зря.
Ещё отмечу, что для больших SPA обязательно нужно грамотно продумывать бандлы и вообще загрузку всех зависимостей по необходимости. Чаще всего на это забивают. Недавний пример ― тинкьковский сайт, тот самый epic fail на 3+ MiB. Хотя они вроде сказали, что они заморочились. Но 3 MiB скриптов для главной страницы, WAT? Сейчас это уже чуть ли не норма. 3 MiB одних только скриптов. Сразу. После загрузки! Да, можно так не делать. Но люди идут по пути наименьшего сопротивления. И получаются все эти огромные перегруженные монстры.
Полагаю, что если крепко повспоминать, то таких вот нюансов можно с десятка полтора вспомнить. И всё будет сводиться к тому, что обойти проблему можно, но не всегда легко, и в итоге многие проблемы игнорируются. В то время как в классическом случае, ты или вынужден их решать (хочешь-не-хочешь), или они решаются архитектурно (само по себе).
Сделать сайт по классической схеме чаще всего просто проще и быстрее. Да и готовых решений без монад, редьюсеров, webpack-а, redux-а, immutable, transpile и пр. выше крыши.
sumanai > И не вижу ничего ужасного в перезагрузке страницы.
Привычка. Наверно. Но это ужасно.
muxa_ru > Я по несколько раз на дню жму обновление страницы в ютуб-аналитике.
Хм. Печально.
faiwer > Сделать сайт по классической схеме чаще всего просто проще и быстрее.
Мало того, сайтов по классической схеме большинство в инете! Большинство.
А вот настоящих SPA сайтов мало. Просто мало. Очень мало. Печально.
Имхо, конечно, имхо. (С)
Привычка. Наверно. Но это ужасно.
muxa_ru > Я по несколько раз на дню жму обновление страницы в ютуб-аналитике.
Хм. Печально.
faiwer > Сделать сайт по классической схеме чаще всего просто проще и быстрее.
Мало того, сайтов по классической схеме большинство в инете! Большинство.
А вот настоящих SPA сайтов мало. Просто мало. Очень мало. Печально.
Имхо, конечно, имхо. (С)
Да вполне все решается. Даже название уже пару лет как придумали чуваки из AirBnB: изоморфные js приложения. Не тривиально конечно, хотя когда появились SPA, специалисты работавшие до этого по схеме с толстым сервером и тонким клиентом, тоже по началу офигевали. Да и сейчас не все архитектурные вопросы SPA решены.
PaulMaly >Не тривиально конечно, хотя когда появились SPA, специалисты работавшие до этого по схеме с толстым сервером и тонким клиентом, тоже по началу офигевали. Да и сейчас не все архитектурные вопросы SPA решены.
Да, слово «изоморфные» появилось. Верно. Но проблемы не решены вовсе. Мало того — там ещё «конь фактически и не повалился».
Кстати, а как Google «раскручивает сайт» со SPA? -, например, в случае с React его пауку на вход подаётся «белый лист» с одним бандлом к этому листу. И всё. — Крутись как хошь то!
Как дать понять пауку что индексировать а что нет? — Текст то при запуске JS возникает (может возникать) то.
И вот, в 2016 году — всё как по старинке — пауку даём отрендереную на сервере страницу, а броузеру вариант в виде SPA. — Со всеми вытекающими отсюда проблемами.
Да, слово «изоморфные» появилось. Верно. Но проблемы не решены вовсе. Мало того — там ещё «конь фактически и не повалился».
Кстати, а как Google «раскручивает сайт» со SPA? -, например, в случае с React его пауку на вход подаётся «белый лист» с одним бандлом к этому листу. И всё. — Крутись как хошь то!
Как дать понять пауку что индексировать а что нет? — Текст то при запуске JS возникает (может возникать) то.
И вот, в 2016 году — всё как по старинке — пауку даём отрендереную на сервере страницу, а броузеру вариант в виде SPA. — Со всеми вытекающими отсюда проблемами.
Не знаю как вы в 2016 году, а мы в том же году пишем изоморфные веб приложения поверх микросервисов. Отдаем на все синхронные запросы к фронтенд-серверу полностью готовое для браузера приложение (html + клиентский код), которое в браузере с поддержкой js продолжает работать как SPA, вплоть до следующего синхронного запросы (например юзер перезагрузил страницу сам). Причем некоторые фичи SPA работают в зависимости от поддержки браузером и фолбеком на сервер, если это возможно конечно. При всем при этом общего кода между клиентским и серверным фронтендом в районе 90-95%. Проблемы есть, но они чисто специфические и это того стоит.
PaulMaly > Не знаю как вы в 2016 году, а мы в том же году пишем изоморфные веб приложения поверх микросервисов.
Не, мы как все — нам надо чтобы Гугл (и прочие) часть наших страниц индексировал, а станицы где у нас редактор (частично там и SPA) то и не трогал.
Код так и разбит. — И вот это неверно, наверное. Но, работает. ;-)
Не, мы как все — нам надо чтобы Гугл (и прочие) часть наших страниц индексировал, а станицы где у нас редактор (частично там и SPA) то и не трогал.
Код так и разбит. — И вот это неверно, наверное. Но, работает. ;-)
Ну так нет никакой проблемы запретить Гуглу индексировать часть урлов. Изоморфные приложения с этим прекрасно справляются)))
PaulMaly > Ну так нет никакой проблемы запретить Гуглу индексировать часть урлов.
Часть да. Можно. Мы так и сделали. Дали ему часть урлов для индексации. Которые рендерим на сервере.
Если же мы захотим рендерить всё на клиенте — Гугл (и остальные) — обломятся.
Об этом и речь то!
Часть да. Можно. Мы так и сделали. Дали ему часть урлов для индексации. Которые рендерим на сервере.
Если же мы захотим рендерить всё на клиенте — Гугл (и остальные) — обломятся.
Об этом и речь то!
Ну моя то речь не об этом, а о том, что серверный рендеринг может исполняться тем же кодом, что и клиентский и вообще на ~95% фронтенд-сервер может содержать и исполнять общий код веб-приложения. В этом случае описанные проблемы отпадают сами собой.
То есть, если имеем навороченный клиент (современный браузер, включенный js и тп), отдаем ему страницу по текущему урл и код клиентского приложения, и дальше все работает как в обычном SPA. Если имеем примитивный клиент (без js, краулер и тп) тогда этот клиент делает исключительно синхронные запросы к серверу на которые сервер всегда отвечает готовой отрендеренной страницей. Все.
Дальше хотим блокируем определенные урлы, хотим не блокируем.
То есть, если имеем навороченный клиент (современный браузер, включенный js и тп), отдаем ему страницу по текущему урл и код клиентского приложения, и дальше все работает как в обычном SPA. Если имеем примитивный клиент (без js, краулер и тп) тогда этот клиент делает исключительно синхронные запросы к серверу на которые сервер всегда отвечает готовой отрендеренной страницей. Все.
Дальше хотим блокируем определенные урлы, хотим не блокируем.
PaulMaly > Если имеем примитивный клиент (без js, краулер и тп) тогда этот клиент делает исключительно синхронные запросы к серверу на которые сервер всегда отвечает готовой отрендеренной страницей.
Я слыхал, что появились такие технологии — но вот насколько они уже зрелые?
Я слыхал, что появились такие технологии — но вот насколько они уже зрелые?
NodeJS существует по меньшей мере 7 лет. На нем полностью реализованы тысячи проектов. Иными словами вы уже 7 лет можете рендерить html в браузере и на сервере с помощью одного и того же кода на js. Вот и все технологии. Да конечно, с появлением таких штук как React с его серверным рендерингом все стало проще, плюс термин придумали и уважаемые библиотеки стали поддерживать не только браузер, но и ноду, и наоборот. Более того, при изоморфном подходе вам даже бекенд на ноду переписывать не надо, если он у вас к примеру на PHP/Python/Ruby/etc. Пусть остаются.
PaulMaly > NodeJS существует по меньшей мере 7 лет.
Верно. Но изоморфность это совсем модная штука.
PaulMaly > Более того, при изоморфном подходе вам даже бекенд на ноду переписывать не надо, если он у вас к примеру на PHP/Python/Ruby/etc.
И всё же я подумал — а кому нужна эта изоморфность?
«Обычный» рендер страницы на сервере — на порядок (в 10 раз) быстрее изоморфного рендера страницы на сервере. — Так что пауку и юзеру быстрее отдать уже «обычным образом» отрендеренную страницу.
А вот редактирование (формы) или страницы типа «админки» и прочего такого же вида — то есть страницы, которые пауку от Гугла (и прочим паукам) не надо вовсе индексировать — те вполне могут быть отрендерены на клиенте.
Ниша изоморфного рендера страницы на сервере (с запуском на сервере типа «броузера» в котором запускается JS) очень мала (до призрачности), по крайней мере по состоянию на конец 2016 года.
Имхо, конечно, имхо.
Верно. Но изоморфность это совсем модная штука.
PaulMaly > Более того, при изоморфном подходе вам даже бекенд на ноду переписывать не надо, если он у вас к примеру на PHP/Python/Ruby/etc.
И всё же я подумал — а кому нужна эта изоморфность?
«Обычный» рендер страницы на сервере — на порядок (в 10 раз) быстрее изоморфного рендера страницы на сервере. — Так что пауку и юзеру быстрее отдать уже «обычным образом» отрендеренную страницу.
А вот редактирование (формы) или страницы типа «админки» и прочего такого же вида — то есть страницы, которые пауку от Гугла (и прочим паукам) не надо вовсе индексировать — те вполне могут быть отрендерены на клиенте.
Ниша изоморфного рендера страницы на сервере (с запуском на сервере типа «броузера» в котором запускается JS) очень мала (до призрачности), по крайней мере по состоянию на конец 2016 года.
Имхо, конечно, имхо.
> Верно. Но изоморфность это совсем модная штука.
Да нет, это термин новая и модная штука. Сама идея довольно очевидная — если есть единая среда исполнения на клиенте и сервере почему этим не пользоваться?
> «Обычный» рендер страницы на сервере — на порядок (в 10 раз) быстрее изоморфного рендера страницы на сервере. — Так что пауку и юзеру быстрее отдать уже «обычным образом» отрендеренную страницу.
Я вас умоляю, откуда такие глупые предрассудки? Чем рендер на стороне сервера с помощью того же PHP отличается от рендера NodeJS. Более того, гарантирую нода отработает запрос быстрее в большинстве случаев. Да и вообще не понятно, что значит «обычным образом».
> А вот редактирование (формы) или страницы типа «админки» и прочего такого же вида — то есть страницы, которые пауку от Гугла (и прочим паукам) не надо вовсе индексировать — те вполне могут быть отрендерены на клиенте.
Не во всех проектах есть такие страницы, а значит по вашей логике для них нужен исключительно серверный рендер, но это не так. Нет никакой причины не переносить часть задач на клиента, который эти задачи может взять на себя и исполнить. Это и есть изоморфность в данном контексте — сервер может делать всю работу, но эту же работу может делать и клиент, если может.
> Ниша изоморфного рендера страницы на сервере (с запуском на сервере типа «броузера» в котором запускается JS) очень мала (до призрачности), по крайней мере по состоянию на конец 2016 года.
Что это еще за «ниша» такая? Вы не понимаете, что абсолютно любой проект можно сделать таким способом? От навороченного веб-апп и заканчивая тупым новостным порталом. При этом мы получаем seo-friendly, user-friendly и даже mobile-app-friendly прямо из коробки.
Да нет, это термин новая и модная штука. Сама идея довольно очевидная — если есть единая среда исполнения на клиенте и сервере почему этим не пользоваться?
> «Обычный» рендер страницы на сервере — на порядок (в 10 раз) быстрее изоморфного рендера страницы на сервере. — Так что пауку и юзеру быстрее отдать уже «обычным образом» отрендеренную страницу.
Я вас умоляю, откуда такие глупые предрассудки? Чем рендер на стороне сервера с помощью того же PHP отличается от рендера NodeJS. Более того, гарантирую нода отработает запрос быстрее в большинстве случаев. Да и вообще не понятно, что значит «обычным образом».
> А вот редактирование (формы) или страницы типа «админки» и прочего такого же вида — то есть страницы, которые пауку от Гугла (и прочим паукам) не надо вовсе индексировать — те вполне могут быть отрендерены на клиенте.
Не во всех проектах есть такие страницы, а значит по вашей логике для них нужен исключительно серверный рендер, но это не так. Нет никакой причины не переносить часть задач на клиента, который эти задачи может взять на себя и исполнить. Это и есть изоморфность в данном контексте — сервер может делать всю работу, но эту же работу может делать и клиент, если может.
> Ниша изоморфного рендера страницы на сервере (с запуском на сервере типа «броузера» в котором запускается JS) очень мала (до призрачности), по крайней мере по состоянию на конец 2016 года.
Что это еще за «ниша» такая? Вы не понимаете, что абсолютно любой проект можно сделать таким способом? От навороченного веб-апп и заканчивая тупым новостным порталом. При этом мы получаем seo-friendly, user-friendly и даже mobile-app-friendly прямо из коробки.
PaulMaly > Сама идея довольно очевидная — если есть единая среда исполнения на клиенте и сервере почему этим не пользоваться?
Она появилась совсем недавно. Едина среда.
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 > Я вас умоляю, откуда такие глупые предрассудки?
Да все об этом пишут.
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 в «броузере» на сервере все пауки корректно индексируют страницу.
Твиттер, бают, попытался всё рендерить на клиенте — отказались — на сервере быстрее и надёжнее.
Я не вижу пока никакой причины использовать изоморфный рендер. Только из-за любознательности. Пока не для продакшен. Имхо.
> Она появилась совсем недавно. Едина среда.
Единая стеда — это NodeJS и он появился минимум 7 лет назад. Не так уж и недавно, особенно учитывая какой кусок продакшен проектов он уже успел откусить.
> Да все об этом пишут.
Это не ответ. Учитывая что изоморфный рендер мало отличается от обычного серверного рендера, у меня есть сомнения на этот счет.
> «Обычным образом» — это написать просто java-класс, на сервере исполняемый. — В данном случае сервлет, то есть это java-класс получаемый из исходной JSP страницы, которая пишется на особом языке фактически. Пишется и компилируется налету в бинарный исполняемый на сервере java-класс (типа по аналогии как JSX в JS-код).
О, ну вы либо динозавр либо из энтерпрайза.))) Вообще Java is good, но разработка «обычным образом» на Java сильно сложнее, дольше и дороже, даже чем изоморфным на JS, хотя многие критикуют изоморфность как раз в этом ключе, мол зачем запариваться и тратить время/деньги. По дороговизне с Java'ой наверное никто не сможет конкурировать, разве что писать сервер на C/C++))))
> Это классика реализации.
Конечно классика, толстый сервер, тонкий клиент. Но это совсем не интерактивно и не подходит современным веб-приложениям. Однако если Хабр переписать изоморфным способом, хуже он не станет, только лучше.
> Нельзя. Если seo-friendly — то только «обычным рендером» на сервере — так быстрее в разы, чем изоморфный рендер.
Что значит нельзя? Похоже вы не догоняете, что изоморфный рендер ничем не отличается от чисто серверного. Выключите JS на клиенте и у вас чисто серверный рендер. И никаких «быстрее в разы» тут нет. Зато есть отсутствие дублирования кода на сервере и на клиенте и еще много полезных вещей из коробки.
> Твиттер, бают, попытался всё рендерить на клиенте — отказались — на сервере быстрее и надёжнее.
Ну так это как раз мой пример из одного из тредов выше, где комментаторы говорили, что рендерить надо исключительно на клиенте. Я же говорю, что рендерить надо уметь и там и там, но делать это с умом. Если синхронный запрос, то по-любому рендер на сервере, когда код попал на клиент, мы можем решить стоит ли доверять ему рендер, способен ли он на это, или же продолжать все делать через сервер. Ничто не мешает сделать приложение настолько умным, чтобы оно могло решать в каждый конкретный момент имеет ли смысл продолжать рендерить на клиенте (например последняя страница рендерилась медленно из-за нехватки памяти) или же отдать рендер на сервер, хотя бы на время. Вы просто не представляете какие удивительные возможности дает изоморфный подход. Классической реализации это даже не снилось.
> Я не вижу пока никакой причины использовать изоморфный рендер. Только из-за любознательности. Пока не для продакшен.
Еще раз, по сути своей изоморфный рендер ниче не отличается от чисто серверного. Отличается лишь подход к написанию кода и разделению зон ответственности между чисто клиентом и чисто серверными вещами.
Единая стеда — это NodeJS и он появился минимум 7 лет назад. Не так уж и недавно, особенно учитывая какой кусок продакшен проектов он уже успел откусить.
> Да все об этом пишут.
Это не ответ. Учитывая что изоморфный рендер мало отличается от обычного серверного рендера, у меня есть сомнения на этот счет.
> «Обычным образом» — это написать просто java-класс, на сервере исполняемый. — В данном случае сервлет, то есть это java-класс получаемый из исходной JSP страницы, которая пишется на особом языке фактически. Пишется и компилируется налету в бинарный исполняемый на сервере java-класс (типа по аналогии как JSX в JS-код).
О, ну вы либо динозавр либо из энтерпрайза.))) Вообще Java is good, но разработка «обычным образом» на Java сильно сложнее, дольше и дороже, даже чем изоморфным на JS, хотя многие критикуют изоморфность как раз в этом ключе, мол зачем запариваться и тратить время/деньги. По дороговизне с Java'ой наверное никто не сможет конкурировать, разве что писать сервер на C/C++))))
> Это классика реализации.
Конечно классика, толстый сервер, тонкий клиент. Но это совсем не интерактивно и не подходит современным веб-приложениям. Однако если Хабр переписать изоморфным способом, хуже он не станет, только лучше.
> Нельзя. Если seo-friendly — то только «обычным рендером» на сервере — так быстрее в разы, чем изоморфный рендер.
Что значит нельзя? Похоже вы не догоняете, что изоморфный рендер ничем не отличается от чисто серверного. Выключите JS на клиенте и у вас чисто серверный рендер. И никаких «быстрее в разы» тут нет. Зато есть отсутствие дублирования кода на сервере и на клиенте и еще много полезных вещей из коробки.
> Твиттер, бают, попытался всё рендерить на клиенте — отказались — на сервере быстрее и надёжнее.
Ну так это как раз мой пример из одного из тредов выше, где комментаторы говорили, что рендерить надо исключительно на клиенте. Я же говорю, что рендерить надо уметь и там и там, но делать это с умом. Если синхронный запрос, то по-любому рендер на сервере, когда код попал на клиент, мы можем решить стоит ли доверять ему рендер, способен ли он на это, или же продолжать все делать через сервер. Ничто не мешает сделать приложение настолько умным, чтобы оно могло решать в каждый конкретный момент имеет ли смысл продолжать рендерить на клиенте (например последняя страница рендерилась медленно из-за нехватки памяти) или же отдать рендер на сервер, хотя бы на время. Вы просто не представляете какие удивительные возможности дает изоморфный подход. Классической реализации это даже не снилось.
> Я не вижу пока никакой причины использовать изоморфный рендер. Только из-за любознательности. Пока не для продакшен.
Еще раз, по сути своей изоморфный рендер ниче не отличается от чисто серверного. Отличается лишь подход к написанию кода и разделению зон ответственности между чисто клиентом и чисто серверными вещами.
UFO just landed and posted this here
Очень странное предложение забить на Яндекс до времен, когда он поумнеет. Вдвойне странно, что все это идет от сеошников.
А как вы описываете стейты в $stateProvider, чтобы менять title динамически?
Sign up to leave a comment.
JavaScript и SEO в 2016 году