During the Spring Festival, Yu Creek announced the official release of Vite 2.0 in a series of moves, so let’s take a look at what is the difference between the next generation of front-end build tools and the current build tools?

Vitejs.dev /guide/why.h…

First of all, why was Vite born?

Why do YOU need a packaging tool?

In today’s front-end engineering, the front-end technology stack is increasingly rich, supporting more and more tools, in order to improve the front-end development efficiency of a variety of frameworks are emerging in an endless stream.

However, as front-end projects get bigger and bigger, there are more and more dependencies that have their own dependencies, which can result in a huge dependency tree. If you open a project’s node_modules directory, you can easily find hundreds of folders. In addition, JavaScript has no module system until now, so the community has developed some methods for loading modules, but different dependencies use different methods. Browsers do not support these loading methods, so our JS code can only be packaged to run in the browser, so previous front-end development has always needed packaging tools.

Packaging tools help us with front-end engineering, but as we rely on more and more, we can package and build more and more slowly, and if we change code during development, we can lose the work we are currently working on during hot updates. Vite was created to solve these problems.

Without a doubt, two of the most attractive features of vite are:

  • Extremely fast cold start speed
  • Extremely fast hot update speed

As we know, modules have been added to ES6 so that there is a common file loading standard that browsers can use to load our code, thus making front-end development more efficient.

Why is Vite better than modern build tools at cold start and hot update performance?

Cold start

Webpack, for example, when we type NPM run into the command line to start the project, WebPack needs to read out our dependencies and package them into a javascript file that a browser can recognize before our server is actually available. But dependencies are tree-like, and we know that the deeper the tree is, the more overhead the traversal becomes, which is the main reason webPack is not efficient at hot updates and cold launches.

Taking a look at the diagram on vite’s website, WebPack needs to collect dependencies based on the file entry we provide (the dependency tree is too deep, so WebPack does a lot of work to load on demand), then package the output files that the browser can recognize, and then our front-end server really starts to work

According to the figure on the official website of Vite, Vite accepts the URL of the browser to identify the required dependencies. Because Vite is targeted at the ES Module (collectively referred to as ESM), the ES Module can be directly recognized by the browser. Therefore, after entering the command, the project does not need to be packaged. And can return JS code according to the URL required file, so that the real load on demand. For non-ESM code, vite is converted to ESM code.

Because Webpack is to package the JS code, when the request is received directly back to the browser (often a request can get all the NEEDED JS code for the browser to execute, too much code will be split into several files), while Vite is to find the code after receiving the request, and rely on a lot, The browser may need to load a lot of JS files, which may have to send many requests to get all the JS code, will this cause network fluctuation? Is it possible that the page takes too long to load?

In this case, Vite does an optimization called pre-bundle when the request is received, which is

  • Convert non-ESM JS code to ESM code
  • Return a dependency as a single JS file to the front-end (rather than each file being returned separately, for example lodash-es, which has over 600 internal modules, will only return lodash-es, which contains all internal modules) to avoid network volatility. Excessive use of network ports (here we put the packaged code under node_modules/.vite/)
  • In the request js code to join the cache information in the HTTP request header, browser cache
  • For Monorepo, Vite also introduces dependent projects via esM

Hot update

In hot updates, webPack is a tree dependency, so every node in it changes and its ancestor nodes need to be recompiled and loaded (which actually feels more expensive in the application than you might think). And the original state of the page is lost as hot updates cause the page to reload. (The specific principle needs to be further studied)

While vite is based on ESM, a node changes. In most cases, you just need to request the node again. We know that O(1) and O(n) in the algorithm are very different. And when Vite is hot updated, it adds cached information to the request header, and the server returns 304 for unmodified files, largely avoiding unnecessary reloads

Vite’s other abilities

typescript

Vite only performs translation of. T files and does not perform any type checking (make sure that ts errors are handled). Vite uses esbuild to convert TypeScript to JavaScript, about 20 to 30 times faster than TSC

ssr/ssg

Vite’s official website is very clear that vite SSR (server rendering) and SSG (static page generation) features are not stable, and because the author of these two are not how to understand, so temporarily not introduced

sass/less

Vite supports CSS preprocessors such as LESS and sass. If you add. Module to a CSS file, Vite will recognize the CSS file as a module, so you can use CSS as an object.

./index.js

import style from './style.module.scss';
<div className={style['home__title']} / >

./style.module.scss
.home__title {
    color: red;
}
Copy the code

pre-built

There are two main purposes here

  1. Performance: Many dependencies, such as the 600+ JS files in LoDash, will incur HTTP overhead (such as unnecessary HTTP headers) if requested one by one, so the prebuild will be composed of one request.

2. Translate CJS and UMD specification code.

The file cache

To optimize development-time performance, Vite does two caches.

During prebuild, prebuild products are stored in the local file system, so that even if the computer is shut down, the next restart does not need to be prebuilt, saving the time of cold boot.

When the browser requests the JS file, the cache information is added in the request header. As long as the JS file is not changed, the browser does not need to request the file again, saving the time of network requests.

Production build of Vite

Vite currently offers production builds that are packaged and released through rollup, which means that vite’s benefits can only be leveraged at development time, and Vite doesn’t consider an ESM-based build to be suitable for production.

The Vite website points out that ESM applies to a production problem, which is HTTP request overhead. A project can easily involve hundreds or thousands of JS files, and using the ESM request-by-request approach will incur unnecessary overhead.

So why not use esbuild for production packages? (EsBuild is an ESM-based packaging base that is faster than WebPack.)

Esbuild deals mainly with JS and TS files, has problems with CSS handling, and esBuild is not as good at code splitting as Rollup, so the packaging is left to the more mature Rollup.

Vite contrast snowpack

Snowpack is an es Build-based building tool that predates Vite, and vite has some design references to Snowpack. But vite has the following advantages:

  • Multi-exit support, in other words, Vite can package multiple output files at the same time, which makes sense for multi-entry page applications
  • Patterns that can be packaged as libraries (after all, not all projects are designed to output HTML, for example vue is designed to output vuejs)
  • Automatically split CSS code
  • Asynchronous block loading optimization
  • Compatibility with older browsers

The production build of Vite is packaged based on rollup, while Snowpack allows users to decide whether to use webPack, rollup or other build tools. I feel that You really like rollup, because VUe3 also uses this tool, so THERE is a chance to learn it.

One final comment: Vite and Snowpack, in my opinion, are not that different. But using Vite means that the configuration that WebPack now packages will have to be changed, and perhaps even the pipeline of packaging will have to be changed, raising the bar to use Vite in a way that may block the adoption of Vite. After all, whether a technology can be popularized depends first on the needs of the market, then on the threshold of getting on the bus and community ecology. However, vite has a natural advantage in that the name of Yu Yu Stream can help it gain more exposure and attract more attention, but the practical application still needs to be pushed by the Yu Yu Stream team.