Skip to content

Rendering Modes in Nuxt 3

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Nuxt is an open source framework to make your Vue.js applications. Currently, Nuxt 3 has a release candidate and the stable version would be out soon. In this series, I would be taking us through Nuxt 3 concepts and APIs. In this first part, we would focus on rendering modes in Nuxt 3.

Setup

To quickly install Nuxt 3, lets use the nuxt 3 documentation.

Rendering modes

Nuxt 3 offers a couple of different rendering modes:

  • Universal Rendering
  • Client-side rendering
  • Hybrid rendering

Each of this rendering modes have their use cases and benefits. In this article, we will take a look at their pros, and how to implement them in Nuxt 3.

Universal Rendering

Universal rendering allows for code to be pre-rendered at build time or rendered on the server before it is served to the client on request.

This results in very fast pages, because rendering on the server is faster and the user gets content on page load compared to Client-Side only rendering.

Nuxt 3 also improves this greatly by allowing code to be rendered not just on node-js servers, but also on CDN edge workers. This increases the site speed, and also helps reduces cost.

In Universal rendering, we can use pre-rendering. This means we can have some pages, or all pages, pre-rendered on build time, and other pages rendered at request time.

This is a great choice for static pages like website landing pages, blogs and some dynamic pages that don’t change often and have a finite number of pages.

Universal mode with server side rendering is best for sites with highly dynamic content that changes frequently, like ecommerce sites.

Pros

Search Engine Optimization: Universal rendered apps serve the page with the generated html content to the browser. This makes it easy for web crawlers to index such pages.

Performance: The performance of Universal rendered apps are fast compared to Client-side rendered apps because the page already contains the HTML code, and this does not rely on the users device to parse and render the HTML.

To deploy and use our Nuxt 3 application on a node-server in universal mode:

First in nuxt.config.js file

defineNuxtConfig({
  ssr: true,
  preset: 'node-server'
})

By default, SSR is set to true if it is not passed in the nuxt.config.js file. Also, preset is set to ‘node-server’ by default, but this can be changed to suit the deployment environment. For example, Vercel preset should be used for Vercel deployment. You can read here for available deployment presets.

When we run our build command:

yarn run build

This will generate the output folder with the app's entry point file.

Next, we can run the file with Node.

yarn run start

or

node .output/server/index.mjs

To deploy and use our Nuxt 3 application on a static server in universal mode:

First, in our nuxt.config.js file, we specify the pages to be generated:

defineNuxtConfig({
  nitro: {
    prerender: {
      routes: [ '/article/100', '/article/101' ]
    }
  }
})

Now we can run our generate command:

yarn run generate

This will generate the output folder '.output/public' with the pages files and the related JS and CSS files. We can simply place this folder into any static hosting service, and access our application.

To generate our routes async, like a blog website, we can fetch our routes and then pass it to the route during build with this hook.

 defineNuxtConfig({
  nitro: {
    prerender: {
      routes: [ '/article/100', '/article/101' ]
    }
  },
	hooks: {
		async 'nitro:config'( config ) {
			const routes = await generateBlogRoutes( config.runtimeConfig );
			config.prerender.routes.push( ...routes );
		}
	}
 });

Client side rendering

Client side rendering involves sending every request to a single file, usually ‘index.html’, with empty content and then linking them to the corresponding JS bundles, allowing the browser perform the parsing and rendering of the HTML.

Client side rendering is a great choice for heavily interactive websites with animations, like online gaming sites, Saas sites, etc.

Pros

Offline support: Client-side rendered apps can run offline once the dependent JavaScript files are downloaded if there is no internet. It is easy to make a client side rendered app a Progressive web app.

Cheap: Client-side rendered apps are the cheapest in terms of hosting as you do not need to run a server. They are made up of HTML and JS files which can be served from a static server.

To config our Nuxt 3 app to be fully client side rendered:

First in nuxt.config.js file

defineNuxtConfig({
  ssr: false
});

Now we can run our generate command:

yarn run generate

This will generate the output folder '.output/public/index.html' with the apps entry point file and the related js files. We can simply place this folder onto any static hosting service, and access our application.

Hybrid rendering

Hybrid rendering is an unreleased Nuxt 3 feature that allows developers to configure different rendering modes for different pages. This should be available later this year, and we will explore it in this series once it is.

For more official information about the hybrid rendering discussion.

