Nuxt.js over Vue.js: when should you use it and why | Hacker News Reader

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

bornfight.com

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.

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.

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.

RoR and Asp.net Core are not static site generators. They are web app frameworks that typically involve server-side rendered html.

A better example of a static site generator would be something like Jekyll (https://jekyllrb.com/)

Yeah this seems close to the philosophy of no side effects for functional languages. It's neat and has some nifty benefits for your code but for the 1% of situations where you need side effects/client-side rendering, you're gonna end up fighting the tool rather than enjoying it.

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.

Does 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...

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?

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

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

That's the main point of Nuxt. You look at the URL and find the page component without going through the routes file. In case that doesn't work for you, you can use `extendRoutes` for dynamic use-cases.

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.

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

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.

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

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.

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

It's ambitions and potential versus its current adoption make it a relative flop. Plus, since it's made by Google it may randomly end up in the graveyard without warning.

Dart wouldn't stop the relentless cycle of frameworks coming and going.

Case in point: Angular has an alternative Dart implementation which is AFAIK used by Google internally, but it didn't take the web by storm and currently the TS flavour is by far the dominant one.

I don't get it. Dart looks almost 1:1 exactly like Javascript. How would it have saved you from people building frameworks in it?

I think we're very lucky that Chrome never decided to include that Dart VM. Typescript turned out to be much better than Dart.

> Typescript turned out to be much better than Dart

I think we can agree to disagree. I would much rather use Dart, imo.

NuxtJS is probably intentionally similar to NextJS to mean NextJS but for Vue.

NestJS is probably a coincidence.

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.

> 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).

When starting a new project, I ask myself whether I want to use "vanilla" Vue.js or Nuxt.js.

They're two different kinds of projects, with different trade-offs, even though the underlying front end framework is the same.

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.

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?

I've found the dev experience with nuxt to be more enjoyable overall than it is with vue-cli. The main reason for that I would say is that you don't have to bother with routes and the generator can set up Tailwind (or other CSS frameworks/tools)

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

Ah. I have Vue with DRF, so I can already skip routes if I don’t need them.

I don’t send JS, my CDN does, so not a big win there.

> 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.

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

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.

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.

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.

That's just one point. Nuxt is the best way to built a multi-page web app with Vue components. Once you're using vue-router and Vuex, you might as well use Nuxt.

Make sense. Currently using neither, but both are on my list to eval.

Well, about the not useful, I was working on a large service for lawyers and accountants behind a paywall, but then the new CEO decided we wanted to open up portions of stuff to google. So just because something isn't going to ever be SEOed anyway, doesn't mean that at some point in time, guess what, we need to SEO optimize some of this stuff!

This is literally a b2b platform. It wouldn't work to remove a paywall. But cool story.

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

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?

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.

> 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.

neat

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.

I'm pretty happy with Nuxt. I built a project with a custom SSR server based on Vue's guide (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 (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...). 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!)

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.

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.

What is ERP?

Enterprise Resource Planning

Think SAP or Salesforce with a bunch of custom/addons. Sometimes account features are built in.

It's very much on a different scale of complexity than a todo app. Or any app that 'does one thing well'. I think a lot of devs forget this when talking about what everyone MUST do, or making recommendations like a form should never have more than 5 fields.

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

Is writing an extra API service layer for what could otherwise use the database directly cheap on developer time?

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.

Nuxt works fine for all the uses case that I have come across, even for ERP projects. With Nuxt you can have real redirects, real 404 pages, and a well-established project structure. The only hard thing is that server-side error is more difficult to inspect

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.

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.

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

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.

When dealing with large tables with searching + sorting + paginating capabilities, I always use query params and let the API do the heavy lifting

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

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

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

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

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

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).

All browser processes 100KB of scripts just fine. And they process the scripts in the background. The HTML is already parsed and displayed.

For low end android devices on a network in rural areas, that's a lot.

I would guess that for the majority of JS-heavy websites, android users in rural areas probably do not make up that much of the target market.

It's unrelated to network conditions (those just make it worse). It's related to the processor in many mobile phones.

It runs just fine for my site, across browsers and OSes.

You're probably getting down-ranked by Google, they use performance as a metric.

And what is the best solution? Client Side Rendering is worse, because users see a blank page until the script is parsed. 100KB is actually desirable, because it's included Vue and Vuex out of the box.

The best solution is to not have as much JavaScript. Use a smaller framework. Use fewer dependencies. Lazy load things when you can.

The solution is to have a performance budget at the start of your project so things never get so bad.

In what year, 2004? A single ad can take up that much space.

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.

in this case, they are related toolchains. the title and premise is just really bad clickbait.

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.

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.

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.

Reply on news.ycombinator.com