Nuxt.js: When does one choose nuxt.js over vue.js?

[rlam3]

When does one choose nuxt.js over vue.js?

_{This question is available on Nuxt.js community (#c1514)}

[piyushchauhan2011]

I personally prefer Nuxt as it simplifies the process of project bootstrapping, gives sane defaults and less material to deal with build process. If a project requires SSR, I would definitely suggest you to go with Nuxt.

In some cases, when you are not happy with the default decisions, and want more control over the build process, or some use cases related to deployment that requires integration of gulp, webpack etc. , probably can take the vue default templates to bootstrap.

Also, Nuxt is built on top of Vue.js , and from the talks I remember the author Evan, wants it to flexible enough to use as a simple library you can request using <script> tag and start playing with it. Doesn't need to specifically use a build process to integrate it.

I really like the idea where I can just play with it like jQuery, quickly come up with something on codepen and share with people. Vue has a real sweet spot. As for larger scalable apps, I would recommend go for Nuxt. @rlam3

[robyedlin]

Agree that Nuxt is better for larger, scalable apps. Nuxt has a lot of the main Vue tools baked right in, including routing and state management.

[bjunc]

I think even small projects can benefit from Nuxt, as nuxt.config.js is a much easier to work in than tweaking the Vue webpack settings. The Nuxt defaults are sensible. Personally, I think the Vue webpack settings are overly complicated, and would benefit from a structure more like the nuxt.config.js structure. They kind of do that to an extent, but not very well.

However, the counter argument is that Nuxt is yet another dependency, and will always be lagging behind Vue / Vuex / Vue router / etc.. I also find that both the Vue and Nuxt teams are very dismissive / condescending of questions for help, or simply unresponsive. I recently started working in Elixir and Phoenix, and it has been a breathe of fresh air for the maintainers not to make you feel like an imbecile because you didn't get the memo that critical architecture changed while you were sleeping, and broke all your code (meanwhile the docs are 4+ minor versions behind). Pre-release software is expected to be volatile, so take that with a grain of salt...

So my 2c are that I am very cautious about Nuxt, but also optimistic that it will become more pleasurable of an experience once the v1 dust settles.

[robyedlin]

The core team is 3 people, so yeah, they can't get to everything. However, I have found that they are VERY responsive, and go out of their way to address issues that are even out of scope of Nuxt. They are busy, so they are direct. Just remember that this project is kind of massive for 3 people.

Lagging behind latest Vue is not always a bad thing. It can mean that Nuxt will be using battle-tested versions of the core tools.

It's true that Nuxt is in pre-release, so it will be volatile.

[rlam3]

I just wish Nuxt and Vue.js would be similar to Flask in their documentation. It seems like there is a lot of repetition between the two. And at some points a bit overwhelming...

@bjunc Thanks for recommending alternatives like Pheonix. I'll definitely have to look deeper into this.

http://flask.pocoo.org

Would one make a comparison of

Nuxt.js : Django :: Vue.js : Flask

?

[uptownhr]

i'd say always use nuxt :)

[bjunc]

@rlam3 I think the Nuxt maintainers have had their hands full with releasing v1, so documentation really hasn't been a top priority. I think that's a mistake, but an understandable one.

Just a forewarning, Phoenix is a whole other beast, and does require a "mental context shift" (as opposed to say, a full-stack JS app that pairs Nuxt with Express/Hapi/Adonis/etc). Worth it in my opinion.

But back to your original question, I think the number 1 reason for using Nuxt is the SEO benefit of SSR, with Vue's seamless hydration. All the other config sugar and router abstraction is far less important (again, just my opinion). If you don't need the SEO benefit, and you can configure Webpack to your own preferences, I find it harder to justify Nuxt in that scenario.

[aadii104]

@bjunc I read you are working with Elixir and Phoenix?
May I know whether you are working with vue on them? If yes please guide me as I want to use SSR on Phoenix so should I go with vue ssr or nuxt? I am damn new to Phoenix and by the way I am using Brunch over there in place of webpack, so is it good?
Thanks in advance.

[bjunc]

@aadii104 Yes, I am working in Phoenix/Elixir. I am using Nuxt as well, which is talking to Phoenix via GraphQL over websocket. I am seeing 200ms time-till-interactive when communicating between a front-end server (Nuxt) to the backend API server (Phoenix) That includes JWT authorization, user context, and modest db querying!

We should continue the conversation in a separate thread, but to quickly answer your questions (largely subjective, but backed by objective measurements as well):

I would run Nuxt and Phoenix as separate repos (as opposed to running Nuxt _inside_ Phoenix via their Brunch setup). Nuxt uses Webpack, and I personally think Webpack is the better tool anyway. So I would nix Brunch from your Phoenix repo all-together (removing the need for any static asset build). Let Nuxt/Vue do what it does best (SSR and browser UI), and let Phoenix/Elixir do what it does best (fault tolerant, highly productive, performant backend).

There are ways to use Elixir to render Vue via SSR, but don't bother. If you want SSR Vue, then Nuxt is the practical way to go on that.

Another option would be to use Adonis JS, which is a situation that would better lend itself to tightly coupling your backend with Nuxt (in-fact, you can use Adonis as the "parent", and have it use Nuxt as the renderer). The benefit is staying within the JS world of syntax and tooling. The potential downside is that your back-end and front-end are tightly coupled (this is so commonly outgrown that I ovoid on most projects). The other downside is that Elixir is more performant than Node in a real-world test. And in my opinion, the syntax is cleaner. I would actually prefer the negatives of switching between JS to Elixir, over the positives of writing all JS.

Hope that helps.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.