What's New in Vite 6

♪♪ I'm Dominic. I'm not sure if you can see the slides, so... Yeah, that's me. And I maintain Vite and Svelte. At least, I work with both teams and do some tooling, like Vite Ecosystem CI, Vite Plugin Svelte, or TSConfCheck, that everybody who uses TypeScript with Vite has to use too, to load TypeScript config files.

But this talk is not about me. I'm a freelancer as well, but open source is what I love. Today, I'm talking to you about Vite 6 and even beyond. In this talk, I'll give you a first overview of our history. There is history with Vite now. That's great. We have a little break as well. Then it's all about the environments and what it has in it for our future.

So history first. Vite is turning older. It started in 2021 as a public release. And soon enough, it'll be four years, but it's been a wild ride. We have had a massive influx of frameworks using Vite. And as a result, also a massive influx of users. The download charts are always a joy to see because when you do open source, you want nothing more than people to actually use what you do. People use Vite a lot. It's been downloaded 12 million times in the middle of the year. Today, this is 16 million. Last year at this conference, it was downloaded 8 million times, now it's 16 million. So it doubled its downloads in that time.

What I'm even more proud of is that this year, we cracked 1,000 contributors to the Vite repository. So we are not alone building this. We are a community building it together. And I can't even name all the projects that have logos on this slide. And there's some missing because it was done a few months ago.

And this makes me very, very proud. And we all like it, but why? I'm getting somewhere with this, please trust me.

We have a great plugin API based on Rollup. We enhanced it with a few extra hooks. This allows frameworks to build their tooling in a very consistent and easy way. It supports server-side rendering out of the box. Server-side rendering is, well, one of the trends in the last years. Especially hybrid applications that hydrate on the client after they rendered the initial response on the server are not even a thing you can do, but a thing you should or must do today. And the built-in support just makes framework authors' lives a lot easier.

The powerful dev server is also one thing that is amazing to use. And you can build dev tooling that is unmatched in developer experience. You should watch what Anthony Fu has up his sleeve because honestly, this guy, he gave us Vt Plugin Inspect, which allows you to watch what other plugins are doing or what your plugins are doing. It's super great. And testing with VTest is zero config by default. So you don't have to create a huge config that mimics your application runtime to tell your test runner what it should test. It just works.

Hot module reloading, like rerunning of tests of files you changed, is a time saver. It has saved me probably weeks of my life already. And you can configure it with so many options. Like, VTest is one of the most feature-rich test runners out there. It's, yeah, I swoon every time I use it. And the defaults built into Vt's built pipeline are also great. So regularly, user configs are just import a few plugins, set one, two options, and you get your output. So you don't have to do a lot as a user to use a framework that's built on VT. And I think that's one of the greatest things why VT is loved so much.

So with that being said, it's time for a break, right? It works. It's loved. It's growing exponentially still. So we are done. We just ride the hype train and feel like using it and not doing anything about it because never change a running thing, right? But some limitations do apply.

These limitations are going to show in just a moment. With SPAs, it's pretty straightforward in VT. You have just one path of requests, and the code is fed to the browser. And you have just one module graph.

OK, so it gets a little bit murky when you add support for server-side rendering. This support for server-side rendering in VT was heavily inspired by an early version of SvelteKit that used Snowpack still. But it basically means that you call SSR load module to load modules for server-side rendering. And in the internals of plugins, this means a lot of different ways to communicate. You have, on the left-hand side, two different flows, one for the browser and one for the server-side rendering. And in the back and forth between the two, you have HTTP calls and function calls and a web socket. And it's a little bit tricky.

But even worse, maybe, on the server-side. So in the dev server, they share a module graph to some extent. So there's one module graph, and you can ask it to give you the client version of the module or the server version of the module. That leads to a lot of workarounds or extra code you have to write when you build hydration-aware or SSR-aware frameworks that work with hot module reloading during dev. For example, when you want to invalidate a module when a client module changed, and you want to prevent the next server-side rendering response from returning an invalid outdated code fragment, you have to invalidate these modules on your own. This is code taken from read-pipe-plugin-serve, for example. And in plugins, in general, the fact that you are processing something that's SSR is transported via an SSR flag that's passed into hooks in the options. And you have to check and branch on it all the time. You also have to pass it in some exported functions that we provide. So you're basically the messenger and have to deal with all this stuff on your own. And if you want to build it, you have to build it twice, once for the client and once for server-side rendering. Frameworks can either wrap, read, and provide their own CLI to orchestrate these builds. Or they can use a trick that was made popular by SvelteKit as well but has been used by Remix and others. That is that you use the right bundle hook to trigger the next build in a chain of builds. But this is like a lot of boilerplate. And it breaks. And building sequentially takes more time. So in the years when we've been growing, we've learned a lot from our frameworks that use us what they do and where they run into limitations. And these limitations led us to thinking what it is.

