Overview of the current and next-gen frontend development tools
Tags: javascript, webdev, typescript, webpack
Published: 2022-11-08 23:49:32

Frontend Tools are moving fast, and it can be hard to keep up! In this article, I will give a short description of Webpack, Rollup, Parcel, Vite, TypeScript, SWC, ESBuild, Babel, Terser, Uglify, ESLint, prettier, Rome tools...

## Transpilers/Compilers

The JavaScript language is evolving a lot but in order to support old browsers, we need to make some transformations (for new syntax) or add polyfills/ponyfills to add new functions.

The most popular JavaScript compiler is [Babel](babel.dev). It supports the very latest ECMAScript features and it is clearly the most mature JavaScript Compiler available. But, some people started to think that it was too slow...

So here comes [SWC](swc.rs) and [esbuild](esbuild.github.io). These tools claim to be between 10x and 100x faster than Babel. But how?
- 1st reason: Babel is written in JavaScript, a single-threaded interpreted language. SWC is written in Rust and esbuild is written in Go. By using these languages, it's possible to have a faster code and to heavily use parallelism. 
- 2nd reason: they have been built with performance in mind from the beginning. They use optimized data structures and they don't need to support very old versions of JavaScript.

## TypeScript

[TypeScript](https://www.typescriptlang.org) extends JavaScript by adding types to the language. It may looks a bit scary at the beginning because it adds some syntax and you'll have the feeling to develop more slowly at the beginning.
In practice, TypeScript speeds up your development experience by catching errors and providing fixes before you even run your code. Your IDE will offer a much better completion by knowing the type of the objects you're manipulating. For serious projects, I wouldn't go back to JavaScript.

What about the performance? Well, the TS compiler (tsc) is also capable of transforming JS/TS code into ES5 but has similar perf to Babel. It's possible to use SWC, esbuild and Babel for TypeScript but it won't check your types. However, it's possible to use these tools and do the type checking with tsc.

## Linters and Formatters

I think it's a good transition to speak about [ESLint](eslint.org). ESLint is a linter that helps identifying and fixing potential issues with your code. It can be formatting issues but it can also be used to enforce some rules to avoid potential bugs.

ESLint is often compared to [prettier](prettier.io) because it can be used as a code formatter: you define formatting rules and then use the autofix feature to correct the code, when possible. However prettier has a different approach: you set formatting options and it gets rid of the original styling and reformats everything. [It's possible to use prettier to format the code and ESLint to enforce other coding rules!](https://prettier.io/docs/en/comparison.html) It's actually the most popular option nowadays.

Guess what, people also started to complain that ESLint and Prettier were too slow on big projects. And the new kid in town is [Rome Tools](rome.tools). Rome Tools ambitions to be a linter, formatter, bundler, etc. For now, only the Linter and Formatter seems to be usable and clearly the project is a bit too young to be used on production projects. But I've tested their Linter on a big project and for the comparison, ESLint takes almost a minute while Rome takes less than a second. The comparison isn't entirely fair because the lint rules were different though, but it's still impressive.

If during Code Reviews, people make comments on the formatting, please consider setting up a formatting tool such as prettier instead. Same for the lint. Code review should focus on code readability, design, complexity, tests, etc. But anything that can be automated should be.

## Minifiers

Before we move on to Frontend Bundlers, a quick word about minifiers. A JS minifier reduces the code length by removing unnecessary code (comments, block delimiters, variables too long, etc.) without altering its functionality. The main goal is to make the website load faster.

There are many minifiers such as [terser](https://terser.org/) and [uglify](https://lisperator.net/uglifyjs/). But, because minifying also require to parse the JS, it is actually possible to use esbuild and SWC to minify the code. [Here's a benchmark of the main minifiers.](https://github.com/privatenumber/minification-benchmarks)

## Bundlers and Dev Servers

Let's now talk about the frontend build tools, which are meant to make your life easier during development but also to generate the build artifacts that you will host somewhere. I will cover the following tools: Webpack, Rollup, Parcel, esbuild, Vite and Turbopack.

The most popular bundler is [Webpack](webpack.js.org). It is highly customizable, it will bundle your JS files but also your other assets using loaders (CSS, images, etc.), do some tree-shaking and minify everything. It's also a dev server: during the development, you’ll have access to a webserver with HMR and source-map. Webpack is full of features, but the configuration is a bit complex and it's a bit slow. Tools such as Create React App (for React projects) can help to start with a pre-configured webpack configuration.

[Rollup](rollupjs.org) is focusing on the bundling part and has a different approach. This article is already big, so here’s a [good article](https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c) on the subject. The tldr is: "Use webpack for apps, and Rollup for libraries".

[Parcel](parceljs.org) is meant to be a zero configuration web application bundler. It has a dev server with hot-reload and everything. This should work great for most projects, I recommend you give it a try. Oh, and it’s based on SWC, so it’s fast!

[esbuild](esbuild.github.io) is not only a compiler but also a bundler with tree-shaking, source-map, minification, etc. However, this project is young and esbuild is mainly used for the compilation, for now.

More recently, [Vercel announced Turbopack](https://vercel.com/blog/turbopack). Behind it we can find the creator of Webpack, so it's clearly a serious candidate. And their secret  for being faster is also to use tools developed in Rust.

And now, let’s talk about the no-bundlers solutions. I've presented you several bundlers, but I haven't told you why we need them. We need to bundle for production builds when we want tree-shaking, lazy-loading, chunk splitting and support of old browsers... But do we really need to bundle the app during the development phase?

[Vite](vitejs.dev) is an ESM-based dev server. The idea is simple: modern browsers now support ESM, so we can actually serve the modules directly to the browser without bundling!

Vite will compile the code using esbuild and they are able to bundle your app using rollup. Even though esbuild could also bundle the app, [they decided not to use it](https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuild).

## Conclusion

As you can see, there are many new tools coming up and it's very exciting to see how fast they are. Nevertheless, I would still recommend using tools such as Babel, TSC, Webpack, ESLint and Prettier for most projects. The reason is that they are stable and full of features. Even though they are a bit slow, they do the job.

I've experimented most of the tools I'm describing on side-projects or as a replacement in projects I have at work. I'm impressed by their speed, but I also realized that the time needed to bundle an app isn't only the time needed to transpile the code. I've tested using SWC instead of Babel in a project that takes 5 minutes to be built. Turns out, most of the time was actually spent compressing images through webpack loaders. Using caches was way more efficient.

I know, I've presented a ton of exciting new tools and my conclusion is that they shouldn't be used yet. Let me be clear, frontend tools are evolving so fast that this advice will be deprecated in 6 months. So, follow these tools and watch their adoption and change logs.