Frontend Tools are moving fast, and it can be hard to keep up, so here’s a thread about Webpack, Rollup, Parcel, Vite, TypeScript, SWC, ESBuild, Babel, Terser, Uglify, ESLint, prettier, ...
🧵
🧵
Let’s start with the 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 to add new functions.
The most popular JavaScript compiler is Babel (@babeljs 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 come SWC (@kdy1dev swc.rs) and esbuild (@evanwallace 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: built with performance in mind.
What about TypeScript (@typescript typescriptlang.org)? Well, the TS compiler is also capable of transforming JS/TS code into ES5 but has similar perf to Babel. SWC, esbuild and Babel won’t check your types, but you can compile with these tools and typecheck using tsc.
I think it’s a good transition to speak about ESLint (@geteslint 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 (@PrettierCode 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! prettier.io/docs/en/compar…
If during Code Reviews, people make comments on the formatting, please consider setting up a formatting tool such as prettier instead. Code review should focus on code readability, design, complexity, etc. But anything that can be automated should be.
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 and uglify. 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: github.com/privatenumber/…
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. Let’s talk about the tools: Webpack, Rollup, Parcel, esbuild, Vite and Snowpack.
The most popular bundler is Webpack (@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...
... During the development, you’ll have a webserver with HMR and source-map. Webpack is full of features, but the configuration is complex and it’s a bit slow.
Rollup (@RollupJS rollupjs.org) is focusing on the bundling part and has a different approach. This thread is already big, so here’s a good article on the subject: medium.com/webpack/webpac…. The tldr is: “Use webpack for apps, and Rollup for libraries”.
Parcel (@parceljs 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 (@geteslint eslint.org) 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.
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?
Snowpack (@snowpackjs snowpack.dev) and Vite (@vite_js vitejs.dev) are both 2 ESM based dev servers. The idea is simple: modern browsers now support ESM, so we can actually serve the modules directly to the browser without bundling!
The result is an extremely fast dev server. A comparison between the 2: vitejs.dev/guide/comparis…
Both Vite and Snowpack 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: vitejs.dev/guide/why.html…
And that’s it for my very first thread! I hope you’ve enjoyed it. If you like this kind of content, I'll write other threads. Feedback is very welcome!
Sorry, wrong link: esbuild.github.io
• • •
Missing some Tweet in this thread? You can try to
force a refresh
