Comments 20
К великому сожалению, ваша статья ничем не отличается от общедоступного руководства по nuxt / vue ssr.
Повторюсь. Интересны примеры кода для решения конкретных задач. Тесты при нагрузке, проблемы и их решения.
Складывается ощущение, что все кто так или иначе связан с vue не хочется или не может делится информацией.
Повторюсь. Интересны примеры кода для решения конкретных задач. Тесты при нагрузке, проблемы и их решения.
Складывается ощущение, что все кто так или иначе связан с vue не хочется или не может делится информацией.
Так понял, что Nuxt.js изначально направлен на работу с vue.js.
Вы активно используете vue.js? И используете ли у себя Angular и React с кучей навесного?
Вы активно используете vue.js? И используете ли у себя Angular и React с кучей навесного?
Из статьи появилось ощущение, что под SSR автор имеет ввиду генерацию статических страниц? Есть ли поддержка собственно универсальных/изоморфных приложений?
Изоморфная — это же статическая, которая на клиенте с помощью дегидрации оживает? Или нет?
Есть два варианта:
- нарендерить кучу html страниц при сборке, задеплоить их куда-то
- поднять сервер, который рендерит страницу на сервере под запрос конкретного пользователя
Вы какой из них используете?
Nuxtjs может и то, и то: generate, middleware, nuxtjs.org/api/nuxt
Мы используем кучу HTML страниц, так как это решает вопрос «быстро показать прототип»
Мы используем кучу HTML страниц, так как это решает вопрос «быстро показать прототип»
Решил я попробовать этот Накст, тем более сам Эван Ю его очень советует. Установив его и начав разбираться, я понял, что мне нужно изучить ещё один уровень абстракции. Да в нём даже исходный вебпак конфиг зарыт в зависимостях. И тут я подумал — а куда мы вообще двигаемся? Теперь не зная и не понимая самого языка можно написать приложение, но стоит копнуть чуть глубже и что? В итоге начинаешь изучать как написан инструмент (а ещё хуже «бороться с ним»), вместо того, чтобы решать реальные задачи.
Я когда-то давно ставил под вопрос использование самих фреймворков. Теперь же, когда они достигли хорошей производительности и удобных интерфейсов, этот вопрос отпал. Но использовать двойную абстракцию с тонной зависимостей — спасибо, не надо. Дальше видимо надо будет рисовать в фотошопе, а тебе раз и приложение готовое. Но где-то я уже это видел…
rm -rf nuxtjs-test
Я когда-то давно ставил под вопрос использование самих фреймворков. Теперь же, когда они достигли хорошей производительности и удобных интерфейсов, этот вопрос отпал. Но использовать двойную абстракцию с тонной зависимостей — спасибо, не надо. Дальше видимо надо будет рисовать в фотошопе, а тебе раз и приложение готовое. Но где-то я уже это видел…
rm -rf nuxtjs-test
Все верно. Это хорошо для тех, кто уже знает вебпак, вуй и хочет просто быстро собирать прототипы. Можно попросить его сгенерировать вебпак конфиг, чтобы на него посмотреть.
Полностью согласен!
Когда попытался разобраться с тем как всё устроено, чтобы иметь возможность влиять на все звенья в проекте, который будет на этом построен, то понял, что нужно настолько долго разбираться в этом всём ради неизвестно чего, что плюнул на него.
Когда попытался разобраться с тем как всё устроено, чтобы иметь возможность влиять на все звенья в проекте, который будет на этом построен, то понял, что нужно настолько долго разбираться в этом всём ради неизвестно чего, что плюнул на него.
это вы еще spring для java не видели. на любом проекте что-то сломается, что потом ищешь полдня
Очень жаль что из-за подобный комментов в обоих статьях такой замечательный фреймворк проходит мимо хабрасообщества.
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. Новая абстракция
Его главная фича это серверный рендеринг, с каких пор люди ожидают что это не будет отдельным слоем абстракции? Если есть хоть один способ рендерить интерактивный 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. Можно и так. Не вижу тут особых проблем. Но скрывать конфиг в зависимостях — для меня это всё же странно.
3. Согласен. А теперь представьте у вас новый баг. Где проблема — во Вью, в Наксте или быть может в Лодэше?
4. А вот тут не согласен. Оставим фотошоп в стороне и поговорим про зависимости. Если зависимости не увеличивают сорс код, это вовсе не означает, что их не нужно контролировать. Все помнят историю про left-pad?
Вопрос: только у меня ощущение, что с ростом зависимостей я становлюсь более уязвим и теряю контроль над проектом? Понятно, что многих зависимостей не избежать, но в целом я считаю, что нужно держаться курса по их уменьшению.
Для каждой отдельной задачи нужно выбирать наиболее подходящий инструмент. Накст — это однозначно отличное решение для определённого типа задач.
Вопрос, на который я пытаюсь для себя ответить — хорошо ли это для общего образования/становления новых разработчиков? С одной стороны — конечно. Это вдохновляет и подталкивает на новые открытия. А с другой стороны не вырастит ли это более, хм, скажем «ленивых» разработчиков, и таким образом не ухудшит ли это общий уровень среди разработчиков в целом? Разумеется никто не заставляет использовать фреймворк, без изучения основ программирования, но именно так и происходит во многих случаях, которые я вижу в последнее время.
Теперь по пунктам.
1. Я бы не назвал серверный рендеринг — новым уровнем абстракции. Это достаточно непростая задача, которая даст разработчику много новых скилов.
2. Можно и так. Не вижу тут особых проблем. Но скрывать конфиг в зависимостях — для меня это всё же странно.
3. Согласен. А теперь представьте у вас новый баг. Где проблема — во Вью, в Наксте или быть может в Лодэше?
4. А вот тут не согласен. Оставим фотошоп в стороне и поговорим про зависимости. Если зависимости не увеличивают сорс код, это вовсе не означает, что их не нужно контролировать. Все помнят историю про left-pad?
Вопрос: только у меня ощущение, что с ростом зависимостей я становлюсь более уязвим и теряю контроль над проектом? Понятно, что многих зависимостей не избежать, но в целом я считаю, что нужно держаться курса по их уменьшению.
Для каждой отдельной задачи нужно выбирать наиболее подходящий инструмент. Накст — это однозначно отличное решение для определённого типа задач.
Вопрос, на который я пытаюсь для себя ответить — хорошо ли это для общего образования/становления новых разработчиков? С одной стороны — конечно. Это вдохновляет и подталкивает на новые открытия. А с другой стороны не вырастит ли это более, хм, скажем «ленивых» разработчиков, и таким образом не ухудшит ли это общий уровень среди разработчиков в целом? Разумеется никто не заставляет использовать фреймворк, без изучения основ программирования, но именно так и происходит во многих случаях, которые я вижу в последнее время.
Спасибо за ваш ответ, все по существу.
Единственное что можно добавить про зависимости, то что это необходимое зло. Мне их было тяжело принять в целом в Node.js. Но как ни крути точно такая же картина например в java и php со своими менеджерами пакетов и кучей зависимостей.
А насчет фреймворков всегда будут «ленивые» люди которые их просто используют как есть и ищут ответы на stackoverflow, и всегда будут люди которые будут копаться в исходниках и доках чтобы понять что за инструмент он использует. И это нормально и первый, и второй может быть хорошим специалистом по задачам которые он решает. Разный уровень подкованности, разные задачи, разная оплата труда. Каждый сам выбирает свой путь. Толковый opensource фреймворк как ни крути, не окажется хуже велосипеда, который поддерживает только один человек, а не целое комьюнити.
Единственное что можно добавить про зависимости, то что это необходимое зло. Мне их было тяжело принять в целом в Node.js. Но как ни крути точно такая же картина например в java и php со своими менеджерами пакетов и кучей зависимостей.
А насчет фреймворков всегда будут «ленивые» люди которые их просто используют как есть и ищут ответы на stackoverflow, и всегда будут люди которые будут копаться в исходниках и доках чтобы понять что за инструмент он использует. И это нормально и первый, и второй может быть хорошим специалистом по задачам которые он решает. Разный уровень подкованности, разные задачи, разная оплата труда. Каждый сам выбирает свой путь. Толковый opensource фреймворк как ни крути, не окажется хуже велосипеда, который поддерживает только один человек, а не целое комьюнити.
В статье вроде написано про серверный рендеринг, но подано это как-то странно, будто бы главным смыслом SSR является подготовка статики для выкладывания ее на CDN через nuxt generate.
На самом деле, SSR в nuxt — это попытка наконец-таки делать индексируемые динамические сайты (single page applications) + попытка ускорить первоначальную загрузку этих самых сайтов. Грубо говоря, вместо того, чтобы грузить заглушку, которая после инициализации подтянет данные через ajax, эти данные будут подтянуты nuxt-ом на сервере через node, отрендерены и отданы сразу же в шаблоне.
Насколько попытка удачная — покажет время, обещают скоро выкатить 1.0, пока что все это изрядно глючит, а раз так, едва ли можно положиться на nuxt в продакшене, где эти оптимизации имеют смысл.
На самом деле, SSR в nuxt — это попытка наконец-таки делать индексируемые динамические сайты (single page applications) + попытка ускорить первоначальную загрузку этих самых сайтов. Грубо говоря, вместо того, чтобы грузить заглушку, которая после инициализации подтянет данные через ajax, эти данные будут подтянуты nuxt-ом на сервере через node, отрендерены и отданы сразу же в шаблоне.
Насколько попытка удачная — покажет время, обещают скоро выкатить 1.0, пока что все это изрядно глючит, а раз так, едва ли можно положиться на nuxt в продакшене, где эти оптимизации имеют смысл.
спасибо за доклад на VueJS meetup
Sign up to leave a comment.
Nuxt.js: 28 килобайт пользы для веб-разработчика