# Nuxt.js - Quick Introduction
Vue.js app development just got better! We got Nuxt.js now!
Nuxt.js helps you with the SPA part. It adds two major features to Vue.js:
- Server-side rendering out of the box
- Declarative configuration by using folders and files to structure your projects and specifically your routes
Let’s dive into these two concepts real quick:
# An Introduction to Server-side Rendering
The advantage of creating browser-based UIs is that you reduce the idle time of your application. Users can always interact with it, async tasks (e.g. fetching data from a server) are executed behind the scenes. Such kind of web apps (=> SPAs) are very popular these days because they bring native-app behaviors to the web.
The downside of SPAs is SEO. Since your page is rendered in the browser, crawlers have difficulties understanding your page. This is especially an issue when your page is rendered with asynchronously fetched data (i.e. if you need to load the data before you can render it).
Search engine crawlers will essentially see this:
Since the entire content gets loaded and rendered in the browser, there’s not much to be detected by crawlers. They won’t wait for your async data to load, hence your search engine rank is probably not going to look that good.
Server-side rendering fixes this issue. You still end up with a single page application but on first load, the page is rendered on the server. You could call this “pre-rendering on-the-fly”. If a user visits
index.html file with the pre-rendered content would be returned. Subsequent navigation within your app would again be handled in the browser. Additionally needed data (e.g. on a different page/ route) would again be fetched asychronously behind the scenes.
Whenever a user enters a page (for any given route supported by your SPA) for the first time or refreshes the page, the page is pre-rendered dynamically on the server.
This greatly improves SEO since the crawler essentially always sends a new request for each of your pages (it doesn’t navigate within your app by clicking links etc) and hence it always receives a pre-rendered version of the page.
A crawler could suddenly see all the nice content of your page:
The server-side rendering part is the difficult part though. Your Vue.js code, which is intended to be executed in the browser, suddenly needs to run on the server. That’s where Nuxt.js helps you by providing a readily configured workflow which supports this.
# Configuration via Folders & Files
Besides helping you with server-side rendering, Nuxt.js also introduces a second important concept: You build and configure your Vue.js app with one single config file (
nuxt.config.js) and a bunch of folders and files.
As you can see, there are quite a lot of folders. You can dive deeper into the meaning of all these folders, but the core takeaway is that you configure the entire routing by placing
.vue single-file components in the
pages folder. The other folders are then used to create non-page components (=>
components folder), store
assets like images, define
middleware which should be executed before a route is loaded etc.
By following this approach, you actually don’t have to configure a lot to end up with a working Vue.js application. You simply re-create your planned app structure as a directory of folders and files!
# Nuxt.js & Vue.js - What’s happening behind the Scenes
You learned about the two core concepts Nuxt.js adds to Vue.js.
If you look closely, you’ll notice that neither of the two concepts affects the features you use in your Vue.js apps.
You still work with
computed properties, you can still use Vuex, you still create
.vue components with
Nothing changed regarding that! You still build Vue apps for the same purposes you built them before.
But now the development process is easier (thanks to the implicit configuration) and the deployed app is more powerful (thanks to server-side rendering and improved SEO).
And that’s how you should think about Nuxt.js: It supercharges your Vue apps. It doesn’t actually add much to the runtime app, it instead simplifies the development process and makes server-side rendering a breeze.
This also of course means that the bundle you ship to your users - the JS code they have to download - only grows very slightly.
# Why would you NOT use Nuxt.js?
With all these new concepts and advantages outlined, what would be reasons speaking against using Nuxt.js?
Here are some possible reasons you could bring up:
- I don’t need SEO, I’m happy with a traditional SPA
- I want to configure my routes manually
- I don’t want to add a single kb to my final bundle
- I don’t want to have yet another dependency in my project
Are these valid reasons?
- Even if you just want to build a “normal” SPA, you can do that with Nuxt.js and take advantage of the “configuration by folders and files” approach. You can actually set the build mode of Nuxt.js apps to
universal) in the
nuxt.config.jsfile. By changing the mode, a normal SPA is created once you build the app.
- Fair enough, but besides the fact that you can re-build any route config with the folders & files approach, you can even set your own programmatic route config in Nuxt.js.
- Okay, if adding a bit more code to the final bundle is an absolute no-go, you can’t use Nuxt.js.
- It can indeed be frustrating to see how many dependencies modern frontend projects have. Nuxt.js is one of the better ones though.
# Dive Deeper!
I hope this article got you interested in Nuxt.js and I also hope that I could explain it’s core ideas. Definitely share your feedback (button at the beginning of the article) with me!