Vite 5 with Bjorn Lu
===

[00:00:00] Hi there, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free at LogRocket. com today. My name is Paul, and joined with us is Bjorn Lu. He is an Astro Core resident and on the Svelte and Veet Core team. What a run up. He's here to talk about the recent release of VEET 5 and boy, is that exciting. VEET has such increasing reach in the amount of projects it's touching. So very excited to have you on. You're very excited to talk about some of the big changes that have come. Welcome to the podcast.

Yeah. Thank you, Paul, for organizing this. It is exciting to talk about V five thing. Yeah, it's a huge release, so I think, yeah, I lost unpack.

Yeah, there's a lot to unpack. And before we talk about the specifics and what's changing, let's talk about web pack a little bit. And just for people who are, you know, [00:01:00] not familiar with what we're getting into in short, what is VEET and how is it different from the other contender out in the space today? 

So V today is, is like web pack. They are the bundles that have you process your JavaScript, your CSS, your assets into a proper app that you can publish. So difference between V and Webpack today is that. V embraces like the modern standards and ESM so that it provides a faster development experience and so quicker response time when you update files.

So overall, they're the same thing, but just using modern technologies. And yeah, that's one of the main selling point. And of course, not to mention the performance.

How did you get involved yourself in the VEET project, 

I got myself into Vee a long time ago, I think like everyone else, I was also a user of Vee and in my past company, I'm pushing [00:02:00] Vee into it and the more I work on Vee to move into my company's project, the more like issues I find, some small nits, and then I started to fix it, like sending issues, pull requests, And those kind of small things pile up over time.

So my work, I started to understand more about how VEED works. And sooner or later, I take more responsibility over VEED and become a maintainer. And that's how it got rolling. I think everyone might have the same experience on the team as well. Just over time, wouldn't know it.

right? When you started using VEET for the first time, or I guess when you learned the mental model of how it is different and how it, doesn't pre bundle everything. Did it feel like a no brainer in terms of the direction that these bundlers should be

headed? 

Definitely, yeah. The first time I see how V works and also like its predecessor, the Snowpack. [00:03:00] I think the new way Dustin just clicks with me on the spot. It feels, it makes sense of what are we doing. The previous ways, like bundling all at once before we even see our apps. 

So VEET 4 has been around for I don't want to say a really long time, but there's been quite a few projects tooled with VEET 4 and people have gotten familiar with VEET 4, so we're going to be talking about VEET 5, and there are some differences between VEET 4 and VEET 5, so before we get into nits and details and stuff, broadly, What excites you, what excites the community that you maybe want to reflect about the improvements and like shiny features in terms of move from beat four to beat five.

Yeah, for VEED 4 and VEED 5, I think we try to keep not too many breaking changes because over time I think between VEED 4 and VEED 5, our ecosystem blew up a lot. I think recently we have Remix started using VEED [00:04:00] and Angular as well, which is, which are huge projects. So in VEED 5, what we do is we try to fix some longstanding issues, like issues where We have to break things to fix it, but we couldn't really do it in the past.

So we, we hold it for quite a long time and so now's the time we finish breaking everything we can to avoid another breaking change. Yes, as mentioned that the ecosystem is huge, we try to avoid changes too much and besides like polishing things up, I think there's a few like deprecated stuff. And some, just some small old stuff from V4 and just...

Just remove it and just have a clean new API like before.

So would you say that this has been more of a cleaning set of changes in terms of, oh, these deprecated API's that were marked as deprecated, they're no longer versus Net new features that you've added 

Yeah, it's more of cleaning and polishing thing. There's also the deprecation. I think I should mention, [00:05:00] we started to deprecate CGS from the node API. So that's like a big thing in Vite 5, I think, where if you use Vite like, it require Vite and CGS. They will now admit a warning. So that's also another selling point.

Just us slowly pushing the web forward to use ESM and embrace it. And yeah, I think we're working towards there. 

V is the king of speed. Are there any like speed related improvements from V4 to V5? 

There, there's actually one I worked before. If you update files that is dependent by a bunch of other files in the past, it would just. Re transform all that files, which sometimes you don't really need to because you just only update that one file, right? So I actually work on some fixes so that it reverts to just transforming that one file.

