Comments 11
На данный момент решаю ту же проблему, но bundleRenderer'ы поместил в отдельные воркеры, чтобы по максимуму использовать ресурсы сервера
Большое спасибо, как раз планирую отказаться от nuxt из-за отсутствия гибкости. Одно не понимаю: почему vue-cli не поддерживает создание универсальных приложений официально?
Я рад, если статья помогла.
Насчет отсутствия такой поддержки у vue-cli, мне кажется обычно все равно каждый настраивает экосистему под себя. Тут нет какого-то универсального решения.
А для обычных случаев есть Nuxt.js
Насчет отсутствия такой поддержки у vue-cli, мне кажется обычно все равно каждый настраивает экосистему под себя. Тут нет какого-то универсального решения.
А для обычных случаев есть Nuxt.js
Nuxt немного сложноват и добавляет некоторые не нужные лично мне вещи. Попробую сделать вариант из статьи, только отдать конфигурирование webpack vue-cli. Есть пара примеров на гитхабе как это сделать. Мне кажется что vue-cli намного проще использовать, так как в случае необходимости можно легко изменить настройки webpack как угодно, зато не надо писать много конфигурации для него. Так же у vue-cli хорошая документация и официальная поддержка.
А не прокомментируете какая гибкость отсутствует в Nuxt? Давно его использую, но вот как то все не могу поймать за отсутсвие гибкости, это без сарказма, если что.
Вполне вероятно, что Nuxt подойдет для большинства вещей. Я использовал Next с React в одном небольшом приложении, в целом ок, но приходилось многие вещи кастомизировать, и я посчитал, что в разросшемся проекте эти кастомизации будут приносить боль.
Я не знаком с Nuxt, пример привести не смогу, но по моему мнению любые высокоуровневые решения налагают свои ограничения и диктуют свои правила построения приложения. Я хочу иметь свободу в этом плане, не хочу завязываться на еще один фреймворк, который к тому же придется изучать и набивать шишки.
Я не знаком с Nuxt, пример привести не смогу, но по моему мнению любые высокоуровневые решения налагают свои ограничения и диктуют свои правила построения приложения. Я хочу иметь свободу в этом плане, не хочу завязываться на еще один фреймворк, который к тому же придется изучать и набивать шишки.
но приходилось многие вещи кастомизировать
Можно подробнее, какие именно вещи приходилось кастомизировать? Все что вы описали в статье, Nuxt.js может из коробки, будучи являясь частью экосистемы Vue. Сейчас это выглядит как «мне было лень изучать Nuxt, т.к. в Next'e я столкнулся с такими-то трудностями, поэтому напишу-ка я сразу свой велосипед»
не хочу завязываться на еще один фреймворк, который к тому же придется изучать и набивать шишки
А то, что в вашем случае придется изучать Node.js, Express, чтобы все это запустить – то это ок
Позвольте полюбопытствовать, а какую проблему у вас решает SSR?
Две основные задачи: это отдать контент пользователю как можно быстрее (без SSR придется ждать пока загрузятся скрипты) и для SEO оптимизации (есть мнение, что сейчас поисковики умеют адекватно работать с сайтами, которые рисуются только на клиенте, но я на это не надеюсь)
Ещё один плюс ssr, неочевидный: иногда нужно получить какие-то данные с сервера, вроде имени залогиненого пользователя или ещё какие-то динамические данные. В случае с обычным SPA придётся ещё и после загрузки скриптов сделать как минимум один запрос. В случае с ssr эти данные можно отдать сразу со статикой, что делает решение очень быстрым. Так как SPA приложение загружается только один раз (статика), то нагрузка в теории не сильно должна повышаться.
есть мнение, что сейчас поисковики умеют адекватно работать с сайтами, которые рисуются только на клиентеПроводились тесты, которые показывают, что реактивные странички парсятся вполне корректно при условии, что данные прилетают быстро, так как у поискового робота на каждый ресурс есть свой бюджет. Оно и логично, Google теперь использует последнюю версию хрома для парсинга. По поводу остальных поисковиков не уверен, не видел тестов.
Sign up to leave a comment.
Как я сделал удобной разработку на Vue.js с server-side рендерингом