In the next article, we will implement a simple webpage using the universal rendering. The webpage will have a blog which will be prerendered, and also a dynamic user page which will be server rendered.


I hope this article has been helpful to you. If you encounter any issues, you can reach out to me on Twitter or Github.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

You might also like

Nuxt DevTools v1.0: Redefining the Developer Experience Beyond Conventional Tools cover image

Nuxt DevTools v1.0: Redefining the Developer Experience Beyond Conventional Tools

In the ever-evolving world of web development, Nuxt.js has taken a monumental leap with the launch of Nuxt DevTools v1.0. More than just a set of tools, it's a game-changer—a faithful companion for developers. This groundbreaking release, available for all Nuxt projects and being defaulted from Nuxt v3.8 onwards, marks the beginning of a new era in developer tools. It's designed to simplify our development journey, offering unparalleled transparency, performance, and ease of use. Join me as we explore how Nuxt DevTools v1.0 is set to revolutionize our workflow, making development faster and more efficient than ever. What makes Nuxt DevTools so unique? Alright, let's start delving into the features that make this tool so amazing and unique. There are a lot, so buckle up! In-App DevTools The first thing that caught my attention is that breaking away from traditional browser extensions, Nuxt DevTools v1.0 is seamlessly integrated within your Nuxt app. This ensures universal compatibility across browsers and devices, offering a more stable and consistent development experience. This setup also means the tools are readily available in the app, making your work more efficient. It's a smart move from the usual browser extensions, making it a notable highlight. To use it you just need to press Shift + Option + D (macOS) or Shift + Alt + D (Windows): With simple keystrokes, the Nuxt DevTools v1.0 springs to life directly within your app, ready for action. This integration eliminates the need to toggle between windows or panels, keeping your workflow streamlined and focused. The tools are not only easily accessible but also intelligently designed to enhance your productivity. Pages, Components, and Componsables View The Pages, Components, and Composables View in Nuxt DevTools v1.0 are a clear roadmap for your app. They help you understand how your app is built by simply showing its structure. It's like having a map that makes sense of your app's layout, making the complex parts of your code easier to understand. This is really helpful for new developers learning about the app and experienced developers working on big projects. Pages View lists all your app's pages, making it easier to move around and see how your site is structured. What's impressive is the live update capability. As you explore the DevTools, you can see the changes happening in real-time, giving you instant feedback on your app's behavior. Components View is like a detailed map of all the parts (components) your app uses, showing you how they connect and depend on each other. This helps you keep everything organized, especially in big projects. You can inspect components, change layouts, see their references, and filter them. By showcasing all the auto-imported composables, Nuxt DevTools provides a clear overview of the composables in use, including their source files. This feature brings much-needed clarity to managing composables within large projects. You can also see short descriptions and documentation links in some of them. Together, these features give you a clear picture of your app's layout and workings, simplifying navigation and management. Modules and Static Assets Management This aspect of the DevTools revolutionizes module management. It displays all registered modules, documentation, and repository links, making it easy to discover and install new modules from the community! This makes managing and expanding your app's capabilities more straightforward than ever. On the other hand, handling static assets like images and videos becomes a breeze. The tool allows you to preview and integrate these assets effortlessly within the DevTools environment. These features significantly enhance the ease and efficiency of managing your app's dynamic and static elements. The Runtime Config and Payload Editor The Runtime Config and Payload Editor in Nuxt DevTools make working with your app's settings and data straightforward. The Runtime Config lets you play with different configuration settings in real time, like adjusting settings on the fly and seeing the effects immediately. This is great for fine-tuning your app without guesswork. The Payload Editor is all about managing the data your app handles, especially data passed from server to client. It's like having a direct view and control over the data your app uses and displays. This tool is handy for seeing how changes in data impact your app, making it easier to understand and debug data-related issues. Open Graph Preview The Open Graph Preview in Nuxt DevTools is a feature I find incredibly handy and a real time-saver. It lets you see how your app will appear when shared on social media platforms. This tool is crucial for SEO and social media presence, as it previews the Open Graph tags (like images and descriptions) used when your app is shared. No more deploying first to check if everything looks right – you can now tweak and get instant feedback within the DevTools. This feature not only streamlines the process of optimizing for social media but also ensures your app makes the best possible first impression online. Timeline The Timeline feature in Nuxt DevTools is another standout tool. It lets you track when and how each part of your app (like composables) is called. This is different from typical performance tools because it focuses on the high-level aspects of your app, like navigation events and composable calls, giving you a more practical view of your app's operation. It's particularly useful for understanding the sequence and impact of events and actions in your app, making it easier to spot issues and optimize performance. This timeline view brings a new level of clarity to monitoring your app's behavior in real-time. Production Build Analyzer The Production Build Analyzer feature in Nuxt DevTools v1.0 is like a health check for your app. It looks at your app's final build and shows you how to make it better and faster. Think of it as a doctor for your app, pointing out areas that need improvement and helping you optimize performance. API Playground The API Playground in Nuxt DevTools v1.0 is like a sandbox where you can play and experiment with your app's APIs. It's a space where you can easily test and try out different things without affecting your main app. This makes it a great tool for trying out new ideas or checking how changes might work. Some other cool features Another amazing aspect of Nuxt DevTools is the embedded full-featured VS Code. It's like having your favorite code editor inside the DevTools, with all its powerful features and extensions. It's incredibly convenient for making quick edits or tweaks to your code. Then there's the Component Inspector. Think of it as your code's detective tool. It lets you easily pinpoint and understand which parts of your code are behind specific elements on your page. This makes identifying and editing components a breeze. And remember customization! Nuxt DevTools lets you tweak its UI to suit your style. This means you can set up the tools just how you like them, making your development environment more comfortable and tailored to your preferences. Conclusion In summary, Nuxt DevTools v1.0 marks a revolutionary step in web development, offering a comprehensive suite of features that elevate the entire development process. Features like live updates, easy navigation, and a user-friendly interface enrich the development experience. Each tool within Nuxt DevTools v1.0 is thoughtfully designed to simplify and enhance how developers build and manage their applications. In essence, Nuxt DevTools v1.0 is more than just a toolkit; it's a transformative companion for developers seeking to build high-quality web applications more efficiently and effectively. It represents the future of web development tools, setting new standards in developer experience and productivity....