So that's like multi performance improvements. And I wouldn't say there's a lot. There's [00:06:00] certainly other small PRs that improve things over time. , the main one we have done as well for performance is in V 4.3, where we also have a big post about all the performance improvements there.

So it is a priority and I'm constantly looking for performance fixes. But yeah, V five should have some, but it, I wouldn't say it's like the main focus so far. 

on the tooling side there in a blog post, there was mentioned or in the release notes that there is PNPM create V. That's like a thing now that people can do to scaffold a project

Yeah.

so how long has that kind of been asked for? In the community or, did you, did guys just come out with it?

I think it existed in the very, very early days because we needed V, we needed people to use starting V because no one ever heard of V before. So we have a scaffolding tool so we can just quickly spin up V. So I think it's been there for quite a [00:07:00] while and it is most important for issue reproductions because if anyone has issues, you can just spin up scaffold and a small app.

But yeah, it's, yeah, it's pretty cool when it works. It also supports scaffolding like other apps like Nuxt or SvelteKit from V's own scaffolding too, so it includes quite a lot inside. For 

Are there any new scaffold to templates that have been added that people might want to know about in V5?

I think it's the same as before, but in between V4 and V5, there's new templates, I think from SolidJS and Quake. So we've, partnered with them in the ecosystem and they have been Helpful giving feedback of our own Vite, so this is a way that we try to cooperate and Yeah, now they also have the templates inside which you can use today

Awesome. , if we're talking about internals now a little bit, we're going to take a view into the microscope There's a combination of ES build and roll up just for my own [00:08:00] information Do those kind of like work at the same level in their role?

They play

Yeah, so Vite contains a bunch of other tools including ESB and rollout. Currently they have different roles ESB is used for transforming like TypeScript to JavaScript Or JSX, TSX, all those stuff. It also powers the pre bundling. If you have no modules, you don't exactly want to put all those files inside your browser because there's a lot of files.

So those are what ESBuild does. And there's also rollup which does on the build side. So once you finish with your app, you can run build those. It will start the entire rollup, build from start to finish. So those are two different responsibilities and VEED just hooks everything up to do each of their own thing.

one of the major migrations that's happened that I do know about is Choosing to go with a roll up version 4 correct

Yeah, Rollout 4 [00:09:00] is I think one of the biggest one as well for VEED 5. Although Rollout 4 it releases as not quite big of breaking change so hopefully it doesn't affect too many people but it is something unexpected while you were on VEED 5 because we know that there's a major coming for Rollout but we don't really I don't know when it's coming out, but suddenly in VEDCONF, I think recently rollout 4 just got released while Lucas was making a talk, and from there on we just put it in VED5, because, yes, why not, just keeping the major, so yeah. 

so that was not a really like difficult Migration because of not a lot of breaking changes, or I guess a follow up question to that also is why did the team choose to do rollup for right now? Was it just a good commingling of the major upgrade versions of your team and the rollout team? 

YEah, so in Rollout 4, it's actually not as painful as expected. I think [00:10:00] there's some tests that we have to tweak, but it's kind of a plug and play situation. So once we upgraded Rollout 4 for V, every ecosystem that upsgrade V as well doesn't have too much of the pain point from what I've seen so far.

So yeah, we brought over some of the fixes from Rollout, but I think overall it's it's not as hard as expected, which is great.

Glad to hear that. Don't want to be slaving away on something that's unexpectedly too hard.

it's the best one. Yeah.

I want to get into some of the deprecated APIs as well, because he mentioned the CJS. Loading, getting deprecated right before I do that, just want to remind our listeners that this podcast is brought to you by LogRocket. So if you're building a web application, you want to find and surface issues faster.

You want to , find trends that you didn't notice before, heat maps, full session replay, LogRocket. com. You can try it for free and you can spend more time building your product and less time debugging it in the console. [00:11:00] So for people building with Vite, they have some changes they do need to be aware of Bjorn, and you mentioned the CJS modules getting deprecated.

If we just look at that Briefly, in particular, what do you think are some of the types of projects or biggest like red flags that you would raise about that? What are the implications that you feel like this will have? You mentioned wanting to just push people in general to embrace ES modules.

Would you say that's the flagship takeaway for that?

