2020 is too difficult, finally wait for the New Year’s Day can have a holiday to rest for a few days, idle browsing weibo, and then, received a gift from the United States:Vite2.0;

Are you shocked! Vite2.0 as a New Year’s eve gift, I’m really impressed. Can’t you play video games and watch TV during your vacation?

When I saw the update, I couldn’t help but go to the official documentation and read it for a few days. When I was almost finished reading the documentation, the news came that 10 beta had been submitted in 3 days.

Come on, we also feel especially big devil update speed… A thousand miles a day

What is the magic of Vite?

Vite (French word for “fast”) is a new kind of front-end build tool; It was originally used with Vue3.0, and later adapted to various front-end projects. Currently it provides Vue, React, and Preact framework templates.

React uses create-React-app scaffolding. Although the scaffolding tool is different, the internal packaging tool is webpack.

Why develop a brand new build tool, is Webpack not cool? What is the difference between a project built using Vite and a project built using Webpack? The emergence of a new tool must be to solve the problems existing in the existing tool, otherwise the new tool has no value and significance.

What problems does Vite solve with Webpack?

To figure this out, we need to figure out what WebPack is. Most people’s first impression is “packaging tools”, so why does the front end need a packaging tool? What were the problems with front-end development before packaging the tools? Do we really need packing tools?

With the development of the Internet, front-end projects become more and more complex. At the same time, V8 engine also makes JavaScript, the toy language, plug in the wings of commercial project development, so that JS is no longer constrained by the browser environment, and begins to enter the field of system-level development. As the complexity of the project is upgraded, the code specification and management must be synchronized. Therefore, a variety of modular specifications are put forward in the programming community. CommonJS specifications are selected for the server, and AMD specifications are selected for the client. Having two different modularity specifications is not enough at the JS language level;

Finally, in ES6, the ECMA Committee introduced a language-level module system: ES Modules specification;

In the current programming practice, front-end programming benefits from the development of building tools, the coding process using ES Modules specification is very widespread, but the back-end is still using CommonJS specification more, but NodeJS has made changes, gradually tends to ES Modules specification;

Let’s take a quick look at the syntactic features of ES Modules with a little codeModularization can help us better solve the problem of code organization in the process of complex application development, but with the introduction of modularization, some new problems will arise in our front-end application, such as:

First of all, the ES Modules system we use has its own environmental compatibility problems. Although the latest versions of major browsers support this feature, there is no guarantee that users will use it. So we also need to solve the compatibility problem.

Secondly, the modular way is divided into too many module files, and the front-end application is running in the browser, each file needs to be individually requested from the server back. Scattered module files will inevitably lead to frequent network requests from the browser, affecting application efficiency.

Finally, talk about the divergence on the basis of implementing JS modularization. With the increasing complexity of applications, it is not only JavaScript code that needs to be modularized, but also HTML and CSS resource files that need to be modularized during front-end application development. And from a macro point of view, these files should also be considered modules in the front-end application, but these modules have different types and uses than JavaScript.

Modularity is definitely necessary for the development process, so we need to introduce better solutions or tools on top of the modularity implementation mentioned above to solve the three problems mentioned above.Let our applications continue to enjoy the benefits of modularity during development without worrying about the impact of modularity on the production environment. As you can imagine, this is where a series of packaging tools like WebPack come in. The above questions are at the core of these tools.

In essence, Webpack is a static Module bundler for modern JavaScript applications.

Vue scaffolding tool VUE-CLI uses Webpack for packaging, development can start the local development server, real-time preview, because the whole project file needs to be packaged, the development server starts slowly

The same problem exists for hot update HMR after file modification at development time;

Hot updates to Webpack are rebuilt and packaged with the current modified file entry, and all dependencies involved are reloaded once

Vite solves both of these problems well. First comePacking problem, Vite only start a static page of the server, the file code is not packaged, the server will be based on the client request, load different module processing, to achieve the real on-demand loading;

For hot updates, Vite compiles the modified file immediately, and uses a caching mechanism (HTTP caching => Vite built-in caching) to load the updated file content

Therefore, Vite has a fast cold start, on-demand compilation, module hot update and other excellent characteristics;

To sum up, vite build projects and VUE-CLI build projects mainly lie in the development mode, the difference is relatively large:

1: Vite can run directly in development mode without packaging, using ES6 modular loading rules; Vue-cli development mode must be packaged for the project to run;

2: Vite hot update based on cache, vue-CLI hot update based on Webpack said so much, Vite should be used in the end?

Vitejs.dev /guide/; Let’s just use it briefly

Make sure the Node version is 12 or greater;

Using the NPM command:

$ npm init @vitejs/app
Copy the code

Alternatively, run the Yarn command:

$ yarn create @vitejs/app
Copy the code

After the command is executed, we will be asked to choose which kind of framework project to build, so I chose VUE directly hereIf you don’t want to choose from the command line, you can specify a specific template

$ npm init @vitejs/app my-vue-app --template vue
Copy the code

Note that either build requires a second installation of the third-party extensions needed to run the project, just by downloading the project code template;

Go to the project directory, install the required dependencies, and start the project:

  cd  <my-project>
  npm install (or `yarn`)
  npm run dev (or `yarn dev`)
Copy the code

From the package.json file, we can see the commands to start and package

Start the development server with the NPM run dev command:

View the run result:

Build the project using the NPM run build command:

It should be noted that after the successful construction of the code is a static resource file, in the local still need to provide a static server to run; That’s the end of the experience. If you want to feel the speed of the devil update, you can go to Github: github.com/vitejs/vite