background

In the last article we analyzed why Esbuild is so fast.

And the data:

You can see: Esbuild is riding the dust and leading by a landslide.

But look at the bottom, and it’s the webPack we’re most familiar with.

So why was webPack’s build slow? What’s slower?

Here are some of my thoughts, to share with you, I hope to help you.

The body of the

First let’s take a look at the general process of webPack construction:

The process takes a long time.

So where are the performance bottlenecks in the whole process?

I think it is mainly in the following two stages:

  1. The code to build
  2. Code compression

Let’s look at them separately.

1. Code building

One of the most important things to do during code construction is to do Module dependency analysis to generate the Module Graph.

This part has a very complicated process.

This part is very complicated and time-consuming.

Therefore, Webpack also designed corresponding algorithms to optimize this part, and those who are interested can go to study.

This part of the detailed analysis, there is a good video, interested can go to see:

Back to building.

Modern browsers are getting better and better at supporting ESM, and the work of module dependency analysis can be done by browsers.

Also, many of the browser’s package analysis tools are written in C/C++, which is obviously much faster and more advantageous than WebPack’s use of JS to analyze the entire dependency graph.

2. Code compression

The most mature JS compression tool is UglifyJS.

It will analyze the JS code syntax tree, understand the meaning of the code, so that it can do such as: remove invalid code, remove the log output code, shorten the variable name optimization.

Webpack uses compression plug-ins to do this.

Among them: Webpack uses Terser, which is written in JS, derived from the original Uglyfy.js, which is feature-rich but very, very slow.

This is one of the reasons why WebPack is slow.

However, for code compression, Vite also chooses Terser.

This is described in the documentation:

  • build.minify:

    • Types: Boolean | ‘terser’ | ‘esbuild’
    • Default: ‘terser’

Set to false to disable obfuscation minimization or to specify which obfuscator to use.

The default is Terser.

Although Terser is relatively slow, in most cases the resulting files are smaller.

ESbuild minimizes obfuscation faster, but builds files that are relatively large.

For more information: cn.vitejs.dev/config/#bui…

Plus, if you’re paying attention, you’ll notice this:

  1. Esbuild, useGOWrite.
  2. SWC, is to useRustWrite.

None of it is written in JS.

Future front-end compilation tools will probably Go in this direction, either in Go or Rust, rather than js for something that can cause performance bottlenecks.

One more point needs to be mentioned.

In the graph at the beginning of this article, it looks like webpack5 is slower than webpack4:

But that doesn’t mean WebPack 5 is bad, don’t get me wrong.

There are a lot of optimizations in WebPack 5, and a lot of historical baggage has been shed.

There are some new features and very useful ones, such as:

  • Module Federation
  • Real Content Hash

As you can imagine, the Webpack team has made a lot of efforts, ❤️.

conclusion

This article, is midnight suddenly thought, spent two hours to write.

I hope to inspire you. Thank you.