With no extra configuration, you can also use Vite for TypeScript, and with one additional command, you can use it for Sass. (That would take a lot of config for a webpack project. You’d need to mess around with loaders and separately install the webpack dev server.)
Once you have Vite installed, you’ll have a build tool and dev server and be ready to start working with the latest tools and languages.
In this introduction, you’ll learn how simple it is to get up and running with Vite. You’ll also learn about how fast Vite is, how to take the first steps towards using it with a library such as Vue, and how much it gets out of your way when you’re using it.
Fun fact*: the name “Vite” comes from the French word for “fast”, which is pronounced, “vit”.*
How Vite Works?
Vite is really fast, because it leverages native ES modules and doesn’t need to rebuild the whole bundle when something changes. This makes HMR updates consistently fast, regardless of the size of your application. When bundling for production, Vite ships with a pre-configured build command that bakes in many performance optimizations out of the box.
As well as being fast, Vite also offers hot module replacement (meaning you see the code refresh in the browser as you develop), and you can use it to compile a minified version of your project to serve in production. By using it, you can get up and running very quickly with a Vue or React project without the buy-in to the Vue CLI or Create React App, both of which ship with the kitchen sink included. This makes it ideal for quick prototyping and smaller projects, although there’s nothing stopping you from using it in a larger project either.
So, let’s take Vite for a spin and see how we go. It will be interesting to see how much of our normal workflow would be better handled with Vite.
We get to choose a project name and a template. At the time of writing, the options are:
Let's stick with vanilla for now. This creates a directory with certain files in it based on the project name. There are files for npm and Git, as well as an index.html, main.js, style.css, and favicon.svg. Only a few scripts to launch the development environment and a build are included in the package.json file in addition to vite as a dependency.
The instructions on screen state that we must switch to the project folder and install the dependencies:
cd vite-project npm install
Then, using npm run dev, we can launch the development server and view our app at http://localhost:3000/. Any of our project files that are edited instantly update on the screen.
According to the documentation, TypeScript files are supported right out of the box. Despite the lack of a specific TypeScript template in the vanilla option, we should be able to rename main.js to main.ts and Vite should build it for us automatically, right? It does, indeed! It appears to be compiling successfully after renaming the file and adding some TypeScript-specific grammar.
Let’s try the same with CSS by renaming it to
style.scss and add some Sass-specific syntax. The following error is shown in both the console and on the web page:
I do enjoy a (somewhat) detailed mistake! We may now use Sass as much as we like after executing npm instal sass —save-dev and restarting the watcher. Nice.
Vite already proves to be a great tool for static sites and potentially Jamstack applications.
Why prefer Vite over create-react
1. Faster spin-up of the development server:
-> As dependencies do not change, they can also be cached and we can skip pre-bundling.
2. Less waiting time for reflecting file updates :
-> In Vite, Hot Module Replacement(HMR) is performed over native ESM. When a file is edited, Vite invalidates the chain between the edited module and its closest HMR boundary. This makes HMR updates simple and fast regardless of the size of your application.
3. Improved build performance
CSS code splitting: Vite automatically extracts the CSS used by modules in an async chunk and generates a separate file for it. The CSS file is automatically loaded via a <link> tag when the associated async chunk is loaded.
Async chunk loading optimization: While code splitting, Webpack, and Rollup produce a common chunk (code that is shared between two or more other chunks). This, when combined with dynamic import, can lead to many network round trips