And it's all about environments, really. You have the browser. You have the server. And we can fix this. If you look at this again, on the left-hand side is this messy thing from Beat 5. And when I say messy, I don't mean messy in a bad way but just in a little convoluted way. So if you look at the left really hard and the top and the bottom, they look pretty similar. It's just like the communication in the middle that's hard and tricky.

And when you abstract that and say, hey, we have this environment that executes code in some kind of runner. And then we have a transport that sends it to the code transformer in the dev server. And the framework can use the code transformer. Then everything looks a lot cleaner already. But you can also have more than one environment, right? We talked about SSR and client already. And what this means is if you have two separate environments, each gets its separate module graph as well. So instead of this mixed thing that you have to tell if you want the client or the server side module, you can just ask the client module graph for a module or the server module graph for a module. And multiple environments still run in one dev server that has all these pieces together. So the dev server in Beat is like it holds all the context and all the information.

And with these different environments and the module runner, the module runner short detour is based on Vite Node, which is something that came from Vitest and was added to Vite Core in Vite 5.1. It allows Vitest to execute your code and run the tests on them. But when you abstract it, it can be used to run any environment. And with this, you can have something that runs in the browser, something that runs in a node process, and the dev server running in a node process. And they are all separate. So before, the dev server was responsible for SSR and client module transpiling and resolving. And now we have this separate runtime environment that's a bit closer to what your actual production would look like. And plugins for this, they get new hooks, like Config Environment, where they can configure environments or change the config for specific environments. So if you build a framework that has more than one environment, you can use it to do different things on different environments. And they also get this.environment. This is basically the module graph, the config, all the metadata for that environment is contained in it. So every time in a hook you use this.environment, you get the environment of that pipeline. So the plugin pipeline is run for each environment separately.

And a plugin can partake in that environment or not. And in each hook, you can use the environment. So when you want to have a module for your environment, you just say this.environment.module graph, get module. That's it. You don't have to do if SSR, if client, if whatever. Less branching, more clarity.

And there are new config options as well. This does look innocent. Sure, you can configure environments easily. But what this means is that a plugin that uses a config hook can add new environments. So you can build plugins that create environments. Still sounds innocent, right? But this is super flexible. You can give a user a plugin that creates five environments and whatever. The sky is the limit here. And I can't wait to see what you all can come up with, because I don't know. It's too vast an area.

And we have CLI support, too. So you can build all these environments in parallel or in sequence depending on how they are structured together. No more weird chaining and write bundle. And the best of it, it's backwards compatible. By default, we are going to create fallback environments for the client and SSR. So what you know from Beat 5. And if you bring Beat 5 aware plugins, it should just work mostly. There's a few breaking changes around resolve conditions. But this could fill a talk. And I would get a little bit angry talking about it, because it's super complex. So I'll skip that for now. So even here, some caveats apply. But it's a lot cleaner than before. And it unlocks new possibilities.

Like I mentioned already that you can have multiple environments. And this means that Cloudflare, for example, shout out to Dario, by the way, who has been exploring this already, can provide a dev environment that's running in Miniflare. Today when you use Miniflare in Vite, it's more of providing hooks and use a separate Miniflare process that's running next to your dev server. But with this, you can create an environment that runs inside Miniflare. So it's actually pretty close to what you get from Cloudflare in production. And all the other cloud providers can do the same.

But it's not just about cloud providers. It's also great for cross-platform app frameworks. You could build a Tauri dev environment or something for React Native. You can use it to make a better environment to build web extensions, which then can be used to build better web tools, better dev tools for Vite. And I'm pretty sure more of you have ideas what you can do with this. It's super flexible, and you can go crazy. The release of this is going to be soon, like really soon. We are currently testing this in Ecosystem CI to make sure we don't break anyone. And there's a few reds left we have to solve. But maybe even next week it's released, and for sure it's going to be released in 2024.