3 VueJS Component Libraries Perfect for Beginners cover image

3 VueJS Component Libraries Perfect for Beginners

For developers checking out VueJS for the first time, the initial steps are overwhelming, particularly when setting up projects from square one. But don’t worry! The VueJS ecosystem offers a plethora of remarkable component libraries, easing this early obstacle. These three libraries are pre-built toolkits, providing beginners with the means to kickstart their VueJS projects effortlessly. Let’s take a look! Quasar Quasar is among the most popular open-source component libraries for Vue.js, offering a comprehensive set of ready-to-use UI components and tools for building responsive web applications and websites. Designed with performance, flexibility, and ease of use in mind, Quasar provides developers with a wide range of customizable components, such as buttons, forms, dialogs, and layouts, along with built-in support for themes, internationalization, and accessibility. With its extensive documentation, active community support, and seamless integration with Vue CLI and Vuex, Quasar empowers developers to rapidly prototype and develop high-quality Vue.js applications for various platforms, including desktop, mobile, and PWA (Progressive Web Apps). PrimeVue PrimeVue is a popular Vue.js component library offering a wide range of customizable UI components designed for modern web applications. Developed by PrimeTek, it follows Material Design guidelines, ensuring responsiveness and accessibility across devices. With features like theming, internationalization, and advanced functionalities such as lazy loading and drag-and-drop, PrimeVue provides developers with the tools to create elegant and high-performing Vue.js applications efficiently. Supported by clear documentation, demos, and an active community, PrimeVue is an excellent choice for developers seeking to streamline their development process and deliver polished user experiences. Vuetify Vuetify is a powerful Vue.js component library that empowers developers to create elegant and responsive user interfaces with ease. Built according to Google's Material Design guidelines, Vuetify offers a vast collection of customizable UI components, ranging from buttons and cards to navigation bars and data tables. Its comprehensive set of features includes themes, typography, layout grids, and advanced components like dialogues and sliders, enabling developers to quickly build modern web applications that look and feel polished. With extensive documentation, active community support, and ongoing development, Vuetify remains a top choice for Vue.js developers seeking to streamline their workflow and deliver visually stunning user experiences. For newcomers venturing into Vue.js, the initial setup might seem daunting. Thankfully, Vue.js offers a variety of component libraries to simplify this process. Quasar, PrimeVue, and Vuetify are standout options, each providing pre-built tools to kickstart projects smoothly. Whether you prefer Quasar's extensive UI components, PrimeVue's Material Design-inspired features, or Vuetify's responsive interfaces, these libraries cater to diverse preferences and project requirements. With their clear documentation and active communities, these libraries empower developers to start Vue.js projects confidently and efficiently, enabling Vue developers to create polished user experiences....

