Building Web Apps with Bundlers

In the previous chapter, we covered an important set of auxiliary tooling – linters and formatters. While code quality is important, the undoubtedly most important aspect of every project is what is shipped and used by the customer. This is the area where a special kind of tooling – called bundlers – shines.

A bundler is a tool that understands and processes source code to produce files that can be placed on a web server and are ready to be consumed by web browsers. It takes HTML, CSS, JavaScript, and related files into consideration to make them more efficient and readable. In this process, a bundler would merge, split, minify, and even translate code from one standard such as ES2020 into another standard such as ES5.

Today, bundlers are no longer nice to have, but necessarily used for most projects directly or indirectly. Pretty much every web framework offers tooling that is built upon a bundler. Often, the challenge is...

Technical requirements

The complete source code for this chapter is available at https://github.com/PacktPublishing/Modern-Frontend-Development-with-Node.js/tree/main/Chapter06.

The CiA videos for this chapter can be accessed at https://bit.ly/3G0NiMX.

Understanding bundlers

Writing a modern web application is quite difficult. One of the reasons for the level of difficulty is the large variety of different technologies that need to be involved in the process. Let’s just mention a few:

• HTML for writing documents
• CSS for styling those documents
• JavaScript with the DOM API to bring some interactivity
• A JavaScript UI framework to create interactive components
• A CSS preprocessor to use variables, nesting, and more features for CSS
• Potentially TypeScript or some other typed system to improve reliability in certain source code areas
• Service and web workers need to be mastered
• All static files should be easy to cache

Before the introduction of a new class of tooling that was capable of building up module graphs, dedicated task runners such as Grunt or Gulp were used. These runners were inspired by more generic approaches such as Makefiles. The problem, however, was that two aspects –...

Comparing available bundlers

There are multiple generations of bundlers. The first generation was centered around the belief that Node.js applications are the only kind of applications that should be written. Therefore, changing these applications into JavaScript files that work in the browser has been the primary concern of the bundlers from that generation. The most popular one in that category is Browserify.

The second generation went on to extend the idea from the first generation to pretty much all JavaScript code. Here, even HTML and CSS assets could be understood. For instance, using @import rules in CSS would extend the module graph to another CSS module. Importantly, while the CommonJS (or later on, ESM) syntax was still used to derive the JavaScript module graph, these second-generation bundlers did not care about Node.js. They always assumed that the code was written for the browser. Quite often, however, you could change the target and also bundle code for Node.js with...

Using Webpack

Webpack is presumably the most popular option among the available bundlers. It is also among the oldest bundlers – dating back to a time when Node.js was still young and the whole idea of bundling was rather new. At this time, task runners were still dominantly used. However, the increasing complexity of frontend development opened the door for much more elaborate tooling.

One thing that makes Webpack stand out is its ecosystem. From the very beginning, Webpack decided to develop only a very shallow core focusing on module resolution. In some sense, Webpack is just the wrapper holding all these plugins together with a fixed plan of execution. It pretty much combines the configuration that was thrown in by the user, with the power of all the selected plugins.

Today, Webpack can also work without plugins or a configuration. At least in theory. In practice, every project that goes beyond some simple examples will require a bit of configuration. Also, interesting...

Using esbuild

esbuild is quite a new tool that focuses on performance. The key to esbuild’s enhanced performance is that it was written from the ground up in the Go programming language. The result is a native binary that has certain advantages over pure JavaScript solutions.

If esbuild stopped at providing a native solution, it would potentially not be qualified to make this list. After all, flexibility and the option to extend the original functionality are key for any kind of bundler. Luckily, the creator of esbuild has thought about this and come up with an elegant solution. While the core of esbuild remains native – that is, written in Go and provided as a binary – plugins can be written using JavaScript. This way, we get the best of both worlds.

To get started with esbuild, we need to install the esbuild package using npm:

$ npm install esbuild --save-dev

With this one installation, you can use esbuild programmatically, as well as directly from...

Using Parcel

When Parcel arrived in the community, the hype around it was massive. The reason for this was to be found in one new feature: configuration-free bundling. Parcel tried to leverage information that was already given in package.json – or configuration files written for specific tools such as Babel. Using this mechanism, the creators of Parcel thought to remove the complexity of configuring a bundler.

Ultimately, however, the whole aspect backfired in some sense. As mentioned previously, a bundler requires some flexibility. To achieve this kind of flexibility, a sound configuration system is necessary. While the configuration system of Webpack is a bit too verbose and complex, the one provided with esbuild might be a bit too low-level.

The successor of the original Parcel now also offers an optional configuration system, which tries to be right between the verbosity of Webpack and the low-level one of esbuild. This makes Parcel no longer configuration-free, but...

Using Vite

The latest addition to the set of popular bundlers is Vite. It combines a few existing tools – such as Rollup.js and esbuild – together with a unified plugin system to allow rapid development. Vite’s approach is to give you the power of Webpack at the speed of esbuild.

Originally, Vite was built by the creator of the frontend framework Vue. However, as time went on, Vite’s plugin system became a lot more powerful. With its increased API surface, other frontend frameworks such as React or Svelte could be supported. Now, Vite has evolved from a single-purpose tool to a real Swiss Army knife – thanks to a well-thought-out plugin mechanism with an active community.

To get started with Vite, we need to install the vite package using npm:

$ npm install vite --save-dev

With this installation, you can use Vite programmatically, as well as directly from the command line.

One thing to know about Vite is that it embraces having an index...

Summary

In this chapter, you learned what a bundler is, why you need it, what bundlers exist, and how you can configure and use them. You are now able to take your web projects from their raw source code to build production-ready assets.

Equipped with detailed knowledge about bundlers, you can create very reliable code bases that are tailored toward efficiency. Not only will unnecessary code be removed upon bundling, but also all referenced files will be processed and taken into consideration. Therefore, you’ll never have to worry about missing a file.

The large variety of existing bundlers can be intimidating at first. While there are some obvious choices, such as the very popular Webpack bundler, other options may be even better due to less complexity or better performance, depending on the project you have at hand. If in doubt, you can refer to the Comparing available bundlers section of this chapter to ascertain which bundler might be the best fit for you.

In the...