But it's going to be released with an experimental flag, because we want your feedback, and we want to make sure this API lasts. Like, it should give the same experience we have today, but better. And with that, I have a few minutes left, and I want to talk about what's coming in the future. In 2025, Vite is starting a new chapter. I call it More is Less. We want to stabilize the environment API. And the elephant in the room that I haven't been talking about at all is Rolldown Vite, which unlocks a lot more. We get faster builds of it, but fast and mostly we get a more unified dev and build pipeline. Because right now, the dev optimizer is using ESBuild, which requires a different plugin pipeline. So Vite plugins or others use a special ESBuild plugin to optimize dependencies during development. With Rolldown integrated, we can replace ESBuild with the regular plugin pipeline, and we can have a lot faster and more consistent dev experience there as well. You get new features. It's faster. And internally, we have less complexity, because there's only one plugin pipeline.

So it's really, really looking like a new era or chapter for Vite. I think we might not have seen the last of this great chart I showed you in the beginning.

That's it for me today. There are a lot of resources about this. main.vite.dev brings you to the documentations. The migration guide is great. And you should check out Patak's Vite Conf talk about the environment API and also Safi Red's blog post, because they go in a lot more details. Some of the images might look familiar when you go there. Also, a changelog, docs, and a migration guide, of course.

This talk has been made with slide to the left by James. Thank you so much for making this. I like the DX and UX of this a lot. It's built with SvelteKit and Threlt and would be impossible without Vite. So yeah, I'm using the stuff I helped maintain to tell you about it. And maybe this can also be made better with the environment API.

If you want to get in touch with me, you can use Mastodon. But I'm not really active on social media. So probably better you go to my website and contact me there. Also, you can find me on chat.vite.dev. And on GitHub, I'm Dominik G. I'll make this talk available sometime. But it might take a few days. So I'll post on Mastodon about that.

I have to thank a few people. First, the organization. Lara, you've been doing an amazing job for managing all the speakers. I feel very welcome here. Matthias Oppadack for being an awesome guy. And Vite wouldn't be the same without him. All of you, of course, coming here and listening to me.

It's an honor to be here. So thank you from the bottom of my heart for having me. And I'm sure you have questions. Let's get going.

First question for you is, realistically, how big of a problem is it that Vite uses ES build and rollup? Do you think this is the biggest drawback to using Vite over something like Webpack? And we kind of heard that with rolldown, that might actually go away.

Well, so first of all, ES build is used for its speed and its simplicity. And Evan Wallace is one of the most amazing people. I can't credit him enough. Nobody can, really. He's mostly done it himself. I said Vite has used 1,000 contributors. If you look at ES build, it's mostly one guy. It's not only one guy, but yeah, I can't thank him enough. But for Vite itself, there are two different plugin pipelines. And the optimizer is different from the rest, is more complexity, and that going away is good for Vite.

I don't want to talk about rolldown as a way to make Vite faster because Vite is fast enough. It makes it more consistent, less complex. That's the big deal about it for me. The speed is not a limiting factor for most of us. Like, if you have tens of thousands of modules, you are like running an organization. You're a big enterprise. You have huge intranets and whatnot. But if you are doing a public website and you have tens of thousands of modules, you might be doing something wrong. We have a discussion about simplicity versus complexity later. Join me and fight me on that opinion if you want to. But you won't change my mind.

Awesome. All right. This next one comes from Paolo, and their question is, any idea how the rollout of rolldown will plan up? Rollup is very sophisticated these days, and replacing it on the spot might be painful. Oh, so actually, I don't have much ideas about that.

And it wouldn't be my news to share, so I have to defer to Evan. He did a talk at ViteConf. You can find the video online where he talks about some of it. It's coming, and yes, it's a big task. And there are, of course, some growing pains maybe. But Vite is not even a teenager yet. Like, we are in elementary school. So we have some time, and we are allowed some growth and some pain. But the result is worth it. And it's also just the start.