Authentication with @this-dot/vue-route-guard cover image

Authentication with @this-dot/vue-route-guard

@this-dot/vue-route-guard is a Vue library that wraps around the vue-router and extends it to provide helpful methods to handle page guards via token authorization and permissions. Authentication Over the years, web applications have always had authenticated (available to authorized users) and unauthenticated (available to anyone) pages. The most common authentication method used in web applications is the token based authentication. This involves sending some user details to an API (backend), then receiving a token that is stored on the users computer and associated with the web application. When user tries to access an authenticated page before they are logged in, the user is redirected to page where they can get authenticated. There are different things to consider while building a web authentication system, including the type of storage for persisting tokens, pages that need authentication, user roles, and redirect paths. This process can get more complex depending on the application. To help with this, we can use vue-route-guard. It helps us with: ✅ Adding authentication guards to pages ✅ Supporting different storage options for storing token ✅ Storing and retrieving authentication data (user details and token) in a reactive state ✅ Exposes method for matching user permissions Our example application Let's set up an example application you can play with on Stackblitz here. The example application flow: A user who tries to access the /route-guard or /route-guard/about pages without authentication is redirected to the login page. After login, a user without the 'admin' role cannot access the /route-guard/about page and is redirected to /route-guard/no-permission if they try to navigate to it. How to use @this-dot/vue-route-guard Let’s dive in on how to use @this-dot/vue-route-guard First, we install the package with: npm install @this-dot/vue-route-guard or yarn add @this-dot/vue-route-guard Let’s set up the package as a plugin in our application: ` Next, we need to register the plugin in our main file. ` Now that we have setup the vue-route-guard package in our project, we need to update the router setup by adding requiresAuth and access to the meta object of each route in the web application. requiresAuth to pages that need authentication, it takes a boolean. for eample: ` access to pages that also require a role permission along with the authentication. It takes an array of strings, for example: ` For the set up we have in the example app, we added authentication to the ‘/route-guard’ path, and also added admin permission access to the '/route-guard/about' path. ` Using session storage to persist our token, the routes are authenticated and users can’t access certain pages without the right permissions with the setup above. Lets take an example of how to setup using cookie storage. ` Setting user authentication data We can set the user authentication data by importing useGuardand calling the method setToken with the token. Example: ` Check if user has access hasAuthenticationAccess can be accessed from useGuard, and called to check if user has a specific permission Example: ` Access authentication data We can access authentication data by importing useGuard getting the store state. Example: ` Clear Authentication We can clear authentication data by calling clearAuthentication from useGuard. Example: ` Refresh Authentication Refresh authentication calls fetch authentication and updates the state with the new authentication details. We can refresh authentication data by calling refreshAuthentication from useGuard. Example: ` --- Feel free to reachout if you have questions, feedback or want to contribute. You can reach out to us at opensource@thisdot.co. If you would like to check out the source code, feel free to visit our repository....

Understanding Sourcemaps: From Development to Production cover image

Understanding Sourcemaps: From Development to Production

