The definition of Vite
Vite (French word for “fast”) is a new front-end build tool, originally used with Vue3.0 and later adapted to various front-end projects, currently providing Vue, React, Preact framework templates. While Vue uses vuE-CLI scaffolding, React uses create-react-app scaffolding. The scaffolding tool is different, but the internal packaging tool is Webpack, why develop a new build tool, is Webpack not good? 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. **
Why Vite?
Practical problems
Before browsers supported the ES module, developers didn’t develop JavaScript’s native mechanics in a modular way. This is where the concept of “packaging” comes in: using tools to grab, manipulate, and link our source code modules into files that run in a browser.
Over time, we’ve seen the creation of tools like WebPack, Rollup, and Parcel that dramatically improve the development experience for front-end developers.
However, as we start building larger and larger applications, the amount of JavaScript code we need to process grows exponentially. It is not uncommon for large projects to contain thousands of modules. We started hitting performance bottlenecks — tools developed in JavaScript often took a long time (even minutes!). To start the development server, even with HMR, it takes a few seconds for the effect of the file changes to be reflected in the browser. Over and over again, slow feedback can have a huge impact on a developer’s productivity and happiness.
Vite aims to take advantage of new developments in the ecosystem: browsers are starting to support ES modules natively, and JavaScript tools are increasingly written in compiled languages
Problem one: Slow server startup
When cold starting the development server, the packager-based approach is to eagerly grab and build your entire application before serving it.
Vite improves development server startup times by initially separating application modules into dependent and source modules.
The dependencies are mostly pure JavaScript and do not change at development time. Some large dependencies, such as component libraries with hundreds of modules, are also expensive to handle. Dependencies are also often split into a large number of smaller modules in some way (such as ESM or CommonJS).
Vite will pre-build dependencies using esBuild. Esbuild is written using Go and is 10-100 times faster than a prepacker-built dependency written in JavaScript.
The source code usually contains files that are not directly JavaScript that need to be transformed (such as JSX, CSS, or Vue/Svelte components) and often edited. Also, not all source code needs to be loaded at the same time. (for example, code modules based on route splitting).
Vite serves source code in a native ESM way. This essentially lets the browser take over part of the packaging: Vite simply transforms the source code when the browser requests it and makes it available on demand. Code that is dynamically imported according to the situation is only processed if it is actually used on the current screen.
A comparison diagram of the two builds
Problem two: Slow updates
When started based on the packer, the file itself is rebuilt after editing it. Obviously, we should not rebuild the entire package, as the update speed would plummet as the application grew in size.
Some of the packer’s development servers store the build content in memory, so they only need to inactivate a portion of the module diagram when the file changes [1], but it still needs to rebuild the entire page and reload the page. This is expensive, and reloading the page eliminates the current state of the application, so the packer supports dynamic module hot reload (HMR) : allowing a module to “hot replace” itself without affecting the rest of the page. This greatly improves the development experience – however, in practice we have found that even HMR update rates decrease significantly as the application size increases.
In Vite, HMR is executed on native ESM. When editing a file, Vite only needs to precisely invalidate the chain between the edited module and its nearest HMR boundary (most of the time just the module itself), making HMR updates always fast, regardless of the size of the application.
Vite also uses HTTP headers to speed up whole page reloads (again letting the browser do more for us) : requests from source modules are negotiated in the Cache according to 304 Not Modified, while dependent module requests go through cache-control: Max-age =31536000,immutable Strong cache, so once cached they do not need to be requested again.
Note: Although native ESMs are now widely supported, it is still inefficient to publish unpackaged ESMs in a production environment (even with HTTP/2) because of the additional network round-trips that nested imports cause. For the best loading performance in production, it’s best to tree-shaking, lazy loading, and chunk splitting your code (for better caching)
How to create vue3.0+ Vite
How Vite works
The overall working mechanism of Vite is shown in a simple diagram:
According to the picture, Vite is actually a server. After Vite is started to build the Web server, that is, after the service is started (such as access), we visit this address, and the page will send a request to the Web server to request the corresponding file, as we can see from the network, as follows:
Vue (helloWorld.vue) : HelloWorld.vue (helloWorld.vue) : helloWorld.vue (helloWorldWorld.vue) : HelloWorldWorld.vue (helloWorldWorld.vue) : helloWorldWorld.vue (helloWorldWorld.vue) : helloWorldWorld.vue
Open helloWorld.vue in network
Compared with helloWorld. vue in our project, the two contents are completely different
Observe the contents of helloWorld.vue in network
import { render as __render } from “/src/components/HelloWorld.vue? Type =template means helloWorld.vue? Type =template: helloworld.vue? Type =template request, open to view response, which is actually what template is compiled in helloWorld.vue
This mechanism is why Vite is so fast. Vite Server intercepts requests and only compiles the requested files and their dependent modules. Files that are not referenced are not compiled.
To prove it, look at the current main.js, which introduces index.css
import { createApp } from ‘vue’ import App from ‘./App.vue’ import ‘./index.css’
Mount (‘# App ‘) createApp(App).mount(‘# App ‘
Modify main.js to remove the introduction of index.css
import { createApp } from 'vue'
import App from './App.vue'
//import './index.css'
createApp(App).mount('#app')
Copy the codeIndex.css is not requested by network
The problem is that intercepting and compiling every time a request is sent will repeat the compilation every time a page is refreshed (even if the page is not updated). The answer is no. Just we put the index. The CSS reference removed, automatically refresh the page and observe the status code above, apart from a few to 200, most of the other was $403, which represents the requests with the inside of the cache resources, not back to compile, reasonable use the browser’s cache mechanism, reduce the request and compilation, improve speed.
In addition to using the browser cache, Vite also has a caching mechanism. It will cache the dependent packages. Here we can look at the response of main.js in network.
As you can see, our reference to vue becomes a reference to vue.js under @modules. In the project directory, go to the. Vite_opt_cache folder under node_modules and you’ll find the vue.js file.
Compare with vue.js in network
Vue. Js in network is vue.js in vite cache. It is a js file generated after compiling vue.
** Refresh the vue. Js file in network. In fact. Vite_opt_cache is used to store cached dependencies, and not only vue dependencies can be cached, but also other dependencies, such as axios **.