This unlocks more. Like, the environment API combined with the added speed and the lessened complexity sets us up for future. Like, at this point, Vite is basically infrastructure for the web. And we are creating more infrastructure after finding what our users need it the most. And I'm talking as we and us and them, but that's not true. Like, there's 7 million projects on GitHub almost that use Vite. Vite has been downloaded almost a billion times now. And it's the community doing it for itself, really. And that's the thing.

So while there is a push that is coming from Void Zero and building tooling around OXC and rolldown, it wouldn't have been possible without the community. And it will always be Vite at the core that is what helps every one of us to build cool things. Absolutely.

So this next one is a question I had as well. So just talk to me a bit about, like, what are environments and what's going to go into creating them. So the question from John is, where is the environment actually stored? Does the environment API have plans to deal with environments updates across platforms? So in the heart of it, the environment is defined in your config. So we have an environments top-level key, and then in there are named environments. The storage is separated per environment. And we are going to provide utilities so that plugins can use Weak Maps for caching for one environment if they work with multiple environments. Because today, many plugins put shared state into their functions context of the initializer, but that won't work if you run it in multiple environments. But this won't be hard, and it actually makes it more consistent than today, where as I've shown, SSR and client are kind of mixed.

This next question is about front-end frameworks. So with front-end frameworks like Vue and React adding compilers to improve performance, how does Vite play into this? Well, you asked the right guy, because Svelte has been using a compiler since a long time. That's none of my doing. Rich somewhere over there did most of it. The newest one was done by Dominic Gunaway. But yes, compilers are a trend, and plugins can use compilers. The environment API will actually make this easier, because the Svelte compiler, for example, has a flag that's called Generate, where you can tell it if it's for a client or a server build. And when you know the environment, you can just pass that along. I suspect Vite Plugin Svelte will lose about 10% to 20% of its code when we move to that API. That's great.

Next up, we have, I mean, I don't know if you can answer this, and maybe it's for the Next.js team, but Anonymous asked, will Vite eventually support building Next.js? Well, Vite supports building React applications. And due to the size of the React ecosystem, React is actually the most used language for Vite, even if that's not entirely obvious, because all the frameworks are not really React-based, except for Remix, maybe. So it's entirely possible to build server-side rendering frameworks that use React with Vite. I'm not involved in Vercel or what they plan to do with Next.js. So it's possible. Yes, of course. Vite is probably the most flexible bundler out there, which is one of the main reasons why it's so great. So it just has to be done, but not by me, because I'm just a freelancer and don't have the resources for it. Definitely. And from my experience, kind of like doing the research, I know there's things that aren't Next.js, but still server-rendered Reacts. There's like Vinci, which is built on top of Vite. And there's also, I think it's called Waku, which is a React server component framework, but I believe built on top of Vite as well. So even if Next.js isn't doing it, others are. Yeah. So Waku was recently added to Vite ecosystem CI. So it works.

So even if Next.js isn't doing it, others are. Yeah. So Waku was recently added to Vite ecosystem CI. So it works. And Vinci is probably one of the happiest infrastructure layers about the environment API, because what we did here is basically playing into their hand. Or it might even be no longer needed to do all the legwork Vinci is doing to that extent, because you can use different environments instead of spinning up different instances. Awesome.

I think we answered this one earlier. So this next question is from Semuel. Could the upcoming environments used be used for per-local builds? I think we're talking about internationalization. So if yes, that could solve per-local splitting of tree-shakeable I18N libraries like Paraglide.js. I am not sure this is the right API or section for it, because internationalization targets one environment, so creating multiple environments of the same kind. So you could create multiple client environments that all target the browser, but use different exports conditions to mark a language or something like that. So technically possible. But then you end up with different outputs and you have to find a way to serve them to the user and do the language switching. So possible, probably useful, maybe not. But I might be wrong on this. It's flexible.

And one of the things that I just said I forgot to mention earlier is that the environment API also allows you to build on a current version of Node, for example, but for an older version of Node. So if you target Node 16 for some godforsaken reason and you should update, you can still do that because the runner abstraction allows you to run a Node 16 instance and use it. So yes, it's flexible, but I probably wouldn't use it for internationalization purposes myself. That makes sense. And also, I mean, it's an experimental, so give it a try and see what comes out of it. That's all the time we have for questions. So thank you so much, Dominik. If you have more questions, be sure to head over to the Glass Room. You can ask questions in person. But thank you again, Dominik. Yeah, please do. I love to hear from you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.