There is a plan to run a hackathon at my company, and as the tech lead of the team I've been asked to choose the tech stack that we'll be using for our application.
My immediate response was that I want us to try out using Vite for the frontend part after I was following it for a while and did some research about it.
In this post I would like to share with you some of the features that Vite offers and to show a bit of how it works.
Vite
Vite (French word for "fast", pronounced /vit/) is a build tool that aims to provide a faster and leaner development experience for modern web projects.
Vite was created by Evan You (the same guy who created VueJS) and it seems that he used the same pattern with Vite as he used with VueJS - Simple, innovative, learning from others mistakes and taking care of many configurations by default BUT in case you need to go deeper and modify any of them - you can do it pretty easy.
Some of those configurations that Vite is providing out-of-the-box are - JSX, TypeScript, Web Workers, CSS and more.
Unlike other bundling tools Vite is using only ES Modules both at development and production - Lets see how:
Development
Vite is running Koa - a light weight dev server which is serving native ES modules and using esbuild for dependency pre-bundling.
What is dependency pre-bundling?
According to Vite's docs dependency pre-bundling has 2 reasons:
1) CommonJS and UMD compatibility - While Vite is using only native ES modules some of the libraries you are using or might use won't be using ES modules, instead it'll use CommonJS or UMD. To solve this issue Vite is converting all the dependencies from CommonJS and UMD into ES modules using esbuild.
Vite is performing this action when you run the dev server for the first time (That is why the first run might be longer then the other runs).
What if I add a new dependency or upgrade a version of an exiting one? Not a problem - Vite will watch the changes in package.json / package-lock.json / yarn.lock / pnpm-lock.yaml and will rebuild the dependency. In case there are some issues you can delete the cache folder node_modules/.vite or rerun the server with the --force flag and Vite will rebuild all the dependencies.
2) Performance - Each dependency can have a large number of it's own modules which will cause the browser to fire a crazy amount of requests to the backend so Vite is converting those dependencies into a single ES module to reduce the amount of the requests being fired.
Running the dev server
Lets run the server:
Now Lets compare it to vue-cli (webpack):
As you can see Vite is faster on both runs. But the question is - How? (We'll get an answer for this question later)
Native ES Modules
As I've mentioned earlier Vite is using only ES modules. If we take a look at index.html file, we'll see this line:
<script type="module" src="/src/main.js"></script>
The type="module" attribute is an ES6 feature that is using native ES modules. All the modern browsers are already supporting this feature.
The image above is showing the 'Waterfall' effect that ES modules create - starting from main.js and importing all the modules down the modules tree. And as you can see each vue component and dependency is being split in a separate module.
Unlike vue-cli (webpack) that by default has only 2 scripts:
app.js containing all the components of the application.
chunk-vendors.js is basically all the node_modules dependencies.
webpack does has a way to split the components and dependencies into chunks, but it requires you to configure this option OR manually selecting files/modules you want to chunk.
Another interesting thing here is that each vue component file has also a css file that is being loaded - Why? HMR.
HMR
Vite's Hot Module Replacement is one of the main reasons that Vite is so fast. It using web-socket just like webpack and other bundling tools, but the difference is that with the combination of ESM it works very fast even if your application will grow by replacing only 1 module and not re-bundling a big file.
Lets take vue-cli (webpack) for an example:
By default it has only 2 files (as mentioned above), on each HMR call the whole app.js will be re-bundled and sent to the browser.
Where is the problem?
When the amount of the components will start growing so do app.js's size and the time it takes.
With Vite on the other hand it'll be much faster because there is no need to re-bundle such a big file - it will only replace the actual component / file that was changed without 'touching' the other components / files. That is why there is also a css file that we've mentioned earlier - If you going to make a change only to the <style> of a component - then only the <style> of that component will be replaced by HMR and not the whole component.
So it means that if your app will have 1 or 1000 or 10000 components the time that the HMR process will take will remain almost the same (of-course it also depending on the size of the file, just avoid creating monster size components...).
Production
For production Vite is still bundling the code according to the official docs:
Even though native ESM is now widely supported, shipping unbundled ESM in production is still inefficient (even with HTTP/2) due to the additional network round trips caused by nested imports.
The cool 'waterfall' effect you saw above is really fast and useful when you're working with a dev server on your localhost, but this advantage can become a disadvantage when it comes to loading performance.
For production bundling Vite is using rollup.js which is also using ESM when building the app for production and it does that faster and with a smaller file size then webpack for example.
Downsides
Vite is not perfect and it also has its downsides:
1. Old browsers support - Old browsers (IE) doesn't support ESM, therefor applications created by Vite is not gonna work there.
2. Different dev and production builds - As you saw Vite is using different tools for development and production which has the possibility to cause problems and bugs that will appear only in one of the environments but not at the other.
3. Ecosystem - Vite is still new in the neighborhood and the ecosystem is still small. There are issues/bugs/problems that will probably appear in the near and far future that'll have to be handled, while webpack for example has a pretty big ecosystem that solves a wide variety of edge cases.
So should I stop using vue-cli or webpack and switch to Vite?
Well, it's up to you. My advice - First try it out, test it, build a small demo app -> then if you want to start working on a real project consider the advantages and disadvantages that I've listed above - and then make your decision.
Libraries and frameworks support
In this post I've showed all the examples with VueJS, but Vite supports also other libraries and frameworks:
VueJs, React, Preact, Svelte, LitElement. (And probably more will join)
Summary
Vite seems to be a really good and promising build tool with nice features, newer tech usage and an alternative to other build tools.
Its not perfect (like every thing in our world...) so I think you should give it a try, and even if it won't fit your needs I suggest you to follow it and watch how it gonna evolve and maybe then consider trying it again.
Hope this post made the understanding of Vite a bit easier.
Thank you for reading :)
Top comments (0)