Nuxt.js over Vue.js: when should you use it and why

Going to the website it wants me to install .. Safari 13.

Generally, it feels like it strikes a good balance between being fully configurable boilerplate and opinionated framework.

They do have a kind of weird plugin/module system that I worry is an overly complicated layer of abstraction - basically, stuff that would normally be manually hooked up in your server or client entry point script now gets called automatically by Nuxt at various points. Still, it is useful for setting up things like authentication (e.g. parse cookies on server and set auth headers in Axios).

They're also still iterating on the public API, though they've been pretty careful to deprecate without breaking things. Like, the fetch() hook that used to be used to load data at a page level (e.g. "before transitioning to this route, load this set of data") was totally overhauled to now be "load data for this component," with no "pre-transition await" available anymore (https://nuxtjs.org/blog/understanding-how-fetch-works-in-nux...). This is a good change, but an example of the complex problems that come up in these SSR frameworks, and why they end up being a lot more complex than just simple wrappers around the ecosystem. You really have to buy in when you use a framework like this, more than just buying into Vue itself.

I did see that they just raised a seed round (https://nuxtjs.org/blog/seed-round), which is surprising to me. I don't see a lot in that announcement about how they're going to make money, which is a bit scary. Over in React-land, of course, Next.js is nominally owned by Vercel (formerly Zeit), which is also venture-backed, but Next is related to their primary revenue stream while not being at all the main focus of the company, which is probably the right spot for this sort of thing.

Moving to Vue 3 will be a problem for Nuxt, I think, because of the abstractions they've built on top of Vue.

(also, glad this post came up because while double-checking to see how big Nuxt is in my app, I realized I was failing to gzip my client assets because I misconfigured Caddy, gah!)

There are other points in favor of doing SSR + hydration besides SEO:

1) Reducing the amount of JS you are sending to the client.

2) Not making a SPA and keep the native functionality of back/forward behavior (scroll behavior, cached pages, forms are filled when going back).

3) Simplifying development. You don't need to manage central state anymore as you're dealing with one page at a time. You might not need an API as you're rendering the page from the server. Etc.

I've been making SPAs for years and for my current project I'm doing SSR + hydration (not using Vue) and loving it.