
Nuxt.js over Vue.js: when should you use it and why - PetraIgnjatovic
https://www.bornfight.com/blog/nuxt-js-over-vue-js-when-should-you-use-it-and-why/
======
whoisjuan
In my humble opinion, you lose a lot when you go fully static. One particular
case that becomes a pain in the ass is redirections. Nuxt has some redirect
modules but they feel super half baked.

Also routing is a mess. Really no way to set up routing in a decent,
understandable way.

So in my opinion just use Nuxt when you are sure your website is not going to
need any complex functionality that is easily achievable with a server
middleware. Pretty sure that there are other ways to achieve good SEO and in
general Search Engine indexation without giving up so much.

~~~
jmkni
I feel as though if you just want a static website, you're better to use one
of the more mature frameworks designed for that purpose, like Ruby on Rails or
Asp.net Core etc.

I worked on a project built with Nuxt about a about a year ago and I really
didn't like it. Everything felt like a chore.

~~~
ComputerGuru
Am I missing something or did the definition of static website change? AFAIK a
static site is one that has no backend and you can throw on S3 or whatever. An
ASP.NET project is pretty much the absolute furthest you can get from a static
website.

------
thomasedwards
We use Nuxt on a fairly large project. One of the biggest problems we’re
having is that there’s no routes file you define yourself, you structure it by
putting views in folders. This is a nightmare once you have more than a few
models. It also leads to highly confusing page names, and if you have more
than one variable in a route, completely screws everything up. We’ve ended up
grouping things together in folders just to make it easier to manage, but that
directly effects the URL.

