This week’s intensive reading article is Comparing the New Generation of Build Tools.

There are a number of new tools in front-end engineering that use new or cross-domain technologies to achieve breakthroughs, so it’s important to know what features these tools have and whether they can be put into production.

Usage and support details are not covered here because the text is verbose, but you can read the text for more details.

Intensive reading

According to the package granularity from bottom to top, in the order of esbuild, Snowpack, Vite, AND WMR.

esbuild

Esbuild is written in the Go language, which is more low-level than Node and does not provide AST operation capability, so the code execution efficiency is higher. According to the official benchmark, the speed is 10 ~ 100 times:

Esbuild has two main functions, bundler and minifier. Bundler is used for code compilation, similar to Babel-loader and TS-loader. Minifier is used for code compression, similar to Terser.

Compile code using esbuild as follows:

esbuild.build({
  entryPoints: ["src/app.jsx"].outdir: "dist".define: { "process.env.NODE_ENV": '"production"' },
  watch: true});Copy the code

However, because Esbuild cannot operate AST, some Babel plug-ins that need to operate AST cannot be compatible with it. As a result, production environments rarely use EsBuild bundler modules directly.

Fortunately, the Minifier module can be used as a direct replacement for Terser and can be used in production environments:

esbuild.transform(code, {
  minify: true});Copy the code

Because ESBuild sacrifices some package size for higher execution efficiency, the compressed package size is slightly larger, but the difference between 177KB and 165KB is negligible.

Esbuild is low-level, so it can be used in conjunction with the upper-layer build tools that follow, although whether and to what extent they are built in, and whether plug-ins are allowed to replace them, depending on the tool’s design philosophy, is another matter.

snowpack

Snowpack is a relatively lightweight solution to Bundless, which I wrote a close look at earlier. Bunpack is a solution to use the browser-supported ESM import feature to load dependencies between modules in the browser, rather than at compile time.

Skipping the compile-time dependency on loading saves a lot of work, such as tree shaking and caching for end-product acceleration, and leaves the work to the final executing browser, which, as the final runtime container, knows better than the compile-time tool how to load on demand.

In terms of compile time alone, the compile speed of a single file is related to the overall size of the project, and without the overall project, the compile time of a single file (at most recursively a limited number of dependent modules, solving problems such as TS variable determination) must be O(1).

In fact, we rarely use Snowpack on its own, because the esbuild it uses is not stable version 1.0, which is a risk for ecological compatibility and product stability, so it is often packed with rollup or WebPack. However, this split also leads to inconsistency between development and production environments. This often represents a greater risk, so you can see this trade-off in the Vite framework.

Snowpack is out of the box:

// package.json
"scripts": {
  "start": "snowpack dev"."build": "snowpack build"
},
Copy the code

We can also add snowpack.config.js configuration file to enable remote mode:

// snowpack.config.js
module.exports = {
  packageOptions: {
    "source": "remote",}};Copy the code

Remote mode is Streaming Imports, that is, instead of installing the corresponding NPM package locally, Snowpack automatically reads the file from Skypack and caches it.

Snowpack seems to be more of a pure attempt at Bundless than a tool suitable for daily development, which requires a one-stop tool, vite and WMR.

vite

Snowpack features a one-stop build tool to help you through the entire process from development to release.

There are many usages involved, and you can see the official documentation for details.

Unlike Snowpack, which produces packaged products as separate files, Vite does not use esbuild but rollup packaging, in order to package as a whole and avoid the risk of esbuild instability.

In addition, vite has many more features than Snowpack due to its higher integration, such as CSS split, multi-page, dependency prebuild using ESBuild, Monorepo support, support for multiple frameworks, SSR, and more. Please refer to the documentation for details. However, this has both advantages and disadvantages, the advantage is out of the box, the disadvantage is the lack of flexibility to customize.

In fact, the main revolutionary breakthrough was Bundless, which developed a series of convenient functions that every engineering team should learn from. Even if you decide to create a new wheel, you’ll need to keep 90% of the features the same, with a few tweaks to the default preferences, most of which can be solved with plug-ins.

All in all, Vite is an engineered bucket that embraces new features and considers the production environment, while tools that are too advanced on the tech stack can only be called toys, and Vite is actually usable.

wmr

Developed by preact authors, it can be interpreted as preact’s version of Vite. So it’s much friendlier and more integrated for developers of the Preact stack.

Another feature mentioned in the article is that WMR uses the HTM transform JSX, giving it a more accurate error reporting experience, which is accurate to the source line while specifying specific columns.

The comprehensive function is similar to vite, single page + SSR support, if you usually use Preact, or want to develop a small volume of projects, you can consider using WMR bucket.

conclusion

The new generation of front-end building tools features two major features: lower-level programming, Bundless, and, in a word, high performance. Embracing browser features or knowledge that crosses boundaries can help break new ground on the front end.

Build tools have also become more and more integrated, from compile-only ESBuild, to developing-enabled Snowpack, to built-in best practices and even back-end capabilities like SSR, to vitePress for vertical scenarios, with each abstraction more out of the box. But the reduced flexibility that comes with it is also a reason for teams to build their own wheels, and the higher up the ladder, the more motivated they are to build their own wheels.

This is very similar to the field of visualization, from the lowest level of SVG, Canvas, WebGL to the command framework based on its encapsulation, to data-driven development framework, fully JSON configuration chart library, even to zero configuration, intelligent projects based on data guess configuration, configuration is less and less, but less flexible. What level of completeness is used depends on the details required by the project.

However, engineering is relatively standardized, because visualization is for users, while engineering is for programmers. We cannot control users’ needs, but we can control programmers’ development habits :P.

Finally, in addition to upgrading your co-build tools, switching to an M1 chip PC can also greatly improve the development efficiency, I personally tested webPack build speed increased by 3 times!

The discussion address is: intensive reading “Comparison of the New Generation of Front-end Building Tools” · Issue #316 · DT-fe /weekly

If you’d like to participate in the discussion, pleaseClick here to, with a new theme every week, released on weekends or Mondays. Front end Intensive Reading – Helps you filter the right content.

Pay attention to the front end of intensive reading wechat public account

Copyright Notice: Freely reproduced – Non-commercial – Non-derivative – Remain signed (Creative Commons 3.0 License)