Yeah, , for me, that's the main point to just push SM4, because CGS has been stuck for quite a while, and then we've been mixing both of those for quite a while, and it's been very painful to get those working. And also, we have to maintain like a special workflow to get CGS working, so it's a small maintenance burden on our part to keep CGS working.

So in V5, We figured initially to just toss it away. But then over time we discussed and then it's a bit too quick. [00:12:00] We couldn't just toss it away. So we did a middle ground to emit a warning if we use it today. And luckily a community member Ben McCann, has been working all those ecosystems using V to make sure they are not hitting the warnings.

So if you're using V through... A meta framework today. Hopefully you shouldn't be seeing those kind of warnings. It should be all fixed today. And yeah, the ecosystem should be ready for ESM when we release the next major.

Gotcha. So right now there's a warning. Pay attention to the warning,

Yeah, there's a warning and there's a guide. The guide should be complete so you can, yeah, fix it.

What are some other polishing actions that you guys took in terms of deprecating APIs that are not true to the focus of beat and the direction you're moving in?

Yeah, there's a small few deprecations, I think. One of the main ones probably gonna bite a bit more than usual is the CSS imports. So in the past you [00:13:00] can import css and then you get like a string of css. You can do whatever with it. But now we require that you put a question mark in line when you import a css so that you can get that string.

So just small things that we have to fix so that we can properly bundle css There is also another cgs related deprecation we did for ssr so in the past metaframework can output SSR bundle in CGS or ESM, but in Vite 5, we kind of forced everyone that you have to only export in ESM.

The good thing is we did it deprecation in Vite 4, and yeah, every ecosystem right now is ready and shouldn't be impacted by this, which is great.

So I would, okay, we talked about cjs, we talked about the CSS one, I feel like that's also a big one that it's just like it is small, but I know I would get confused if you're not like reading the docs, so I'm glad we mentioned that. aNother [00:14:00] transition I want to talk about is. worker. plugins, so if you've been using plugins before in Vt4, the way you configure them is going to be different in Vt5, right?

Yeah, so worker plugins is one of the change that we're reluctant to do it because if you have to use a function for the plugins, it kind of, weird. But then we decided it's the only safe way if you have multiple workers in your app, or you have workers that depend on other workers.

And then they kind of have a loop and everything becomes very complicated. And we also want to bundle workers in parallel. Because otherwise if we do it one by one, it's going to be very slow. So that's the change that we have to do. So in a function form, you always get fresh set of plugins for the worker.

And that way, we can all do, we can do the optimizations to get everything working as fast as before.

ParallelWorkerBuilds, that's great. And the last specific one I want to throw at you is [00:15:00] the server warmup feature. I know we, Talked about speed for a quick second at the beginning of the podcast, but what is the server warmup feature and how does that affect speed?

yeah, warm up is also one of the more important parts of Vite 5 that we're gonna be talking about it. So warm up, how it works is that, let's say you have a thousand modules in your app , and you know that there's certain parts of the modules, maybe you have like utility files, you have component files, that kind of layouts, and you know that those can be loaded right away.

But the browser has to discover those files after processing. Other files, right? So there's a waterfall before V knows that file is going to be used. So warmup is a way to tell V that, okay, I'm gonna use this file later. Just that maybe you won't know about it until later. I'll tell you about it now.

And when V knows about it, it will start processing it. So by the time the [00:16:00] browser knows about that it needs this file, V already has it and it's cached. So everything's already cached. And yeah, page load will be snappy as before. So this is one of the few things we did to try to improve page load times, especially for larger apps.

Because larger apps tend to have slower page loads. I'm excited to see if this new option works for everyone. So in V5, I'm happy to see it's being shipped.

So the level that it tells the browser of what files are available is at the file level. It doesn't actually serialize the tokens within that file.

Yeah, it will... If you, yeah, if you know which files to anticipate and then when it's, when a browser wants to request it, it's already there in cache.

So you mentioned you guys have been putting in a lot of effort to work with other. Frameworks and other ecosystems to expand the breadth and the reach of I'm curious, you know of Angular of [00:17:00] Svelte of view which ones prompted the most pivotal conversations and debates to happen

That's a bit spicy. I think. I think every framework has so far put some nice criticisms about something we should fix Some SSR pain points, some configuration options are confusing and it's great to see all those feedback from the ecosystem. Directly, because those maintainers are in contact with us