~~~
avolcano
Does extendRoutes ([https://nuxtjs.org/api/configuration-
router#extendroutes](https://nuxtjs.org/api/configuration-
router#extendroutes)) not work for y'all? I haven't had to use it (yet) but I
was happy to see an escape hatch, though I could imagine it not scaling very
well...

~~~
thomasedwards
My understanding was that it just added to the existing generated list, I
can’t work out how you’d tell it to ignore all your current pages and then
manually write them all out?

~~~
freneticks
you can use router-module if you want to do everything yourself
([https://github.com/nuxt-community/router-module](https://github.com/nuxt-
community/router-module))

~~~
thomasedwards
Ah that’s perfect, I don’t know why I haven’t found it before. Thanks.

------
AbuAssar
NuxtJS

NextJS

NestJS

why all these frameworks have very similar names? it is very confusing every
time I read a news about one of them I wonder which one is which.

~~~
andarleen
probably because there are so many js “frameworks” that they are running out
names

~~~
taywrobel
Sort of makes me bummed out that the Dart project failed.

If there was one time when we could have escaped the client side hell that is
JavaScript it would have been then, when chrome had astonishing market share,
and Dart could compile down to JS to ease the transition until native support
became standardized.

But nope, here we are with anotherone.js every week.

~~~
swyx
what makes you say it failed? Flutter is growing strong.

~~~
nivethan
Is there a way around the nested mess in Flutter widgets? I took a stab at a
small app but it was basically a new div hell. Besides that however, it was
quite neat.

~~~
swyx
haha idk im just going off of what others say, i dont use it myself

------
swyx
this title and entire premise of the essay is the definition of false
dichotomy. when you use nuxt.js you use vue.js. its very clear to webdevs what
the metaframework does more than the framework, and you need both.

~~~
canada_dry
> this title and entire premise of the essay is the definition of false
> dichotomy

The article's very first words are: _Nuxt.js is a frontend framework built
upon Vue.js_ so I think it's more of a semantics thing on what he meant by
"over" (i.e. on top of vs. replaces).

------
adevx
I've used Nuxt.js when I started rewriting a membership site from WordPress to
Vue.js. But at that time, the routing options were limited so I opted for a
hand crafted Vue.js + server side rendering setup. Maybe today, I would try
out Nuxt.js again. Or maybe not, the drawbacks are another layer of
abstraction on top of Vue.js. That being said, their community is great and
the development is very active. When I did a project in React, and tried
Next.js, I expected to find much more info and plugins for this combination,
but found this to not be the case.

------
brianwawok
So the point is to improve SEO of Vue apps

Perhaps useful to some sites. Assuming Google has issues with Vue. Not useful
for someone doing content behind a sign-in that isn’t going to ever be SEOed
anyway?

~~~
pier25
> So the point is to improve SEO of Vue apps

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.

~~~
tailsdog
Out of interest, what are you using instead of Vue?

~~~
pier25
Svelte.

It reduces the JavaScript sent to each page even further because it doesn't
have a runtime per se. Basically each component is "compiled" to a set of
imperative DOM instructions with some helper functions.

~~~
whoisjuan
I wanted to like Svelte so bad, but the lack of tooling made it pretty hard to
debug.

Hopefully they will get there one day but so far it gives me the feeling that
I could hit a dead-end with it at any time.

~~~
pier25
It's not perfect but I'm willing to accept all its shortcomings because of
everything I get in return.

Sometimes I hit a little bump on the road which would be faster/easier to
solve in React/Vue/etc but even including those slowdowns I save so much net
dev time it's crazy.

------
kangoo1707
I always use Nuxt by default for new projects, and it's a correct decision
every time. People who choose to do Client Side Rendering (SPA) finally
struggling on SEO and other tasks.

1\. Nuxt can runs in SPA mode just like using Vue CLI. The opposite is not
true

2\. SEO is the winning feature of Nuxt, no doubt.

3\. Real server status code: especially useful for redirections and 404 pages.
For example if you do `curl -I /some-page-that-does-not-exist`, you will get
back 404 status code, which is critical for sitemaps and uptime tools.
(Instead in SPA you always get 200 for all the pages).

4\. Pages written in Nuxt seems to display faster, because the HTML is sent
immediately. I say "display" here, not necessarily "load" faster.

5\. Real Express middleware helps a lot when doing route validations and
authorizations. You can also make calls to private API without exposing them
on the client side.

6\. Can adjust the amount of HTML sent to client by wrapping client-side-only
components in a <client-only> component. Which means that on the server you
don't need to generate giant HTML for a simple datepicker, and let the browser
does that

------
jpz
I admit I don't know the space that well, but I find it interesting that you
get static site generators for SPA frameworks, and the companies behind them
get really significant VC funding.

Naively it seems a trivial problem, but I guess that SEO for SPA is not as
trivial as I imagine?

~~~
kangoo1707
Why are people slapping Static Site Generators to all the problems?

Imagine you build an e-commerce website that has ten thousands of products,
that can be accessed by example.com/products/{product-slug}. Now what is
making more sense: 1\. Generating ten thousands of .html file for each
products in the DB 2\. Use routing in Nuxt like this "/products/$productSlug"
and query for $productSlug in the database

To me the (2) approach is a clear winner here. And the performance only
depends on how fast your API can query a single product from the database,
which is pretty fast 99% of the time.

------
coldcode
> Your web browser (Safari 13) is out of date. Update your browser for more
> security, speed and the best experience on this site.

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

~~~
dschiffner
neat

------
mmusc
As others pointed out nuxt can be very restrictive when you're trying to build
something that doesn't fit their mould. What I end up using is vanilla vue.js
and a cli plugin to statically generate the pages that need to be SEO friendly
during build. Best of both worlds.

------
avolcano
I'm pretty happy with Nuxt. I built a project with a custom SSR server based
on Vue's guide ([https://ssr.vuejs.org/](https://ssr.vuejs.org/)), and
maintaining it/tweaking it wasn't too bad, but moving all that complexity to
Nuxt was nice. If you'd like to see a realistic codebase, warts and all, it's
here: [https://github.com/thomasboyt/jam-
buds/tree/master/app](https://github.com/thomasboyt/jam-buds/tree/master/app)
(powers the jambuds.club frontend).

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...](https://nuxtjs.org/blog/understanding-how-fetch-works-in-nuxt-2-12)).
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](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!)

------
gildas
Alternatively, if you want to get the same result in terms of SEO. You can use
seo4ajax.com. In 5 minutes it's integrated and ready to use. Disclosure: I am
the founder of the service.

------
ehutch79
There are people over on reddit who say that EVERY project should use nuxt.
from the lowly todo app, to huge erp projects...

Yet, especially for ERP projects, most of those features are problematic. Like
SEO. I don't want a search engine to ever see my content. In fact, my
robots.txt says not to index it. SSR is a non starter, since everything would
vary based on the user, we're just shifting the rendering back to the server,
for no real gain other than the round trips on the api. The routes can be a
problem as well. My routes have different navigation guards depending on
permissions and state for the user, i haven't checked but i doubt auto
generated guards based on folder structure wouldn't handle our weird business
logic. COmbined with the difficulty of dealing with errors server side,
nuxt.js isn't going to work in these kinds of cases.

TL;DR Nuxt.js does not work for everyone, even if people say it does.

~~~
ComputerGuru
In an enterprise context, round trips (on the intranet) are cheap.

~~~
ehutch79
Agreed. Even across the internet, it's not bad.

Most of the ssr for performance is around how a couple extra milliseconds will
increase your bounce rate. For some of us, if our users bounce, they get
fired, because the site is the tool they use to do their job. (but we should
always endeavour to be performant, because we don't want to make their job
more miserable) So things like bounce rate doesn't matter.

------
revskill
I only use SSR for `bot` or for `?ssr=true` in dev mode. My setup is that, SSG
most of the time, with fallback to SSR for bot/crawlers, else return the
spa.html which is just a SPA.

------
nerdbaggy
My biggest thing with Nuxt is that only the first page load is server side
rendered. Everything else is client side. So doing complex search and re-
render is done client side.

~~~
aabhay
If you use query params, the search and render can be done server side..

~~~
thdrdt
Which should be done because it helps the user very much.

Sharing filtered links or storing filtered links in your favorites becomes
impossible when the query parameters don't change.

------
Touche
Warning that Nuxt.js is almost 100k out of the box, making it unsuitable for
mobile usage.

~~~
chimen
Depending on what you're building, I don't find 100k to be that much .

~~~
thdrdt
It's not only filesize it's also what the browser must parse. Parsing huge
files is not a great experience on mobile.

~~~
warent
I'm trying to imagine what browser is so outdated that it struggles to parse
100kb of javascript

~~~
Touche
It's not the browser, it's the processor that's in most non-iPhones.

~~~
true_religion
Samsung phones and Pixels aren’t that bad either. I am not saying it to be
proud, but I tested our 3mb internal app with a 5 year old android phone, and
worked.

The only time it was slow is if the browser itself was old (e.g. Chrome 44).

------
taywrobel
Oh good, another .js. Throw it in the pile.

The quagmire of subtly different JavaScript frameworks is definitely the
leading reason I avoid front end work like the plague.

~~~
warent
If you just said the first two sentences and we could have inferred that you
don't work in frontend. Every technology has tradeoffs, and frankly I'd like
to hear about this mystical backend panacea you're implying.

~~~
taywrobel
I generally work in go, where the standard library covers the vast majority of
use cases. If you have some crazy specific performance needs there are
frameworks for that, but generally vanilla go will get you where you need to
go.

I’d love to see a “modern” web app built in pure JavaScript without a
framework.

~~~
warent
That's _most_ modern web apps. React is a library, not a framework. jQuery is
also a library. That covers probably about 95% of the web today.

