Уточнение: google хоть и умеет в js, тем не менее новые страницы открывает всегда по ссылке, так же как и yandex. Так же всегда остается проблема социальных сетей, которые ничего не знают про js, но, как правильно замечено, Nuxt с легкостью справляется со всеми seo вопросами.
Расскажу про свой опыт.
Back и front на одном сервере, back кешируют запросы в редис, с ключами типа '/product/123', потом оба проверяют по такому ключу. Статика отдается через nginx, Для большинства компонентов используется lru-cache. Параллельно работает несколько Nuxt инстансев, для разных подпроектов. pm2 используется по простому: pm2 start npm --name «myapp» — run myapp. Так же используем analyze, многие модули грузим через ajax по запросу пользователя. Поэтому текущий общий начальный бандл сократили примерно до 200kb в gzip. При этом функционала и кастомных контролов в проекте достаточно много. Единственное с чем до сих про не разобрался (руки не дошли) это деплой без простоев. Когда билдится новая версия, новые страницы не открываются. Около 50 секунд, для нас не критично, так как главные страницы пока отдаются не через nuxt, когда их переведем придется заморочится. Проект в продакшене около года.
Спасибо за ваш ответ, все по существу.
Единственное что можно добавить про зависимости, то что это необходимое зло. Мне их было тяжело принять в целом в Node.js. Но как ни крути точно такая же картина например в java и php со своими менеджерами пакетов и кучей зависимостей.
А насчет фреймворков всегда будут «ленивые» люди которые их просто используют как есть и ищут ответы на stackoverflow, и всегда будут люди которые будут копаться в исходниках и доках чтобы понять что за инструмент он использует. И это нормально и первый, и второй может быть хорошим специалистом по задачам которые он решает. Разный уровень подкованности, разные задачи, разная оплата труда. Каждый сам выбирает свой путь. Толковый opensource фреймворк как ни крути, не окажется хуже велосипеда, который поддерживает только один человек, а не целое комьюнити.
Очень жаль что из-за подобный комментов в обоих статьях такой замечательный фреймворк проходит мимо хабрасообщества.
1. Новая абстракция
Его главная фича это серверный рендеринг, с каких пор люди ожидают что это не будет отдельным слоем абстракции? Если есть хоть один способ рендерить интерактивный js на сервере без новой абстракции, покажите мне его, я забуду про все эти потуги защищать vue и nuxt.
2. Webpack
Установив vue-webpack из vue-cli мы тоже получим готовый webpack конфиг, который не то чтобы самый простой, но в нем уже сделано почти все что может понадобиться. И мне тоже было старшно его использовать не разобравшись что там происходит. Что я сделал? Открыл конфиг и изучил его. Меня все устроило, только добавил плагин для svg. Чем это отличается от Nuxt? Установил, в этот раз зашел не в конфиг, а в node_modules, изучил там практически такой же конфиг и остался доволен. В проекте можно легко сделать extend и добавить все нужные параметры, я так же добавил плагин для svg и вырезал все лишнее из moment.js
3. Борьба с инструментом
Это будет всегда, какой бы вы фреймворк не взяли, всегда будут задачи которые не удобно на нем выполнять, тогда мы будем вспоминать фреймворк Х и думать что там это было проще.
4. Тонна зависимостей и фотошоп.
У меня создалось впечатление что вы решили, что Nuxt за вас приложение будет создавать, но он практически ничем не отличается от чистого Vue кроме фич для рендеринга, которые созданы по гайдам самого же Vue. Единственное что сразу бросается в глаза это автоматический роутинг по структуре папок и файлов и более продуманные middlewares, неужели это предвестиники фотошопа для сайтов?
Вопрос с зависимостями меня ставит в тупик, это же фреймворк для серверного рендеринга, он выполняется на сервере, настраивает роутинг и т.д. Мы же не удивляемся почему так много зависимостей у Express или любого другого nodejs серверного фреймворка, почему же так боимся зависимостей Nuxt? Уверяю вас, ничего из этого не попадет в ваш браузерный билд, он будет почти таким же крошечным как у самого Vue.
Повторюсь, главная фича это серверный рендеринг. Это не очередной новый фреймворк вокруг которого начнется необоснованный хайп и появится куча статей на медиуме с заголовками типа «Как я перешел с React на Nuxt». Это всего лишь минималистичная надстройка, которая решает конкретную проблему, не добавляя при этом не обоснованной магии.
Это не совсем так. Проблема существует давно, с тех пор как интеркативный js захотелось отдавать в google и остальным роботам, которые не умеют в js. Есть множество способов решения данной проблемы:
1. Начиналось все с извращений типа двух вариантов страниц для кравлера и пользователя, это просто за гранью добра и зла, создавать все по два раза.
2. Потом придумали пререндерить все это на сервере с помощью selenium/phantomjs и других. В этом также есть огромное кол-во подводных камней. Лично для меня главный из них это необходимость вести двойную разработку, сначала делаем фичу, потом учим эту фичу работать с серверным рендером. Бывает это не так сложно, но всегда нужно помнить про лишний слой разработки, который не нужен конечному пользователю, но необходим кравлерам. Помимо прочего все сильно усложняется на проектах где может быть 100 000+ страниц.
3. Со временем к этому подтянулись и frontend фреймворки. Сейчас и Angular, и React, и Vue поддерживают серверный рендеринг. И это сильно упрощает работу в целом, программист просто пишет код, а он просто рендерится на сервере, как будто это обычные шаблоны jsp или php.
Думаю не стоит объяснять насколько больше оверхеда в первых двух вариантах по сравнениею с третьим.
Так вот Nuxt не придумывает ничего, он просто за вас настраивает серверный рендеринг по гайдам Vue и добавляет парочку полезных плюшек. Поддерживать его сервер не составляет никакого труда. Если вся логика будет у вас на api сервере, то все что будет делать front server — это отдача статики.
Опять же он решает конкретную проблему, которая существует очень давно. Если вам необходимо интерактивное приложение, которое смогут «увидеть» кравлеры, то Nuxt вам в это поможет. Если в этом нет необходимости, то просто проходите мимо, этот инструмент не для вас.
Вот с этим к сожалению пока нет опыта, работа идет в основном в направлении сложных интерактивных админок или аппов, поэтому тему мобильных приложений мы еще не поднимали.
Этим мне и понравился Nuxt. У Vue замечательные гайды, в том числе по ssr, и Nuxt полностью им следуют. В первую очередь я его рассматриваю как один из готовых vue-cli темплейтов (хоть это и не так), в котором тебе не требуется заного настраивать ssr по всем канонам в каждом новом проекте. Сам Nuxt активно использует все возможности Vue, практически не добавляя магии. Разработка идет так же на чистом js и это мне нравится больше всего, особенно после перехода с Angular.
Фактически все что реализует Nuxt.js можно реализовать на Vue.js, серверный рендеринг у них очень продуман. Но Nuxt.js позволяет получить все это из коробки:
1.Браузер/Google и все остальные получают готовый статичный html, в котором все данные уже загружены и отренедерены. После загрузки страницы сайт ведет себя дальше как SPA.
2. Уже сконфигурированный webpack. Бандлы для вендоров, приложения и отдельных страниц, загружаемых через prefetch
3. Простой роутинг на базе структуры папок и файлов.
4. Набор модулей типа pwa, axios, firebase, в которых многое сделано за вас: github.com/nuxt-community/modules
Уточню в чем конкретное отличие от рендеринга php/python/ruby/etc. Единая кодовая база, не нужно писать какой-то отдельный рендер для SPA или интерактивных сайтов, не нужно придумывать отдельно серверные шаблоны и отдельно js шаблоны для интерактива, чтобы как-то пофиксить SEO. Это просто работает. И самое главное не только для гугла, ведь не всем нужен SEO для SPA. Это работает везде. Можно шарить в google+ и facebook и это будет работать без каких-либо телодвижений.
Еще более важное уточнение для скептиков js. Это не замена вашего backend. По сути это прослойка между backend и frontend. Nuxt.js можно прикрутить напрямую к express/koa и другим node фреймворкам, либо запрашивать данные из любого другого бекенда.
Пример как это работает в реальной жизни:
1. api сервер на php, авторизует юзеров, выдает данные и т.д.
2. front сервер на express+nuxt.js запрашиват данные из api сервера, рендерит страницы, отдает пользователю.
Сделав 2 проекта на Nuxt.js, очень нехватает его плюшек на чистом Vue.js. Хотя и без них прожить можно. Особенно если вы уверены что вам точно не потребуется серверный рендеринг.
Back и front на одном сервере, back кешируют запросы в редис, с ключами типа '/product/123', потом оба проверяют по такому ключу. Статика отдается через nginx, Для большинства компонентов используется lru-cache. Параллельно работает несколько Nuxt инстансев, для разных подпроектов. pm2 используется по простому: pm2 start npm --name «myapp» — run myapp. Так же используем analyze, многие модули грузим через ajax по запросу пользователя. Поэтому текущий общий начальный бандл сократили примерно до 200kb в gzip. При этом функционала и кастомных контролов в проекте достаточно много. Единственное с чем до сих про не разобрался (руки не дошли) это деплой без простоев. Когда билдится новая версия, новые страницы не открываются. Около 50 секунд, для нас не критично, так как главные страницы пока отдаются не через nuxt, когда их переведем придется заморочится. Проект в продакшене около года.
Единственное что можно добавить про зависимости, то что это необходимое зло. Мне их было тяжело принять в целом в Node.js. Но как ни крути точно такая же картина например в java и php со своими менеджерами пакетов и кучей зависимостей.
А насчет фреймворков всегда будут «ленивые» люди которые их просто используют как есть и ищут ответы на stackoverflow, и всегда будут люди которые будут копаться в исходниках и доках чтобы понять что за инструмент он использует. И это нормально и первый, и второй может быть хорошим специалистом по задачам которые он решает. Разный уровень подкованности, разные задачи, разная оплата труда. Каждый сам выбирает свой путь. Толковый opensource фреймворк как ни крути, не окажется хуже велосипеда, который поддерживает только один человек, а не целое комьюнити.
1. Новая абстракция
Его главная фича это серверный рендеринг, с каких пор люди ожидают что это не будет отдельным слоем абстракции? Если есть хоть один способ рендерить интерактивный js на сервере без новой абстракции, покажите мне его, я забуду про все эти потуги защищать vue и nuxt.
2. Webpack
Установив vue-webpack из vue-cli мы тоже получим готовый webpack конфиг, который не то чтобы самый простой, но в нем уже сделано почти все что может понадобиться. И мне тоже было старшно его использовать не разобравшись что там происходит. Что я сделал? Открыл конфиг и изучил его. Меня все устроило, только добавил плагин для svg. Чем это отличается от Nuxt? Установил, в этот раз зашел не в конфиг, а в node_modules, изучил там практически такой же конфиг и остался доволен. В проекте можно легко сделать extend и добавить все нужные параметры, я так же добавил плагин для svg и вырезал все лишнее из moment.js
3. Борьба с инструментом
Это будет всегда, какой бы вы фреймворк не взяли, всегда будут задачи которые не удобно на нем выполнять, тогда мы будем вспоминать фреймворк Х и думать что там это было проще.
4. Тонна зависимостей и фотошоп.
У меня создалось впечатление что вы решили, что Nuxt за вас приложение будет создавать, но он практически ничем не отличается от чистого Vue кроме фич для рендеринга, которые созданы по гайдам самого же Vue. Единственное что сразу бросается в глаза это автоматический роутинг по структуре папок и файлов и более продуманные middlewares, неужели это предвестиники фотошопа для сайтов?
Вопрос с зависимостями меня ставит в тупик, это же фреймворк для серверного рендеринга, он выполняется на сервере, настраивает роутинг и т.д. Мы же не удивляемся почему так много зависимостей у Express или любого другого nodejs серверного фреймворка, почему же так боимся зависимостей Nuxt? Уверяю вас, ничего из этого не попадет в ваш браузерный билд, он будет почти таким же крошечным как у самого Vue.
Повторюсь, главная фича это серверный рендеринг. Это не очередной новый фреймворк вокруг которого начнется необоснованный хайп и появится куча статей на медиуме с заголовками типа «Как я перешел с React на Nuxt». Это всего лишь минималистичная надстройка, которая решает конкретную проблему, не добавляя при этом не обоснованной магии.
1. Начиналось все с извращений типа двух вариантов страниц для кравлера и пользователя, это просто за гранью добра и зла, создавать все по два раза.
2. Потом придумали пререндерить все это на сервере с помощью selenium/phantomjs и других. В этом также есть огромное кол-во подводных камней. Лично для меня главный из них это необходимость вести двойную разработку, сначала делаем фичу, потом учим эту фичу работать с серверным рендером. Бывает это не так сложно, но всегда нужно помнить про лишний слой разработки, который не нужен конечному пользователю, но необходим кравлерам. Помимо прочего все сильно усложняется на проектах где может быть 100 000+ страниц.
3. Со временем к этому подтянулись и frontend фреймворки. Сейчас и Angular, и React, и Vue поддерживают серверный рендеринг. И это сильно упрощает работу в целом, программист просто пишет код, а он просто рендерится на сервере, как будто это обычные шаблоны jsp или php.
Думаю не стоит объяснять насколько больше оверхеда в первых двух вариантах по сравнениею с третьим.
Так вот Nuxt не придумывает ничего, он просто за вас настраивает серверный рендеринг по гайдам Vue и добавляет парочку полезных плюшек. Поддерживать его сервер не составляет никакого труда. Если вся логика будет у вас на api сервере, то все что будет делать front server — это отдача статики.
Опять же он решает конкретную проблему, которая существует очень давно. Если вам необходимо интерактивное приложение, которое смогут «увидеть» кравлеры, то Nuxt вам в это поможет. Если в этом нет необходимости, то просто проходите мимо, этот инструмент не для вас.
1.Браузер/Google и все остальные получают готовый статичный html, в котором все данные уже загружены и отренедерены. После загрузки страницы сайт ведет себя дальше как SPA.
2. Уже сконфигурированный webpack. Бандлы для вендоров, приложения и отдельных страниц, загружаемых через prefetch
3. Простой роутинг на базе структуры папок и файлов.
4. Набор модулей типа pwa, axios, firebase, в которых многое сделано за вас: github.com/nuxt-community/modules
Уточню в чем конкретное отличие от рендеринга php/python/ruby/etc. Единая кодовая база, не нужно писать какой-то отдельный рендер для SPA или интерактивных сайтов, не нужно придумывать отдельно серверные шаблоны и отдельно js шаблоны для интерактива, чтобы как-то пофиксить SEO. Это просто работает. И самое главное не только для гугла, ведь не всем нужен SEO для SPA. Это работает везде. Можно шарить в google+ и facebook и это будет работать без каких-либо телодвижений.
Еще более важное уточнение для скептиков js. Это не замена вашего backend. По сути это прослойка между backend и frontend. Nuxt.js можно прикрутить напрямую к express/koa и другим node фреймворкам, либо запрашивать данные из любого другого бекенда.
Пример как это работает в реальной жизни:
1. api сервер на php, авторизует юзеров, выдает данные и т.д.
2. front сервер на express+nuxt.js запрашиват данные из api сервера, рендерит страницы, отдает пользователю.
Сделав 2 проекта на Nuxt.js, очень нехватает его плюшек на чистом Vue.js. Хотя и без них прожить можно. Особенно если вы уверены что вам точно не потребуется серверный рендеринг.