Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
А зачем вообще использовать серверный рендеринг?
Даёт все возможности SPA, не жертвуя при этом оптимизацией в поисковых системах.
Давно слежу за темой SSR, как-то пробовал настроить SSR с реактом, много матерился (из-за неопытности, конечно). Потом долго не работал с SPA-приложениями, а сейчас как раз потихоньку изучаю Vue, разрабатывая pet-project.
В связи с этим вопрос: а у вас есть опыт, показывающий, что такая оптимизация реально помогает с поисковиками? Просто я уже много раз слышал, что, как минимум, гугловские боты умеют выполнять js, т.е. они уже давно не просто wget'ом страницы качают. Вот и думаю, может гугл/яндекс и так смогут мой сайт посмотреть и ранжировать его не хуже, чем «классические» сайты?
В связи с этим вопрос: а у вас есть опыт, показывающий, что такая оптимизация реально помогает с поисковиками? Просто я уже много раз слышал, что, как минимум, гугловские боты умеют выполнять js, т.е. они уже давно не просто wget'ом страницы качают. Вот и думаю, может гугл/яндекс и так смогут мой сайт посмотреть и ранжировать его не хуже, чем «классические» сайты?
Ну на самом деле для SEO по сути кроме разметки ничего не нужно, а с этим SSR как раз и справляется, он для этого и создан. Так что да, с оптимизацией это не просто помогает, а является одним из способов оптимизировать в принципе :)
Есть ещё пререндеринг, но серверный рендеринг — это его эволюция, то есть пререндеринг просто можно считать устаревшим подходом.
Насчёт интерпретации js поисковиками я слышал, но я очень скептически к этому отношусь. Представьте, сколько мощностей нужно задействовать, чтобы за адекватное время запустить каждыйговносайт со всем его кодом в масштабах гугла. Ну и плюс слышал, что эта дрянь пока что не очень хорошо работает — старый добрый HTML всё равно надёжнее. По крайней мере ближайшие лет 5 точно (имхо).
Есть ещё пререндеринг, но серверный рендеринг — это его эволюция, то есть пререндеринг просто можно считать устаревшим подходом.
Насчёт интерпретации js поисковиками я слышал, но я очень скептически к этому отношусь. Представьте, сколько мощностей нужно задействовать, чтобы за адекватное время запустить каждый
Был где-то сайт, где проверялись приемы и подходы и как это влияет на поисковики. Попробуйте поискать, но насколько я помню SSR дает значительно лучший результата, так как даже при выполнении JS они не дожидаются многих асинхронных функций
Кратко — это всё провокация, поисковики не умеют индексировать JS сайты. И ещё долгое время не будут уметь.
Они могут выполнять js на сайтах, но только для обнаружения текста или факта его видимости / невидимости, но это с поисковой оптимизацией ничего общего не имеет.
Они могут выполнять js на сайтах, но только для обнаружения текста или факта его видимости / невидимости, но это с поисковой оптимизацией ничего общего не имеет.
Поисковые боты умеют только в синхронный JS, ваших аяксов никто ждать не будет.
Спасибо, за статью.
Недавно на хабре вышел пост habrahabr.ru/post/338612 про использование нескольких сборок.
Можно-ли такой подход применить во Vue ssr?
Недавно на хабре вышел пост habrahabr.ru/post/338612 про использование нескольких сборок.
Можно-ли такой подход применить во Vue ssr?
На php разработку не веду, но так будет более понятно для примера.
glot.io/snippets/eui1on1so3
И не нужна нода на сервере.
glot.io/snippets/eui1on1so3
И не нужна нода на сервере.
А какая связь этого куска кода с серверным рендерингом?
Пример, как можно сформировать html на сервере не исполняя клиентский код на нем.
Это я и так вижу :)
Но связи с серверным рендерингом по-прежнему не улавливаю :)
Неужели все, кто пытается реализовать SSR, не заметили, как, оказывается, всё элементарно?
Но связи с серверным рендерингом по-прежнему не улавливаю :)
Неужели все, кто пытается реализовать SSR, не заметили, как, оказывается, всё элементарно?
Для лучшего понимания происходящего имеется русская документация о серверном рендеринге в vue — vue-ssr
Вы конечно сделали все по своему, хотя у vue есть инструменты для SSR «из коробки», подробнее по ссылке выше…
Почему же по-своему, я на неё и опирался, когда всё это делал. Просто там было далеко не всё, что нужно мне, да и вообще в любом более-менее серьёзном проекте. Не описано, как подмешивать состояния компонентов (только vuex state), ни слова про взаимодействие с API и т.п.
Правда, этого всего и не должно быть в документации, так как её цель — описать возможности, а не давать готовый код. Второе как раз и есть задача, которую я пытаюсь решить в этой статье.
Но было бы правильно оставить в статье ссылку на документацию, это я сделаю в ближайшее время.
Правда, этого всего и не должно быть в документации, так как её цель — описать возможности, а не давать готовый код. Второе как раз и есть задача, которую я пытаюсь решить в этой статье.
Но было бы правильно оставить в статье ссылку на документацию, это я сделаю в ближайшее время.
[не в ту ветку]
А можно спросить умных людей что кроется за фразой «разрабатывать SPA держа в уме SSR» или может быть статья есть классическая?
Чтобы говорить более конкретно пусть будет пример: дашборд каких-нибудь биржевых индексов. Первое что приходит на ум: роутинг, чтобы было удобно указывать что же именно попадает под SSR (личные кабинеты, даже если они публичны, не интересны SEO). Что-то еще?
Чтобы говорить более конкретно пусть будет пример: дашборд каких-нибудь биржевых индексов. Первое что приходит на ум: роутинг, чтобы было удобно указывать что же именно попадает под SSR (личные кабинеты, даже если они публичны, не интересны SEO). Что-то еще?
Если исходить из вашего примера, то да, SSR должен отдавать только контент для анонимусов, всё остальное определяется/грузится уже на клиенте.
Мало того, можно целые разделы рендерить исключительно на клиенте, типа тех же личных кабинетов со своими внутренними роутами (на Vue это делается очень просто). С сервера в таком случае приходит пустая страница или, скажем, какой-нибудь индикатор загрузки, а на клиенте уже получаем информацию о текущем пользователе (скажем, в хуке beforeMount или mounted, которые на сервере не вызываются) и выводим в зависимости от его наличия форму для входа или непосредственно личный кабинет (
В общем-то это всё, что нужно понимать, статья тут, мне кажется, не нужна :)
Мало того, можно целые разделы рендерить исключительно на клиенте, типа тех же личных кабинетов со своими внутренними роутами (на Vue это делается очень просто). С сервера в таком случае приходит пустая страница или, скажем, какой-нибудь индикатор загрузки, а на клиенте уже получаем информацию о текущем пользователе (скажем, в хуке beforeMount или mounted, которые на сервере не вызываются) и выводим в зависимости от его наличия форму для входа или непосредственно личный кабинет (
<router-view />).В общем-то это всё, что нужно понимать, статья тут, мне кажется, не нужна :)
Ну а причем тут только SEO? Разве не очевидно, что у SSR значительно больше преимуществ? Например, более быстрая начальная загрузка страницы, без лишних индикаторов загрузки, возможность сделать нормальный «Progressive Enhancement» приложения, вплоть до полной поддержки работы без JS. Возможность сделать приложение максимально «environment agnostic». Имхо, это уже много, тем более с современными фреймверками это не слишком сложно, просто надо чуть больше заморочится.
Не знаю, в каких случаях реально нужно обходиться без JS. Сейчас даже на недорогих моделях телефонов можно открыть сайт на фреймфорке и без особых тормозов с ним работать.
Environment agnostic — тоже не сказал бы. Всё равно для чтения HTML нужен браузер, который поддерживает также и JS, так что никаких дополнительных ограничений, связанных со средой выполнения, JS не накладывает. Я ни разу не встречал живого человека, который был бы одновременно в своём уме и выключал JS в браузере :)
Единственное, с чем глупо не согласиться — скорость первичной загрузки. Но это в случае с SPA мелочь, ради которой не стоит заморачиваться с SSR.
В общем, по моему мнению SEO — единственная причина использовать SSR. Я пытался придумать другие реально веские причины для этого, но так ни к чему и не пришёл.
Environment agnostic — тоже не сказал бы. Всё равно для чтения HTML нужен браузер, который поддерживает также и JS, так что никаких дополнительных ограничений, связанных со средой выполнения, JS не накладывает. Я ни разу не встречал живого человека, который был бы одновременно в своём уме и выключал JS в браузере :)
Единственное, с чем глупо не согласиться — скорость первичной загрузки. Но это в случае с SPA мелочь, ради которой не стоит заморачиваться с SSR.
В общем, по моему мнению SEO — единственная причина использовать SSR. Я пытался придумать другие реально веские причины для этого, но так ни к чему и не пришёл.
Не знаю, в каких случаях реально нужно обходиться без JS. Сейчас даже на недорогих моделях телефонов можно открыть сайт на фреймфорке и без особых тормозов с ним работать.
Ну во-первых, около 1% юзеров вообще не получают JS. Делал доклад на эту тему, могу найти пруф.
Я ни разу не встречал живого человека, который был бы одновременно в своём уме и выключал JS в браузере :)
«Видишь суслика, а он есть»))) Даже на хабре полно таких людей. Представьте себе остаются люди, которые просто отключают скрипты умышлено. В зависимости от специфики вашего приложения, таких людей можно или нельзя игнорить. Правда не понятно зачем это делать, если можно просто сделать Progressive Enhancement и пусть ваше приложение умеет работать вообще без JS на клиенте.
Единственное, с чем глупо не согласиться — скорость первичной загрузки. Но это в случае с SPA мелочь, ради которой не стоит заморачиваться с SSR.
Это вы так сейчас неудачно пошутили? А можете пояснить почему же для SPA — это мелочь?
Скрипты для сложных веб-приложений стали весить хренову тучу Мб, а значит если у вас чистый SPA, то ваши пользователи будут довольно долго «любоваться» классным загрузчиком. Особенно на слабой мобильной сети. И в этом смысле, нужно помнить что у вас есть всего 3 секунды, чтобы их заинтересовать, а значит 2-3Мб ваших скриптов на слабом мобильном интернете приведут ваше SPA в ситуацию, когда юзеры будут тупо закрывать его не дождавшись контента. Эта проблема легко решается применением SSR и изоморфных подходов.
Environment agnostic — тоже не сказал бы. Всё равно для чтения HTML нужен браузер, который поддерживает также и JS, так что никаких дополнительных ограничений, связанных со средой выполнения, JS не накладывает.
Есть всякие Cordova/Electron/etc. и у них немного разные принципы к построению приложения относительно того же веба. И там 3Мб скриптов не передаются по сети, а значит можно делать чистый SPA. Так где появляется сеть, я уже написал выше, поддержка SSR будет очень кстати. Юзая изоморфные подходы, вам не нужно думать как лучше поступить. Если вам нужен SSR и все его плюшки — юзаем, нужен чисто клиентский SPA — юзаем, нужен чистый серверный апп — юзаем. И нет проблем. Посмотрите кстати доклад Netflix как они ускорили сайт на 50% просто выпилив реакт с клиента и оставив его на сервере.
В общем, по моему мнению SEO — единственная причина использовать SSR. Я пытался придумать другие реально веские причины для этого, но так ни к чему и не пришёл.
Да если рассуждать как вы, то SPA и SEO не нужно. Вы же наверное из тех, кто делает SPA только для кабинетов и админок.)))) Хотя во многом это уже не так и лишать юзеров более публичных веб-приложения и даже веб-сайтов возможности находить их в поисковиках и при этом иметь быстрый интерфейс и UX, это довольно глупо, при таких то возможностях, которые мы имеем сейчас.
Ну во-первых, около 1% юзеров вообще не получают JS. Делал доклад на эту тему, могу найти пруф.
В каком плане не получают? Доклад посмотреть было бы интересно, да!
«Видишь суслика, а он есть» ...
Я и не утверждал, что таких людей нет. Просто их недостаточно много для того, чтобы только ради них внедрять SSR. Конечно, всё будет зависеть от ЦА, но сложно представить такую ЦА, где достаточно большая доля людей без JS.
Это вы так сейчас неудачно пошутили? А можете пояснить почему же для SPA — это мелочь? ...
Нет, я серьёзно :) По двум причинам:
— скрипты грузятся один раз и кэшируются, то есть при всех последующих загрузках страницы проблем с этим не будет
— в SPA нет явных физических переходов между страницами сайта/приложения, поэтому потерпеть придётся всего один раз при открытии ресурса
Скрипты для сложных веб-приложений стали весить хренову тучу Мб…
нужно помнить что у вас есть всего 3 секунды, чтобы их заинтересовать
Это легко решается с помощью code splitting в webpack. То есть я не утверждаю, что проблемы нет, но есть более простые альтернативные способы их решения. SSR же — стрельба из пушки по воробьям.
Есть всякие Cordova/Electron/etc. и у них немного разные принципы к построению приложения относительно того же веба ...
Ну для таких целей подозреваю (не уверен), что можно просто делать разные сборки одного и того же приложения. К тому же они будут существовать параллельно с SSR, так как они вообще не имеют прямого к нему отношения. Ну и JS эти технологии прекрасно исполняют (иначе зачем они вообще), так что это принципе не аргумент в данном случае.
Да если рассуждать как вы, то SPA и SEO не нужно. Вы же наверное из тех, кто делает SPA только для кабинетов и админок.))))
Зачем же вы так меня обижаете :(
Я, наоборот, топлю за то, чтобы вообще любой проект сложнее бложика делать как SPA, а проблемы с SEO решать серверным рендерингом. При должной квалификации разработчиков в человекочасах потерь не будет (скорее наоборот), зато UI/UX получит значительный прирост.
Вообще, мой посыл не совсем в том, что не надо использовать SSR для чего-либо кроме SEO. Я говорю о том, что все остальные проблемы, которые решает SSR не стоят того, чтобы его внедрять, так как можно обойтись меньшей кровью.
Но с другой стороны SSR достаточно один раз настроить и потом везде использовать без дополнительных затрат, и все новые проекты лично я бы всегда делал с поддержкой SSR, так как мне, как разработчику, у которого есть для этого готовое решение, это ничего не стоит.
Другое дело пересаживать на SSR какой-то существующий фронтенд, тут всё значительно сложнее.
В каком плане не получают? Доклад посмотреть было бы интересно, да!
Вот FYI: gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement
Доклад вроде где-то на YouTube доступен, если найду, пришлю в личку.
Я и не утверждал, что таких людей нет. Просто их недостаточно много для того, чтобы только ради них внедрять SSR. Конечно, всё будет зависеть от ЦА, но сложно представить такую ЦА, где достаточно большая доля людей без JS.
Ну я тоже не утверждал, что SSR нужно внедрять только ради них))) Это всегда совокупность факторов. Возможно в колличественном смысле ЦА не большая, зато может оказаться важной. Вообще не нужно игнорить людей, если есть такая возможность. Ну и опять же, может это и не главное преимущество SSR, но сильно повышает «accessibility» приложения.
— скрипты грузятся один раз и кэшируются, то есть при всех последующих загрузках страницы проблем с этим не будет
А если не грузятся? Не успели за 3 секунды — юзер закрыл ваш ресурс, JS не успел загрузиться.
— в SPA нет явных физических переходов между страницами сайта/приложения, поэтому потерпеть придётся всего один раз при открытии ресурса
Почему вообще 1 раз? Кэш браузера это прекрасно, но вы вообще не дописываете аппу свою? А значит, грузиться будет не один раз, а значит если вы код доработали, юзеру опять придется ждать))) Представляю текст загрузчика: «Подождите еще 10 секунд, а потом мы будем грузиться быстро» ))))))
Это легко решается с помощью code splitting в webpack. То есть я не утверждаю, что проблемы нет, но есть более простые альтернативные способы их решения. SSR же — стрельба из пушки по воробьям.
Code splitting is good. Но все же это не решает проблему полностью. Плюс применение этого подхода вообще обязательно, даже в изоморфном приложении. И это будет работать быстрее на каждую загрузку. Поэтому изоморфная аппа всегда будет быстрее на старте, чем чистый SPA. Ну а в процессе работы они будут одинаково быстры. И никаких воробьев там нет, если бы «code splitting» полностью решал проблему старта приложения, то она не была бы одной из самых острых в SPA.
Ну для таких целей подозреваю (не уверен), что можно просто делать разные сборки одного и того же приложения. К тому же они будут существовать параллельно с SSR, так как они вообще не имеют прямого к нему отношения. Ну и JS эти технологии прекрасно исполняют (иначе зачем они вообще), так что это принципе не аргумент в данном случае.
Блин, ну я же написал, что для веба и когда у вас файлы бегают по сети, применение SSR — это очень важно, но при этом это не важно Cordova/Electron/etc. И тут с изоморфным подходом вы можете сделать сборку для тех кому важен SSR и для тех, кому он не важен. Без изменения кода и без компромиссов с самим собой. Это и называется «environment agnostic», т.е. вы можете выбирать наилучший подход для каждой среды.
Зачем же вы так меня обижаете :(
Я, наоборот, топлю за то, чтобы вообще любой проект сложнее бложика делать как SPA, а проблемы с SEO решать серверным рендерингом. При должной квалификации разработчиков в человекочасах потерь не будет (скорее наоборот), зато UI/UX получит значительный прирост.
Сорян, обижать не хотел. Да и только что обратил внимание, что вы автор статьи. Правда теперь не совсем понимаю вашу аргиментацию. Если концентрироваться лишь на SEO, тогда ребята, которые не хотят, как они говорят «заморачиваться» с изоморфностью скажут вам, что есть phantomjs и prerender и они прекрасно решают эту проблему. Зачем тогда «из пушки по воробьям»?
Вообще, мой посыл не совсем в том, что не надо использовать SSR для чего-либо кроме SEO. Я говорю о том, что все остальные проблемы, которые решает SSR не стоят того, чтобы его внедрять, так как можно обойтись меньшей кровью.
Видимо для вас SEO — это главный аргумент. Для меня не менее важным является скорость загрузки при старте и здесь опыт Twitter и Netflix очень показателен. Ребята тоже заигрались с SPA. Ну и ваше «меньшей кровью» также сомнительно, потому что если prepender более-менее решает вопрос с SEO, но code splitting вообще не решает вопрос со стартом. Да код начинает грузиться параллельно, а значит быстрее, но SSR + code splitting все равно будет значительно быстрее.
Но с другой стороны SSR достаточно один раз настроить и потом везде использовать без дополнительных затрат, и все новые проекты лично я бы всегда делал с поддержкой SSR, так как мне, как разработчику, у которого есть для этого готовое решение, это ничего не стоит.
Именно так я и считаю.
Другое дело пересаживать на SSR какой-то существующий фронтенд, тут всё значительно сложнее.
На самом деле не так уж и сложно, хотя конечно зависит от проекта. Во-первых, не обязательно сразу делать все изоморфным, можно постепенно внедрять этот подход в разные части приложения. Во-вторых, это в принципе не так уж сложно, если конечно у проекта есть какая-то адекватная архитектура. У меня был старый проект, не большой, компонентов 20 и 5-6 страниц. Весь переход на изоморфность занял не больше 100 строк кода, причем вместе с серверным. Да там она не совсем «full», но преимущества итак были очевидны.
Я больше не буду приводить цитаты, а то слишком уж длинные комментарии получаются :)
Думаю, из контекста будет понятно, на что я отвечаю.
Статья конца 2013 года. Я не могу утверждать наверняка, потому что не имею такой статистики, но подозреваю, что ситуация сильно изменилась вместе с ростом качества, доступности и скорости интернета (много где появился 3G/4G, например), а так же падением популярности старых версий IE (УРА). Возможно, 0.2% людей с реально отключенным JS ещё остались, но цифра 0.9% скорее всего упала.
По поводу 3-секундного скрипта, кеша и доработок приложения — если применить код-сплиттинг и определённым образом настроить вебпак, то все эти проблемы решатся. Но, конечно, глупо спорить с тем, что SSR так или иначе повысит скорость отображения контента. Просто, опять же, я к тому, что это решаемо и без SSR.
Cordova и пр. — тут я просто, если честно, не понял, к чему была поднята тема. А так да, со всем согласен :)
Phantom/prerender решают те же проблемы, согласен. Но я считаю SSR своего рода эволюцией пререндеринга. Это более разумное решение, которое работает значительно быстрее + имеет хороший потенциал для оптимизации + с ним удобнее работать на сервере в целом (подключать какую-то аналитику, кешировать и прочее). То есть если есть равнозначный выбор между пререндерингом и SSR, то было бы глупо выбирать первое. Но для существующих проектов с большим количеством кода пререндеринг может быть единственным решением.
А SEO — да, главный аргумент лично для меня. Просто потому, что это единственный вариант писать код «без костылей» и не жертвовать SEO (ну, есть ещё пререндеринг, но свою позицию относительно него я уже описал). Но то, что он параллельно решает ряд других проблем или улучшает какие-то показатели — определённо, приятный бонус.
Опыт же крупных проектов по выпиливанию/впиливанию чего-то — думаю, не совсем об этом. Технологии в вебе, особенно на фронтенде, меняются с невероятной скоростью. С ними же растут потребности, критерии качества, размеры js/css файлов,… Появление проблем из-за этого всего неизбежно с любыми технологиями.
Думаю, из контекста будет понятно, на что я отвечаю.
Статья конца 2013 года. Я не могу утверждать наверняка, потому что не имею такой статистики, но подозреваю, что ситуация сильно изменилась вместе с ростом качества, доступности и скорости интернета (много где появился 3G/4G, например), а так же падением популярности старых версий IE (УРА). Возможно, 0.2% людей с реально отключенным JS ещё остались, но цифра 0.9% скорее всего упала.
По поводу 3-секундного скрипта, кеша и доработок приложения — если применить код-сплиттинг и определённым образом настроить вебпак, то все эти проблемы решатся. Но, конечно, глупо спорить с тем, что SSR так или иначе повысит скорость отображения контента. Просто, опять же, я к тому, что это решаемо и без SSR.
Cordova и пр. — тут я просто, если честно, не понял, к чему была поднята тема. А так да, со всем согласен :)
Phantom/prerender решают те же проблемы, согласен. Но я считаю SSR своего рода эволюцией пререндеринга. Это более разумное решение, которое работает значительно быстрее + имеет хороший потенциал для оптимизации + с ним удобнее работать на сервере в целом (подключать какую-то аналитику, кешировать и прочее). То есть если есть равнозначный выбор между пререндерингом и SSR, то было бы глупо выбирать первое. Но для существующих проектов с большим количеством кода пререндеринг может быть единственным решением.
А SEO — да, главный аргумент лично для меня. Просто потому, что это единственный вариант писать код «без костылей» и не жертвовать SEO (ну, есть ещё пререндеринг, но свою позицию относительно него я уже описал). Но то, что он параллельно решает ряд других проблем или улучшает какие-то показатели — определённо, приятный бонус.
Опыт же крупных проектов по выпиливанию/впиливанию чего-то — думаю, не совсем об этом. Технологии в вебе, особенно на фронтенде, меняются с невероятной скоростью. С ними же растут потребности, критерии качества, размеры js/css файлов,… Появление проблем из-за этого всего неизбежно с любыми технологиями.
Ок, давайте без цитат)))
Да, статья не самая новая, однако доводы, которые там приводятся, навряд ли устарели. Сеть есть сеть и она никогда не будет работать на 100% стабильно в любой точке мира. Ну и вот более современные цифры: blockmetry.com/blog/javascript-disabled
Что значит решается? Можете рассказать как code spliting может заставить ваше приложение быть быстрее чем он же + SSR? Или вы считаете что веб-приложение может быть «достаточно быстрым»? Как мне кажется, учитывая особенности веб, нужно использовать все возможности по ускорению, которые у нас имеются. Ибо мы никогда не знаем в какой среде работает наш юзер. Ну и опять же уверен, что Twitter и Netflix тоже в курсе возможностей вебпака, но видимо их им не хватило. Ну и лично я давно хочу реализовать идею, когда приложение само может автоматом переключаться между SSR и чистым SPA в зависимости от замеров качества соединения. Точной реализации пока нет, но думаю это сделать возможно в изоморфном стиле и совершенно не реально без него.
SSR — это не эволюция пререндера, это хорошо забытое старое. У меня как раз в презе было вступление на эту тему, где я рассказывал что вместо эволюционного развития веба, мы выбрали революционное — как только браузеры начали развиваться, все дружно кинулись на клиент, выкинув в пекло весь опыт серверной части. Это не правильно и именно изоморфность возвращает нас на эволюционный путь.
По поводу ваших доводов о SEO — они чисто субъективны. Кому-то может оказаться важнее поддерживать юзеров без JS, а кому-то просто ускорить загрузку. Вы говорите все это фигня и решается без SSR, я говорю что SEO также решается без SSR, а вы в ответ — «мне так нравится больше». Ну ок, тогда другие доводы также нравится больше и вообще зачем крутить кучу решений, если можно один раз крутануть изоморфность и сразу решить все проблемы.
Да, статья не самая новая, однако доводы, которые там приводятся, навряд ли устарели. Сеть есть сеть и она никогда не будет работать на 100% стабильно в любой точке мира. Ну и вот более современные цифры: blockmetry.com/blog/javascript-disabled
Что значит решается? Можете рассказать как code spliting может заставить ваше приложение быть быстрее чем он же + SSR? Или вы считаете что веб-приложение может быть «достаточно быстрым»? Как мне кажется, учитывая особенности веб, нужно использовать все возможности по ускорению, которые у нас имеются. Ибо мы никогда не знаем в какой среде работает наш юзер. Ну и опять же уверен, что Twitter и Netflix тоже в курсе возможностей вебпака, но видимо их им не хватило. Ну и лично я давно хочу реализовать идею, когда приложение само может автоматом переключаться между SSR и чистым SPA в зависимости от замеров качества соединения. Точной реализации пока нет, но думаю это сделать возможно в изоморфном стиле и совершенно не реально без него.
SSR — это не эволюция пререндера, это хорошо забытое старое. У меня как раз в презе было вступление на эту тему, где я рассказывал что вместо эволюционного развития веба, мы выбрали революционное — как только браузеры начали развиваться, все дружно кинулись на клиент, выкинув в пекло весь опыт серверной части. Это не правильно и именно изоморфность возвращает нас на эволюционный путь.
По поводу ваших доводов о SEO — они чисто субъективны. Кому-то может оказаться важнее поддерживать юзеров без JS, а кому-то просто ускорить загрузку. Вы говорите все это фигня и решается без SSR, я говорю что SEO также решается без SSR, а вы в ответ — «мне так нравится больше». Ну ок, тогда другие доводы также нравится больше и вообще зачем крутить кучу решений, если можно один раз крутануть изоморфность и сразу решить все проблемы.
По первым двум абзацам. На самом деле просто надо взвешивать все за и против на конкретном проекте. Сложно говорить об этом всём абстрактно.
Я просто хотел показать, что есть другая сторона, которая тоже имеет право на существование.
Идея с автопереключением SSR и SPA. Интересно, но оно того стоит? Можно просто рендерить на сервере всегда, так как это никому не приносит неудобств, кроме сервера. А если сервер начинает от этого уставать, то можно кешировать. Да и на самом деле мне кажется, что в перспективе SSR сравняется по производительности с обычными шаблонизаторами, ведь по сути задача его сводится к тому, чтобы получить данные и запихать их в разметку. А весь интерактив начинает свою работу уже на клиенте.
Про SSR — как ни крути, а это не то же самое, что мы делаем при построении старого доброго бэкенда с шаблонизаторами, jQuery и пр. Это всё равно развитие (= эволюция), то есть слияние всего того, что было хорошо в SPA с тем, что было хорошо в MPA. Плюс это развитие идеи пререндеринга просто потому, что SSR лучше пререндеринга почти во всём.
Про SEO — да, я признаю, что это субъективно. И да, SSR решает все проблемы разом, с этим я вообще не спорил.
Я просто хотел показать, что есть другая сторона, которая тоже имеет право на существование.
Идея с автопереключением SSR и SPA. Интересно, но оно того стоит? Можно просто рендерить на сервере всегда, так как это никому не приносит неудобств, кроме сервера. А если сервер начинает от этого уставать, то можно кешировать. Да и на самом деле мне кажется, что в перспективе SSR сравняется по производительности с обычными шаблонизаторами, ведь по сути задача его сводится к тому, чтобы получить данные и запихать их в разметку. А весь интерактив начинает свою работу уже на клиенте.
Про SSR — как ни крути, а это не то же самое, что мы делаем при построении старого доброго бэкенда с шаблонизаторами, jQuery и пр. Это всё равно развитие (= эволюция), то есть слияние всего того, что было хорошо в SPA с тем, что было хорошо в MPA. Плюс это развитие идеи пререндеринга просто потому, что SSR лучше пререндеринга почти во всём.
Про SEO — да, я признаю, что это субъективно. И да, SSR решает все проблемы разом, с этим я вообще не спорил.
По первым двум абзацам. На самом деле просто надо взвешивать все за и против на конкретном проекте. Сложно говорить об этом всём абстрактно.
Я просто хотел показать, что есть другая сторона, которая тоже имеет право на существование.
Другая? А чем она другая? Ну да, вебпак поддерживает code spliting? Но его можно и даже нужно использовать вместе с изоморфностью. Полноценным решение ни для Progressive Enhancement ни для повышения «accessibility» приложения оно не является.
Идея с автопереключением SSR и SPA. Интересно, но оно того стоит? Можно просто рендерить на сервере всегда, так как это никому не приносит неудобств, кроме сервера. А если сервер начинает от этого уставать, то можно кешировать.
Кажется я не совсем раскрыл кейс. Понимаете, ситуация всяких много. Вот вам реальный кейс из практики: есть 2 смарт тв — один старый, 12-го года, другой более-менее новый 15-го года. Оба из них подключены в wi-fi 100% времени (т.е. сеть работает стабильно и с хорошей скоростью). Делать SPA для второго ТВ вполне себе оправданное решение, потому что во-первых в его встроенном браузере уже нормальные движки JS/HTML/CSS. Во-вторых, там более-менее производительное железо.
Первый же телик слаб и движками, и железом. Поэтому дичайше тормозит просто от того, что рендарит шаблоны на клиенте. В таком случае выгоднее рендарить на сервере и получать полностью готовый html (ну или хотя бы куски HTML), сеть то прекрасная и стабильная. Даже с учетом накладных на сеть, SSR работает все равно быстрее. Что будем делать? Писать PHP приложения для второго сервера и специальный клиент для первого? Лишать первый возможностей SPA, потому что нужно поддерживать старые модели? Или все же запилим изоморфность?
Про SSR — как ни крути, а это не то же самое, что мы делаем при построении старого доброго бэкенда с шаблонизаторами, jQuery и пр.
А чем это не тоже самое? Тем что сейчас модно строить virtual dom? Ну личное имхо это даже хуже для сервера, но в целом просто деталь реализации. Изоморфность — да, это эволюция всех подходов, использование лучшего из обоих миров. А чисто SSR — это всего лишь то, что мы делали раньше, только на PHP. Вы же понимаете, что SSR != изоморфность?
Про SEO — да, я признаю, что это субъективно. И да, SSR решает все проблемы разом, с этим я вообще не спорил.
Да все субъективно, но лично я люблю решать все проблемы разом)))
Я о том, что просто нужно взвешивать целесообразность внедрения SSR с точки зрения трудозатрат. Чем сложнее проект и чем больше в нём legacy кода, тем больше человекочасов займёт внедрение SSR.
Про телевизор понял, нагдлядно.
Ну как минимум тем, что фронтенд и бэкенд не пересекаются и гораздо более явно разделены. Никто не «натягивает вёрстку», не переписывает стили под CMS/фреймворки, не решает проблем с SEO и т.д. и т.п. Каждый занят своим делом: фронтендщик — пишет стили, разметку и интерактив, бэкендщик — создаёт бизнес-логику и API для неё. Изоморфность же достигается сама собой благодаря одному человеку, который один раз настроил сборку и сервер для SSR, а также разъяснил немногочисленные особенности разработки фронтендщикам. У меня этого достичь с одним лишь PHP на сервере не получалось :)
SSR != изоморфность, но SSR — инструмент, позволяющий достичь изоморфности.
Про телевизор понял, нагдлядно.
А чем это не тоже самое?
Ну как минимум тем, что фронтенд и бэкенд не пересекаются и гораздо более явно разделены. Никто не «натягивает вёрстку», не переписывает стили под CMS/фреймворки, не решает проблем с SEO и т.д. и т.п. Каждый занят своим делом: фронтендщик — пишет стили, разметку и интерактив, бэкендщик — создаёт бизнес-логику и API для неё. Изоморфность же достигается сама собой благодаря одному человеку, который один раз настроил сборку и сервер для SSR, а также разъяснил немногочисленные особенности разработки фронтендщикам. У меня этого достичь с одним лишь PHP на сервере не получалось :)
SSR != изоморфность, но SSR — инструмент, позволяющий достичь изоморфности.
Я о том, что просто нужно взвешивать целесообразность внедрения SSR с точки зрения трудозатрат. Чем сложнее проект и чем больше в нём legacy кода, тем больше человекочасов займёт внедрение SSR.
Как я и говорил ранее, изоморфность можно крутить постепенно. Шаг за шагом. Первое приложение, которое я перевел только на изоморфный SSR, вообще без других аспектов изоморфности, было еще в те времена, когда только nodejitsu о ней и говорили. Это был обычный сайт на PHP, который сперва умел рендарить шаблоны сам, потому части шаблонов этого бекенда (например список с фильтрами) перекочевали на ajax и рендаринг на клиент с помощью «усов». Потом нода продвинулась, стала более-менее рабочей и мы ее поставили вперед (frontend server), перенесли все шаблоны в «усы», а из PHP сделали чисто апи (частично оно уже было, потому что частично рендаринг был на клиенте). Вот так мы с минимальными затратами втащили в крайне legacy проект частичку изоморфности. Без реактов, вуев, ангулятов, юзая просто изоморфный шаблонизатор. Можно было бы и даальше по-тихоньку наворачивать, но не было нужды для этого проекта.
Ну как минимум тем, что фронтенд и бэкенд не пересекаются и гораздо более явно разделены.
Это смотря как написан ваш код. У нас и до начала использования ноды активно юзалась 3-х звенная архитектура, с обязательными frontend и backend серверами. Например одна из моих любимых конфигураций того времени — бэк-сервер на C/C++ (чистый апи поверх базы и elasticsearch) и фронт-сервер на PHP (в том время он давал наиболее простой способ шаблонизации на сервере). Сейчас у нас примерно такой же бекенд, только на Go или C/C++, ну или на кройняк PHP/Python. Дальше фронтом стоит NodeJS + ну и прибавился полноценный SPA на клиенте. Так что как можете заметить отличий не так много, просто прибавился толстый клиент. Это и есть эволюция. А то, что сейчас подают под соусом SSR — это когда толпа радостных фронтендщиков сначала дружно ломанулись на клиент и начали хренячить SPA и во все стороны орать «backendless»!!! Потом начали делать пререндер, в качестве костыля под SPA. А потом вдруг вспомнили, что можно и на сервере, что то делать и даже быстрее. Поэтому для них это все «эволюция пререндера после революции веба», а для меня это просто «эволюция веба, после ошибкок молодости (SPA)».
Ха-ха, ну вы уже давно как матёрый разработчик)
У меня такой опыт мог бы сложиться, родись я хотя бы на пару лет пораньше. Нода появилась чуть раньше того момента, когда я нашёл первую работу по специальности) А вместе с ней пошли-поехали сборщики, фреймворки, пререндеринги и т.д.
Хотя с усами без ангуляров, реактов и вуёв я тоже экспериментировал, но исключительно на клиенте. Сейчас, конечно, всё это не особо актуально.
А сервера на C/C++ я вообще вживую ни разу не видел. Слышал только, что до появления PHP только на них и писали.
А так да, я понимаю, что были и раньше способы. Но сейчас они становятся «народными» и большее количество людей начинает их использовать.
У меня такой опыт мог бы сложиться, родись я хотя бы на пару лет пораньше. Нода появилась чуть раньше того момента, когда я нашёл первую работу по специальности) А вместе с ней пошли-поехали сборщики, фреймворки, пререндеринги и т.д.
Хотя с усами без ангуляров, реактов и вуёв я тоже экспериментировал, но исключительно на клиенте. Сейчас, конечно, всё это не особо актуально.
А сервера на C/C++ я вообще вживую ни разу не видел. Слышал только, что до появления PHP только на них и писали.
А так да, я понимаю, что были и раньше способы. Но сейчас они становятся «народными» и большее количество людей начинает их использовать.
Ха-ха, ну вы уже давно как матёрый разработчик)
Ну я далеко не самый древний старпер здесь, но 10+ лет профстажа то есть конечно.
А сервера на C/C++ я вообще вживую ни разу не видел. Слышал только, что до появления PHP только на них и писали.
Да это и сейчас актуально. Далеко не все написано на PHP, а до этого писалось на C/C++. Есть полно серверов на Java/.Net и тп. Да и до PHP как бы Perl был в угаре из ему подобных. Вообще на интерпретируемых языках писать многие типы серверов — это смерти подобно, ну либо потом костыли крутить типа HipHop. Сейчас лично мне кажется весьма перспективным Go.
А так да, я понимаю, что были и раньше способы. Но сейчас они становятся «народными» и большее количество людей начинает их использовать.
Статистики не имею, но прям чтоб «народными» есть все же сомнения. К сожалению, изоморфность в том числе — почему-то для многих это капец как сложным кажется.
Не так ветка, сорян.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Server side rendering на Vue.js