SSR - это жёсткая необоходимость. я сам пришу на всем, включая Blazor, VS2019, SSR - это единственный выход в БЫСТРЫЙ мобильный интернет, а это до 50% всех подключений к 2020 году. Про дектопы как 80% потребителя трафика можете забыть, теперь будет 50%. Неважно у вас Xiaome Mi9 Explorer Edition, уронить браузер даже с 12 Гб оперативки можно легко по производительности без SSR даже на средних и малых сайтах, при достаточной криворукости программистов
Маленькая поправка, разница между SSR и CSR это только первый ответ, то есть несмотря на то что клиент получил HTML, он все равно опять собирается. Точнее валидирует. А по скорости, в режиме SSR отображение сайта у пользователя будет быстрее. Сайт Реакта построен на SSR, сайт ангуляра на CSR, можете сами ощутить разницу.
Использую второй подход, но в монолите, с рендерингом всего сразу на сервере (не нода), а затем оживлением через Vue. Всё хорошо, минус только в поддержке двух шаблонов: один для сервера, другой для Vue.
Илья, подскажи, как лучше? Чтобы каждый компонент сам тянул данные с API? В этом случае будет много запросов. Или один HOC сразу тянет все данные одним запросом для всех своих "детей"? Это как бы аналог контроллера, которые собирает все данные и отдаёт разом для view в MVC модели. Или всё зависит от ситуации? В случае с SSR получается, что сервер должен сделать кучу внешних сетевых запросов (даже самому себе), чтобы отрисовать страницу. А это очень больно.
"Лучше" для кого? Конечно с точки зрения архитектуры фронта лучше когда каждый компонент самодостаточный. В этом плане хорош graphql, который решает эту проблему на корню
@@JavaScriptNinja не совсем понял, о чём ты имеешь в виду. Но я понял другое правило: не слушай никого, слушай свой мозг и принимай решения по ситуации.
А как называется, если вёрстку создать на сервере и заполнить минимальными данными. Затем вернуть клиенту и после JS передать с сервера данные для заполнения? Допустим JSON-ом
Мне кажется, что это не вполне SSR, а скорее agile SSR, SSR + CSR, или даже CSR (даже, упрщенно, чистый html + ajax), но с элементами SSR (шаблоны HTML). однако, вы не упомянули такую важну часть, как routing, причем, он должен работать как с включенным JS на клиенте, так и без, то есть реализация механизма Routing для сервера и клиента, а так же, как следствие, реализация History, да всего в принципе, может быть очень сложной, надо было об этом упомянуть, что реализуя ЛЮБУЮ гибридную схему, кроме чистого SSR, и чистого CSR, когда сервер stateful, а ваш клиент имеет минимально возможный state, сьезжая на stateless, вы просто сразу же упретесь в то, как именно реализовать history, routing и даже store, чтобы он работал в такой гибридной схеме более менее адекватно. Причем, с чистым CSR, и чистым SSR, все более менее понятно, нет никакого дуализма, что где хранить и что где обрабатывать, но как только вы переходите рубикон, вам просто колом в попу втыкается вопрос синхронизации контекста клиента и контекста сервера. А накладывая на все это проблему браузерной реализации, вы получаете реальную картину мира, что создать универсальное решение в разумные сроки не под силу никому, и все просто берут первый попвшийся vue + nuxt, react + redux и молятся программерскому двоичному Богу, чтобы в будущем ничего не поломалось, не изменилось, и работало как надо. Имено поэтому на большинстве Angular сайтов, с выключенным JS (я использую NoScript плагин), да и на большинстве совеременных сайтов, вы почти гарантированно увидите просто чистый лист HTML5 blank template. Потому что SSR - это сложно. Но не само по себе, а в сочетании с AJAX, WebComponents, JS и динамической загрузкой.
Когда научатся поисковики работать с js, тогда и будем юзать клиент сайд рендернинг со всякими vuями и реактами. А пока не извращаемся и юзаем нормальный html и jquery)
@@PavelAShvedov Хороший план. Можно в фотошопе нарезать макет и сохранить в html. Потом перелинковку настроил, получился симпатичный сайт. Грузится быстро, поисковики его любят. Будет лампово и статичненько.
Vue ssr? Зачем? Нужен seo -- берите laravel + vanillajs. Не нужен вам vue. У вас state нет на клиенте... Да и все эти ssr ужасные костыли в плане производительности.
А если вебсокеты надо использовать? А если надо асинхронность движка v8? Эх.... Пхп как язык изначально был костыль для слаборазвитых выпендрежников, которые скопировав говнокод, кричали всем вокруг какие они крутые прогеры хакеры. Ненавижу пхпшников, буду травить их, пока все не вымрут.
Очень полезно и интересно!
О наконец-то понял, что это такое и для чего реально оно нужно
Было интересно и полезно. Спасибо)
Благодарю!
Спасибо. По seo ещё нужно было пробежаться, какие решения можно применить
Белиссимо!
SSR - это жёсткая необоходимость. я сам пришу на всем, включая Blazor, VS2019, SSR - это единственный выход в БЫСТРЫЙ мобильный интернет, а это до 50% всех подключений к 2020 году. Про дектопы как 80% потребителя трафика можете забыть, теперь будет 50%. Неважно у вас Xiaome Mi9 Explorer Edition, уронить браузер даже с 12 Гб оперативки можно легко по производительности без SSR даже на средних и малых сайтах, при достаточной криворукости программистов
2 недели не мог решить, как именно писать приложение на Vue. Наконец определился. Спасибо, очень полезно.
Определились? Что практика/опыт показал?
Спасибо.
раз два три) как там у вас?
познавательно. спасибо!
Красавчик! Крутой видос, спасибо)
Спасибо большое за информацию. Подскажите пожалуйста а как совмещается роутинг на сервере с роутингом на реакте
Маленькая поправка, разница между SSR и CSR это только первый ответ, то есть несмотря на то что клиент получил HTML, он все равно опять собирается.
Точнее валидирует.
А по скорости, в режиме SSR отображение сайта у пользователя будет быстрее.
Сайт Реакта построен на SSR, сайт ангуляра на CSR, можете сами ощутить разницу.
Всё же ожидал услышать что то умное про SSR :(
Использую второй подход, но в монолите, с рендерингом всего сразу на сервере (не нода), а затем оживлением через Vue. Всё хорошо, минус только в поддержке двух шаблонов: один для сервера, другой для Vue.
А что вместо ноды, если не секрет?
Tak chto vibiraty next ili react/vue +php?
Илья, подскажи, как лучше? Чтобы каждый компонент сам тянул данные с API? В этом случае будет много запросов. Или один HOC сразу тянет все данные одним запросом для всех своих "детей"? Это как бы аналог контроллера, которые собирает все данные и отдаёт разом для view в MVC модели. Или всё зависит от ситуации? В случае с SSR получается, что сервер должен сделать кучу внешних сетевых запросов (даже самому себе), чтобы отрисовать страницу. А это очень больно.
"Лучше" для кого? Конечно с точки зрения архитектуры фронта лучше когда каждый компонент самодостаточный. В этом плане хорош graphql, который решает эту проблему на корню
@@JavaScriptNinja не совсем понял, о чём ты имеешь в виду. Но я понял другое правило: не слушай никого, слушай свой мозг и принимай решения по ситуации.
@@RagazzoKZ ну так зачем спрашивать , если ты понял другое правило ?!
сложно как то представить реализацию такой штуки
Спс
А как называется, если вёрстку создать на сервере и заполнить минимальными данными. Затем вернуть клиенту и после JS передать с сервера данные для заполнения? Допустим JSON-ом
Это боль
Как понимать - клиент может в http2?
nuxt сам по себе - плохой или хороший выбор?
Мне nuxt не нравится. Но это лучшее из того, что есть
Nuxt очень удобный для разработки.
Даже если вам не нужен SSR, в Nuxt есть много ништяков.
Мне кажется, что это не вполне SSR, а скорее agile SSR, SSR + CSR, или даже CSR (даже, упрщенно, чистый html + ajax), но с элементами SSR (шаблоны HTML). однако, вы не упомянули такую важну часть, как routing, причем, он должен работать как с включенным JS на клиенте, так и без, то есть реализация механизма Routing для сервера и клиента, а так же, как следствие, реализация History, да всего в принципе, может быть очень сложной, надо было об этом упомянуть, что реализуя ЛЮБУЮ гибридную схему, кроме чистого SSR, и чистого CSR, когда сервер stateful, а ваш клиент имеет минимально возможный state, сьезжая на stateless, вы просто сразу же упретесь в то, как именно реализовать history, routing и даже store, чтобы он работал в такой гибридной схеме более менее адекватно. Причем, с чистым CSR, и чистым SSR, все более менее понятно, нет никакого дуализма, что где хранить и что где обрабатывать, но как только вы переходите рубикон, вам просто колом в попу втыкается вопрос синхронизации контекста клиента и контекста сервера. А накладывая на все это проблему браузерной реализации, вы получаете реальную картину мира, что создать универсальное решение в разумные сроки не под силу никому, и все просто берут первый попвшийся vue + nuxt, react + redux и молятся программерскому двоичному Богу, чтобы в будущем ничего не поломалось, не изменилось, и работало как надо. Имено поэтому на большинстве Angular сайтов, с выключенным JS (я использую NoScript плагин), да и на большинстве совеременных сайтов, вы почти гарантированно увидите просто чистый лист HTML5 blank template. Потому что SSR - это сложно. Но не само по себе, а в сочетании с AJAX, WebComponents, JS и динамической загрузкой.
Это все хорошо, только для чего отключать JS? "причем, он должен работать как с включенным JS на клиенте, так и без" почему он так должен работать?
Норм... но засул во время просмотра..........
Когда научатся поисковики работать с js, тогда и будем юзать клиент сайд рендернинг со всякими vuями и реактами. А пока не извращаемся и юзаем нормальный html и jquery)
да нафиг jquery? делали нормальные сайты и до него, просто куча статичных html на все случаи жизни, с версткой на таблицах
Мда
@@PavelAShvedov Хороший план. Можно в фотошопе нарезать макет и сохранить в html. Потом перелинковку настроил, получился симпатичный сайт. Грузится быстро, поисковики его любят. Будет лампово и статичненько.
Вот и девелопер адвокаты jQuery подтянулись))
@@okke00 с "девелопер адвокатов жквери" в голосяру))
Vue ssr? Зачем? Нужен seo -- берите laravel + vanillajs. Не нужен вам vue. У вас state нет на клиенте...
Да и все эти ssr ужасные костыли в плане производительности.
ну если сделать пререндер странички , то производительность норм. Тот же next js с его getStaticProps
Нода на бекенде так себе идея изначально
Так а что иначе? PHP?
java, python, c# тоже
А если вебсокеты надо использовать? А если надо асинхронность движка v8? Эх.... Пхп как язык изначально был костыль для слаборазвитых выпендрежников, которые скопировав говнокод, кричали всем вокруг какие они крутые прогеры хакеры. Ненавижу пхпшников, буду травить их, пока все не вымрут.
@@user-yr8lr8vo7n я не топлю за php. А что, веб-сокеты только js поддерживает?
с чего ты это взял?