Vite vs Webpack

title: Vite vs Webpack
date: 2022-06-06 10:28:00
toc: false
index_img: https://puep.qpic.cn/coral/Q3auHgzwzM4fgQ41VTF2rF1YCFdibQ9cyYktsNibicoKDA3PQPcYXddjA/0
category:

Front-end
tags:
Project
Files
Users
Services
Solutions
Issues
Printing

Why is Vite fast?#

When using webpack for project building, you may have encountered the following situation.

Let's assume that our project has two pages, A and B.

Page A is the homepage of the project and its code is working fine.

Page B is a page that can only be accessed through navigation and it contains some errors. For example, I import a file a.js that does not exist and then print a.

When we build this project, even though we have never accessed page B, webpack still throws an error saying Can't resolve './a.js' in xxx.

The reason for this problem is due to the building mechanism of webpack.

By default, webpack fetches and builds your entire application during development and build time before it can provide the service. This means that any error in your project (even if it occurs in a page that the user has never accessed) will still affect the entire project build.

Because of this, the larger your project becomes, the longer the build time will be, and the slower your project startup speed will be.

However, for vite, if we perform the same test, we will discover something interesting.

The same Can't resolve './a.js' in xxx error does not appear unless we enter page B. It only appears when we enter page B.

The reason for this is because vite does not build your entire project at the beginning. Instead, it separates the modules in the application into dependencies and source code. For the source code part, it splits the code modules based on the routes and only builds the necessary content at the beginning.

At the same time, vite provides the source code to the browser in the form of native ESM, allowing the browser to take over the packaging part of the work.

Because of this mechanism, no matter how large your project is, it will only build the necessary content at the beginning, greatly improving the speed of vite during the build process.

This is also a core reason why vite is fast.

Does this mechanism of Vite have any issues?#

If you are familiar with the building mechanism of ESM, you may notice a problem.

That is, since vite provides the source code to the browser in the form of native ESM and lets the browser take over the packaging part of the work, does it mean that it cannot handle commonJS content in our project?

Yes!

In the early versions of vite, this problem indeed existed, and the most significant trouble caused by this problem was that many dependencies could not be used.

For example, axios uses a lot of commonJS specifications, which makes vite unable to resolve the corresponding content (related issue), resulting in an error. This issue has also been intensively discussed in the vite issues.

Evan You also made a statement about this:

So how was this problem eventually resolved?

How did the official team solve this problem?#

Because this problem is very serious, vite later introduced the functionality of dependency pre-bundling, and one of its important purposes is to solve the CommonJS and UMD compatibility issue. Currently, vite will first convert the dependencies published in CommonJS or UMD format to ESM, and then recompile them. This can also be understood as a compromise between speed and business.