and, yeah, I think every framework so far has voiced their opinions about certain things fairly equal. And, yeah, we also try to help out whenever they have questions about it. I wouldn't say that a certain framework has changed V quite a lot. I think everyone so far in the ecosystem is much appreciated so far.

and I Would love to ask you personally Because you're in this interesting position of working a lot at the core boilerplate [00:18:00] fundamental level of whole tech stack ecosystem set of ecosystems that everybody's working on. You're you have this good perspective of how things were done prior because it was just the way it was done in Webpack and this new paradigm of how things are being tooled in the present day.

So from your perspective, Bjorn, what learnings have you taken away in terms of how to do clean code, how to do efficient code, or just general processes of how to structure projects that you didn't have before joining the VEET ecosystem and working on the VEET Core project. 

I've definitely learned a lot. Especially for V, the code base is quite huge and there's like design decisions I learned over time. I think one of the main ones for me is that whenever you start a project, V has its own early days, the easiest way to get your ideas rolling is to not really care about Like patterns, you know, code, just write it out, just get it running.

And [00:19:00] once it's running, and once people are using the code that you crappily wrote out of a whim, and once that's stabilized, you can then start refactoring and just making everything cleaner. And I think that works really well for my other projects as well. I get to ship stuff a lot more quicker than before.

Because before I start, I always overthink about like certain patterns. And that's one of the main ones. And also, I think the second point is that you shouldn't really try to change a lot of small things at once. I think it's good to scope what you want to do, or want to fix, and make sure those are relevant, if you're only fixing a certain syntax to another syntax that is not really different but looks slightly cleaner, because it's like the new modern syntax that you want to use.

Thing. Yeah, you should try to avoid small things unless it's really worth it to prevent like bugs from happening.

And on kind of the contrarian point of view of [00:20:00] takeaways, is there something that you've noticed in the general way of feedback that you've gotten from other projects, personal projects, just people submitting issues of things you've noticed of how folks might structure projects that you're just like, why do so many people do this? this doesn't feel good. Are there any things like that, that you've noticed? CJS might be one of those things where you're like, why are people still doing this? But I wonder if there's any others. 

So from my experience, I'm working in V and then looking at how other frameworks do things these days I think and what I learned is that every structure Each project has definitely has a reason that they exist that way so if it looks weird for some reason usually I come to First accept it that there's probably a good reason why they structure it this way and then from there on I start to Understand what their flow is and then at the end of the day, I think each structure they have is probably [00:21:00] Fine, it's not really an issue because every project has its own unique constraints And I think over time a bit more Accepting about all those weird patterns because I think Everyone writes good code at the end of the day.

I love the positivity. , and that is a really good point that we have a lot of folks on this podcast that they hammer home this point of if it works for you, use it.

Yeah.

And don't clamor about anything else. It's definitely encouraging to hear that from you as well, Bjorn. If we're coming to the end of the pod here.

So if people wanted to themselves learn specifically about Beat 5, there's always the release notes. Some folks maybe don't want to read the release notes. So if that's the case, what other resources are out there? That you can point folks to.

I think the release notes is kind of the only way you can get the most complete information I don't think I saw like any blogs written about those but we've put a lot of time [00:22:00] In the migration guide so that is complete and I hope people read those

iS the migration guide accessible from the release notes? not like a separate... Okay, gotcha.

we have a changelog that links to the migration guide and the migration guide that links back to the changelog So hopefully it's discoverable.

Okay. Awesome. And Do you yourself post anywhere, or blog, Bjorn?

I have a site, a blog on my website beyondblue. com, but I've already written any blogs for more than a year But if anywhere else, I think my thoughts and opinions are on Twitter lately or Hex that's the only place you can find me

And what's your handle, just so folks listening can hear it, and then we can put in the show notes?

Oh, yes. Um, I handle is blue. We use a B L U W Y O O. You can find me there. I try to share some findings from time to time. So around the, yeah, you can find some news there.

Awesome. Bjorn, this has [00:23:00] been an excellent time. And now there is another piece of content out there that isn't necessarily the release notes. If people want to quick and dirty of what's new in beat five, but it's been a pleasure having you on and look forward to having you on in the future to talk about the next major versions of beat.

Thank you. Thank you Paul for having me.