What Are Sourcemaps? Modern web development involves transforming your source code before deploying it. We minify JavaScript to reduce file sizes, bundle multiple files together, transpile TypeScript to JavaScript, and convert modern syntax into browser-compatible code. These optimizations are essential for performance, but they create a significant problem: the code running in production does not look like the original code you wrote. Here's a simple example. Your original code might look like this: ` After minification, it becomes something like this: ` Now imagine trying to debug an error in that minified code. Which line threw the exception? What was the value of variable d? This is where sourcemaps come in. A sourcemap is a JSON file that contains a mapping between your transformed code and your original source files. When you open browser DevTools, the browser reads these mappings and reconstructs your original code, allowing you to debug with variable names, comments, and proper formatting intact. How Sourcemaps Work When you build your application with tools like Webpack, Vite, or Rollup, they can generate sourcemap files alongside your production bundles. A minified file references its sourcemap using a special comment at the end: ` The sourcemap file itself contains a JSON structure with several key fields: ` The mappings field uses an encoding format called VLQ (Variable Length Quantity) to map each position in the minified code back to its original location. The browser's DevTools use this information to show you the original code while you're debugging. Types of Sourcemaps Build tools support several variations of sourcemaps, each with different trade-offs: Inline sourcemaps: The entire mapping is embedded directly in your JavaScript file as a base64 encoded data URL. This increases file size significantly but simplifies deployment during development. ` External sourcemaps: A separate .map file that's referenced by the JavaScript bundle. This is the most common approach, as it keeps your production bundles lean since sourcemaps are only downloaded when DevTools is open. Hidden sourcemaps: External sourcemap files without any reference in the JavaScript bundle. These are useful when you want sourcemaps available for error tracking services like Sentry, but don't want to expose them to end users. Why Sourcemaps During development, sourcemaps are absolutely critical. They will help avoid having to guess where errors occur, making debugging much easier. Most modern build tools enable sourcemaps by default in development mode. Sourcemaps in Production Should you ship sourcemaps to production? It depends. While security by making your code more difficult to read is not real security, there's a legitimate argument that exposing your source code makes it easier for attackers to understand your application's internals. Sourcemaps can reveal internal API endpoints and routing logic, business logic, and algorithmic implementations, code comments that might contain developer notes or TODO items. Anyone with basic developer tools can reconstruct your entire codebase when sourcemaps are publicly accessible. While the Apple leak contained no credentials or secrets, it did expose their component architecture and implementation patterns. Additionally, code comments can inadvertently contain internal URLs, developer names, or company-specific information that could potentially be exploited by attackers. But that’s not all of it. On the other hand, services like Sentry can provide much more actionable error reports when they have access to sourcemaps. So you can understand exactly where errors happened. If a customer reports an issue, being able to see the actual error with proper context makes diagnosis significantly faster. If your security depends on keeping your frontend code secret, you have bigger problems. Any determined attacker can reverse engineer minified JavaScript. It just takes more time. Sourcemaps are only downloaded when DevTools is open, so shipping them to production doesn't affect load times or performance for end users. How to manage sourcemaps in production You don't have to choose between no sourcemaps and publicly accessible ones. For example, you can restrict access to sourcemaps with server configuration. You can make .map accessible from specific IP addresses. Additionally, tools like Sentry allow you to upload sourcemaps during your build process without making them publicly accessible. Then configure your build to generate sourcemaps without the reference comment, or use hidden sourcemaps. Sentry gets the mapping information it needs, but end users can't access the files. Learning from Apple's Incident Apple's sourcemap incident is a valuable reminder that even the largest tech companies can make deployment oversights. But it also highlights something important: the presence of sourcemaps wasn't actually a security vulnerability. This can be achieved by following good security practices. Never include sensitive data in client code. Developers got an interesting look at how Apple structures its Svelte codebase. The lesson is that you must be intentional about your deployment configuration. If you're going to include sourcemaps in production, make that decision deliberately after considering the trade-offs. And if you decide against using public sourcemaps, verify that your build process actually removes them. In this case, the public repo was quickly removed after Apple filed a DMCA takedown. (https://github.com/github/dmca/blob/master/2025/11/2025-11-05-apple.md) Making the Right Choice So what should you do with sourcemaps in your projects? For development: Always enable them. Use fast options, such as eval-source-map in Webpack or the default configuration in Vite. The debugging benefits far outweigh any downsides. For production: Consider your specific situation. But most importantly, make sure your sourcemaps don't accidentally expose secrets. Review your build output, check for hardcoded credentials, and ensure sensitive configurations stay on the backend where they belong. Conclusion Sourcemaps are powerful development tools that bridge the gap between the optimized code your users download and the readable code you write. They're essential for debugging and make error tracking more effective. The question of whether to include them in production doesn't have a unique answer. Whatever you decide, make it a deliberate choice. Review your build configuration. Verify that sourcemaps are handled the way you expect. And remember that proper frontend security doesn't come from hiding your code. Useful Resources * Source map specification - https://tc39.es/ecma426/ * What are sourcemaps - https://web.dev/articles/source-maps * VLQ implementation - https://github.com/Rich-Harris/vlq * Sentry sourcemaps - https://docs.sentry.io/platforms/javascript/sourcemaps/ * Apple DMCA takedown - https://github.com/github/dmca/blob/master/2025/11/2025-11-05-apple.md...

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Prefer email? hi@thisdot.co