Nuxt-Js. An Objective Assessment of the Framework

Intro

In the 2022 Stack overflow developer survey, over 2/3 (about 64%) of the developers that have used the framework love it. Yet only about 5% of developers who do not already use the technology have expressed interest in developing with it. I was honestly curious as to why that's the case. I've been working with Nuxt.js for over a year now. My first project was a simple weather app. It's probably my most used frontend framework, so it only makes sense that my first tech related article is about it. I'll try my best to give you an insight into the framework, a bit of how it works, why you should probably give it a try in your next project, and when I think it's probably not recommended.

Concept

Nuxt is an "intuitive" framework used for building simple and powerful Vue.js applications. It's a higher-level framework that offers a simpler development environment for universal and static Vue applications. The framework comes with a lot of features that improve developer experience and productivity. Some of the features being:

• Little to no configuration
• Automatically generated routes
• Server side rendering (SSR) and Static Site Generation (SSG)
• Enhanced meta-management and SEO
• Out of the box State Management (Vuex)

The technology is composed of different core packages. The core engine (Nuxt), bundlers (Vite and Webpack), server engine (Nitro), command line interface (Nuxi) etc. These packages abstract all the intricate pre-coding setups and configurations, allowing you to completely concentrate on creating a fantastic Vue.js web application. I'll be discussing the benefits and some limitations (at least in my opinion) of using Nuxt in the next segment.

Strengths

"Development of Javascript applications has already been made simpler by Vue. So why should I choose Nuxt? ". Well...

SEO and Site Performance

One of the significant benefits of using Nuxt is SEO. Nuxt resolves the issues we tend to encounter when working on SPAs. From web performance and routing to enhanced meta tags. If you've developed or worked on Single page applications (SPA) you would know that one of their biggest drawbacks is SEO. This is because when a browser loads an SPA (say built with React or Vue), the server returns only barebones HTML without any rendered content. It sends a new request to get the JavaScript bundle, which is then run on the browser to render content. That's where SSR comes into play. Like the name implies, scripts are being run on the server that generate fully rendered HTML on page load. This results in faster page loads and optimal performance and SEO because all of the content is already rendered on the server and the application is properly indexed by search engines.

Nuxt by default employs SSR to deploy applications, however you can still generate a static site with Nuxt if you want to avoid the server requirement while still reaping most of the SEO benefits. Nuxt makes use of vue-meta (a HTML metadata manager for Vue.js) internally to generate the contents of the <head> tag. This means that SPAs generated with Nuxt tend to be more "meta-enhanced" than our typical SPAs.

Overall, sites built with Nuxt are more performant and SEO-friendly.

Automatic Code Splitting

If you're a developer, this is probably not the first time you've heard of code splitting. But for the benefit of those that haven't, it simply means dividing your code into numerous smaller bundles, commonly referred to as "chunks," which you ship to the browser. Basically just splitting your JavaScript code into separate files. The aim is to speed up the initial loading speed of the application, hence improving performance.

Nuxt automatically handles code-splitting for your application using its Webpack configuration. It does this every time you run the production build command (nuxt build/nuxt generate), producing code-split points for each route. For each page's "chunk," it only loads the components and dependencies that you need.

Configurations

One of the really nice features about Nuxt is how it sorts out all the pre-configuration needed to create production-ready Vue applications. For example, in a large Vue app, the routing configuration may become lengthy. When using Nuxt, all you have to do is create or drop your Vue components into the pages folder, and Nuxt will automatically create your routes without any configuration.

Directory Structure

Code organization becomes increasingly crucial as your application grows and scales-up. By default, Vue provides an asset and components directory, which is great, but Nuxt takes it further and configures extra folders like:

• Pages: Handles routing
• Layouts: Custom templating
• Plugins: For Vue & other Js plugins and to inject functions or constants before instantiating your Vue app
• Middleware: Similar to plugins, only that the functions are executed prior to rendering a page or layout.
• Modules: Functions that are called sequentially when booting Nuxt
• Store: Vuex state management

This "dogmatic" approach makes switching from one Nuxt application to another and getting up to speed really straightforward.

Modules

Modules are functions that are called sequentially when booting Nuxt. The framework waits for each module to finish before proceeding. In this way, modules can customize almost any aspect of your project. What I really love about modules is that they can be incorporated into npm packages. This makes them reusable across projects and shareable with the community. Seen a use case that hasn't been covered in Nuxt? Create a module and make it open source.

Some other benefits of using Nuxt include:

• Easy setup using the command line interface (Nuxi) with the starter template
• Nuxt makes it possible for you to get the most out of your universal web app without a server.
• At the core of things, it's still just a Vue app, so you get all of those benefits. I honestly consider Vue the best Js framework. Simple, fast, lightweight, solid architecture, reactive two-way binding, not Jsx (although it has the option if that's your preference), etc.
• For a relatively small community, the documentation is quite comprehensive.

Caveats

Just like every framework and technology out there, Nuxt has its limitations and caveats. But before I go into them, there's something fundamental I need you to understand. Nuxt requires a slightly different way of thinking than Vue. The primary distinction being that Vue runs exclusively on the client-side, which isn't the case for Nuxt. This can lead to some silly bugs and errors if not properly understood. For example, on the server-side, the app is running on Node.js, hence we do not have access to some javascript objects like window, local storage, document, navigator and all the other objects and functions that are provided by the browser. These objects can only be accessed via the client-side lifecycle hooks beforeMount() and mounted(), so attempting to utilize them in any other hook could introduce bugs or logical errors. Vue does not have these problems because it is always running on the client.

Alright, back to the caveats. Here are some of the challenges I've encountered while working with Nuxt

Plugins

Some Vue plugins don't function properly with Nuxt. The reason being that they weren't designed with servers in mind. The workaround for some would be to add a client constraint or check (e.g. process.client) so the functions only trigger on the client side.

Debugging

It's gotten better with recent updates and releases, but debugging in Nuxt can be very difficult sometimes, especially on the server side and when generating a build. When some things break, it may be really painful to try to figure out what exactly went wrong. This is a problem that gets increasingly frustrating as your project gets bigger and more complex. The console will typically report an error, but it doesn't always provide you with any relevant information. There are different ways one can go about solving it depending on the issue. VS Code can be configured to make debugging a little bit simpler, but from a general perspective, it's a pain.

Setting up Custom Packages or Libraries

Another drawback I tend to experience when using Nuxt is setting up custom libraries. You might need to spend more time on it than you anticipated. So if you're working on a tight development timeline, it can get uncomfortable.

Summary

Nuxt is a very effective and powerful framework that offers so much and makes your life as a developer very easy. It has a lot of helpful features that make creating front-end applications simpler. However, it's not the best choice for all types of client-side applications. Depending on the objectives, specifications, and requirements of the project, you, the developer, ultimately decide which framework is more suitable because no one understands the scope of the project better than you. I usually recommend it when your project requires sustainable SEO (e.g. a blog page or company website), authentication (Nuxt middleware handles this properly) or a project with multiple pages (you would really appreciate the layout and pages directory). But if you're working on an in-house project (say an admin dashboard), a custom widget for a website, or a simple SPA that doesn't require SEO performance, you should probably just stick to Vue. It's scalable, lightweight and tends to handle all that in a much better way.