Studyportals is a company which has been built, fundamentally, from web technology. As such, it’s very important to us that we keep up on the changes and assess when to adapt; though we strive to keep our stack up-to-date, occasionally we need to balance that out with pragmatism. You may have read about our recent journey in upgrading to Vue3. As part of that, our engineers had to assess a lot of the tooling we use surrounding our Front-End stack. That is where we met Vite and delved into a comparison with our current bundler, Webpack.
Effective JavaScript bundling is a huge part of our ability to successfully build, maintain, and run our portals and ~20 microservices. The challenge we have is achieving a modern and effective bundling setup that adheres to our quality guidelines, whilst also ensuring our engineers are empowered by a smooth development experience.
In this blog, we will explore what Vite is, how it aims to improve developer experience, and dive into some of the decisions we made when assessing it as a viable alternative to our current setup.
What is Vite?
Vite (pronounced \ ˈvēt \, French for fast) is the “next generation of Front-End tooling” developed by Evan You, the founder and creator of VueJS. It is a build tool which comes with a pre-configured dev server and also bundles your code for production.
The first stable version, Vite 2, was released in February of 2020 and did well to gain traction. With the development of a successful ecosystem, community adoption has grown exceptionally well to its current 1 million+ average weekly downloads. Not too long ago, Vite 3 was released with a generous payload of new features and support. The Vite team now aims to release a new major version annually, to align with Node.js’s EOL.
It's no coincidence either, that the Vite 3 release has aligned neatly with the re-write of VueJS to Vue3. The Vue team hasn’t made it a secret that Vite, with its latest features, has been built as a replacement for vue-cli, with the ultimate goal of providing all of the spanners a modern Front-End build kit needs, with drastically improved developer experience.
Webpack vs Vite
The reason Vite claims to be a “new” type of build tool is that, as a dev server, it functions fundamentally differently to a traditional bundling setup. Vite natively handles ES modules and uses a pre-configured dev server, meaning things are very snappy compared to a Webpack with CommonJs setup, for example.
But, how does this actually work?
Well, Vite allows us to author our code as native ES modules (ESM). The browser will then take these ES modules, parse the files looking for import statements. It then makes HTTP requests for each required module, to the dev server. The dev server simply serves up each of these modules as is. Think of it as introducing a level of asynchronous behaviour that was not previously possible with CommonJs and AMD.
Esbuild + Rollup + TypeScript
Vite uses esbuild under the hood for ESM and bundles your code for production using Rollup. So, the speed benefits are really around developer experience here; Vite pre-bundles all your node modules with esbuild and serves them to the browser on page load. The rest of the application modules are served up as needed, meaning it's really fast to get going.
A great feature of Vite is its out-of-the-box support for Typescript. Vite makes it easy to scaffold your project with Typescript, or simply add Typescript files to an existing project without any extra dependencies or configuration changes.
It is worth highlighting an important caveat of esbuild and Typescript here:
Since esbuild is written in Go, it is naturally transpile-only. This means that for projects built in Typescript, there will be limited type checking in the compiler with Vite.
Evan You has defended this as “a small price to pay” for the significant speed improvements; when you think of the extensive support we have with modern IDEs and extensions, he’s probably right. It is good to remember, though, that issues that slip through will be caught by the Rollup build, anyway.
Vite-cli
Vite is very streamlined to install. It adds a single dependency to your project, which installs a few necessary packages. By running an npm init vite command, you can get a hello-world project setup and scaffolded with a dev server running in less than 20 seconds.
Although likely to have been developed to be used with Vue, Vite is framework agnostic, so the CLI offers us a few options when setting up a project. The list includes Vanilla, Vue, React, Preact, Lit, and Svelte. As mentioned above, Typescript is out-of-the-box supported, so can be preset along with JavaScript (and Nuxt for Vue projects!).
Though it doesn’t offer loads of features, Vite’s focus on being streamlined and minimal seems logical, when considering the goal here is speed and efficiency.
Sounds great, sign me up!
… Not so fast.
So far, Vite sounds like exactly the tool any team would want to use. It has all the modern features you need, is framework agnostic, and blisteringly fast. So, this begs the question, why did we choose not to use it? Well, that really boils down to how we work at Studyportals and the maturity of our stack and tooling.
At Studyportals, we run 5 platforms (or, portals, as we call them) to help people all around the world find education options at various levels. A few years ago, when endeavoring on an initiative to modernize our stack, we made the decision to implement a microservice architecture and chose Vue to be the primary JavaScript framework to enable this.
Today, we are running a suite of roughly 20 Front-End microservices across our portals. Keeping all of these services consistent and maintainable requires a strong set of tooling and quality criteria. One of the tools which is paramount in achieving this is a package we developed called WebpackHelper.
WebpackHelper, as the name suggests, helps us quickly set up Webpack across all of our services. It comes with a few flavours, includes our core dependencies, and outputs Webpack configuration that allows us to bundle our code in a way which is standardised and highly optimised for production.
For a number of reasons, we decided that this was not the right moment to migrate over to Vite, even though we knew it would improve our developer efficiency (and probably happiness too!). As you can see with WebpackHelper above, we have a mature set of tooling surrounding our Webpack setup which means our services are standardised, optimised, and easy to deploy. To add to this, our teams have built up solid knowledge of Webpack over the years and are well-versed in maintaining and evolving the current setup.
Ultimately, we realised that the amount of resources it would take to migrate our existing solution to a Vite based setup with a similar level of maturity, was too high to offset the value it would provide us. Not to mention that we are already starting to see ESM support in Webpack-cli, so it’s likely just a matter of time before we see improvements in developer experience too.
Takeaways
Clearly, there are some changes coming to the way modern web applications are developed. With the rise of ESM, it seems likely that we will see a wave of support in all the long-standing tools like Webpack, Rollup, and Parcel. So, the question now beckons, should you use Vite?
Vite is undoubtedly a great tool with a great set of features. But, the true moral of the story here is that it depends. It depends on the tooling you have already setup, it depends on the project you are setting up/migrating, and it depends on your team. Our decision came down to an assessment of how much value this change would bring, vis-à-vis our success criteria; ultimately we decided that on this occasion it would not be sufficient. Regardless of that, Vite is an exciting project that I will be keeping my eye on and I suggest you do too!
Top comments (0)