Panel Discussion: Next Gen Build Tools

Hey there, I'm super happy to be here and to be with the Git Nation team again in this excellent event of JS Nation. And I am even more privileged and honored to be here with this excellent panel of experts Evan Yo, creator of Vue.js and Veet? Is that how you pronounce it? Veet or Veet? Veet. Veet. Veet, right, okay, so I wasn't sure about that. That's French. Yes, that's why I asked, I assumed it might be French, but then you know, the American in me wasn't 100% sure. Sean, aka SWICS, head of developer experience at Temporal.io and the author of Coding Career Hello. Hey, hey, hey. And Fred K. Schott, a Snopak author and who apparently had a very exciting launch yesterday. Just yesterday? Yep, just yesterday. That's good for you. Congratulations, and also hot on the heels of the Open Source Awards which are near and dear to my heart as a cloud native and open source IELT community lead. So that's exciting. Congrats to all the winners. I'm really excited to be here. I think this is going to be a really great session. So folks don't forget to drop your questions for our panelists. They're here now with us and you really want to hear their expert opinions on the next gen build tools. So I guess the million dollar question for all of you, and we'll let each and every one of you, first also introduce yourselves or give us a little bit of background about why you would know a lot about next gen build tools, but also what makes a tool, a next gen build tool versus just a regular old build tool. So let's start with Evan.

Sure. So I'm Evan. I work on Vue.js and VT and I guess VT is considered a next gen build tool. That's kind of the slogan, but honestly, like if I were asked to say, define what really makes it next gen, I don't think there is a very clear or definitive line. Like, we can, I think, you know, existing so-called old gen tools like Webpack, given proper redesign or improvements, can incorporate some of the characteristics of next gen tools. So I don't think it's a very definitive like this is always going to be old, this is always going to be new. In terms of technology, it's always going to be a shifting landscape. But I guess, in general, I think some of the trends I personally been seeing is adoption of these new emergent standards, leveraging more from the platform itself like native VS modules, native dynamic imports. There are some interesting stuff that is going on in the standards body, like new URL import meta, import.meta to URL, you can use that.

Hey there, I'm super happy to be here and to be with the Git Nation team again and this excellent event of JS Nation and I'm even more privileged and honored to be here with this excellent panel of experts. Evan Yeo, creator of Vue.js and Veet, I wasn't sure about that. Yes, that's why I asked. I assumed it might be French but then you know the American in me wasn't 100% sure. Sean aka Suik Suang, head of developer experience at Temporal I.O and the author of Coding Career Handbook, say hello. Hey, hey, hey. And Fred K. Schott, Snowpack author and who apparently had a very exciting launch yesterday, just yesterday. Yep, just yesterday. Good for you, congratulations. And also hot on the heels of the Open Source Awards, which are near and dear to my heart, as the Cloud Native and Open Source IEL community lead, so that's exciting. Congrats to all the winners. I'm really excited to be here. I think this is going to be a really great session.

So folks, don't forget to drop your questions for our panelists. They're here now with us and you really want to hear their expert opinions on next gen build tools. So I guess the million dollar question for all of you and let each and every one of you first also introduce yourselves or give us a little bit of background about why you would know a lot about next gen build tools but also what makes a tool a next gen build tool versus just a regular old build tool. So let's start with Evan. Sure. So I'm Evan. I work on Vue.js and Vite. And I guess Vite is considered a next gen build tool. That's kind of the slogan. But honestly, if I were asked to define what really makes it next gen, I don't think there is a very clear or definitive line. I think existing so-called old gen tools like Webpack, given proper redesign or improvements, can incorporate some of the characteristics of next gen tools. So I don't think it's a very definitive like this is always going to be old, this is always going to be new, right? In terms of technology, it's always going to be a shifting landscape. But I guess, in general, I think some of the trends I've personally been seeing is adoption of these new emerging standards, leveraging from the platform itself, like native VS modules, native dynamic imports. There are some interesting stuff that's going on in this standards body, like new URL or import meta, like import dot meta to URL, you can use that. And also like, I think there are ongoing work trying to standardize CSS imports as well. So a lot of interesting stuff there.

Hey there, I'm super happy to be here and to be with the Git Nation team again and this excellent event of JS Nation and I'm even more privileged and honored to be here with this excellent panel of experts. Evan Yeo, creator of Vue.js and Veet, I wasn't sure about that. Yes, that's why I asked. I assumed it might be French but then you know the American in me wasn't 100% sure. Sean aka Suik Suang, head of developer experience at Temporal I.O and the author of Coding Career Handbook, say hello. Hey, hey, hey. And Fred K. Schott, Snowpack author and who apparently had a very exciting launch yesterday, just yesterday. Yep, just yesterday. Good for you, congratulations. And also hot on the heels of the Open Source Awards, which are near and dear to my heart, as the Cloud Native and Open Source IEL community lead, so that's exciting. Congrats to all the winners. I'm really excited to be here. I think this is going to be a really great session. So folks, don't forget to drop your questions for our panelists. They're here now with us and you really want to hear their expert opinions on next gen build tools.

I think there are ongoing work trying to standardize CSS imports as well. So a lot of interesting stuff there. I think next-gen tools, in general, try to play along with these native standards that is coming up and try to leverage as much native capabilities as possible. Another aspect is, I guess, next-gen tools don't really limit itself to be strictly JavaScript. As long as, you know, you serve the purpose of a build tool, we can leverage tools, lower level tools written in other languages, or the tool itself can be written in other languages other than JavaScript. That's just my two cents.

It's more type safe. It's more secure sometimes. It's polyglot like Evan already said. I have this dream of calling it essentially scripting core sorry, scripting shell and systems core. That's a lot of what people are moving towards, too. And then some kind of isomorphic JavaScript coming in the form of things like Astro, which Fred is also working on. So there are a bunch of ideas all thrown in there. There's no overall theme apart from, these are just newer and haven't been worked on before. So if you want to call a line of, like, next-gen, I think these are the directions that people are exploring. Interesting. You mentioned Rome, so we'll keep that in mind because that's going to be one of the next things we're talking about. But I want to let Fred also answer the question.

So first, Fred, introduce yourself and also give us your little take on what an FGen filter is. Yeah, definitely. I mean, I'm still laughing at Sean, JavaScript journalist. That is just, I've never had a title for what you are, but that's actually spot on. No, I mean, that blog post kind of nails where we saw our vision. So I've been working on a project called a Snowpack for a while now. And before that, something called ES Install. And now the launch yesterday was something called Astro. And all of this has been about exploring the space of what is a next gen build tool. And when we got started, it was kind of a lot of what's already been said, right? There's this real shift towards using more stuff in the browser, native browser, native JavaScript, and relying less on all the tooling that you can, which was kind of to kind of give a dramatic summary of where we were coming from over the last decade. It was like, webpack will do everything.

And so, there's been a real move towards other tools to solve bundling using more compiled languages and WASM. I don't think any of these tools would be half as impressive as they are if we weren't able to rest on the shoulders of ES Build and SWC. So, a huge shout out to them. They're kind of powering a lot of this at the lower level. And then, yeah, just like letting the browser catch up over the last decade. We are now able to rely on these really cool native primitives in the browser, which just drops the amount of work you need to do as a developer, your tooling needs to do, and you get a much simpler baseline of tooling as a result. That's really interesting.

Okay, that was very helpful. Swiggs, I'll let you take it from here. Tell us a little bit about yourself and what you consider to be a next-gen build tool. Yeah, I feel the most imposter syndrome here, because I don't actually work on a next-gen build tool. I more or less serve the role of JavaScript journalist, so I write about these tools and I try them out rather than actually build one. So a lot of respect to the other two who are here. I think the only reason I'm here is because I wrote this blog post about the third age of JavaScript, which I think Fred is also going to talk about.

So I had a few definitions. They're ES modules first. They're collapsing layers. Sometimes we used to have this Unix philosophy in JavaScript where each tool does one little part of the tool chain. You can see a consolidation of jobs into a single tool, which is partially what Roam tools does. It's more type safe. It's more secure sometimes. It's polyglot like Evan already said. I have this dream of calling it essentially scripting core and sorry, scripting shell and systems core, and that's a lot of what people are moving towards too. And then some kind of isomorphic JavaScript coming in the form of things like Astro which Fred is also working on. So there are a bunch of ideas all thrown in there. There's no overall theme apart from these are newer and haven't been worked on before. So if you want to call a line of next gen, I think these are the directions that people are exploring.

Interesting. And you mentioned Roam, so we'll keep that in mind because that's going to be one of the next things we're talking about, but I'm going to let Fred also answer your question. So first, Fred, introduce yourself and also give us your little take on what a next gen fill tool is. Yeah, I mean, I'm still laughing at Sean JavaScript journalist. That is just never had a title for what you are, but that's actually spot on. No, I mean, that that blog post kind of nails where we saw our vision. So I've been working on a project called a snow pack for a while now and before that, something called ES install. And now the launch yesterday was something called Astro. And all this has been about exploring the space of what is the next gen build tool. And when we got started it was it was kind of a lot of what's already been said, right? There's this real shift towards using more stuff in the browser, native browser, native JavaScript and relying less on all the tooling that you can, which was kind of, you know, to kind of give a dramatic summary of where we were coming from over the last decade was like webpack will do everything.

So, I like the comparison to older tools, but since you touched on it briefly, I'll let you unpack that, ironically, and tell us a little bit about the differences, right? So, what you were using until now, and what has been significantly improved now that you can adopt next-gen built tools? Yeah, sure. So I might be the most kind of like old man yelling at clouds on this because we started looking at this so early when it was just like a web-packed dominated space, and now there's a ton more options. But at the time, this was back in like 2018, 2019, you just couldn't import React in the browser. You had to basically either use a bundler or use the UMD build, which means you're like window.reactdm and window.reactdomin, and doing this more manual approach, it really just didn't have the same convenience of you go into a web-pack and you're actually able to use ESM, and you're able to use a syntax that feels really modern and fresh. But behind the scenes, web-pack was like taking that and doing a lot of work to bundle it for you so that it would run in a browser that maybe didn't have that primitive, that import-export syntax. And so, a lot of my early days were like, no, you don't need to do all this, but it was only because these primitives were now finally in the browser. And so, yeah, they dominated the last decade because it was really the only way to get a modern developer experience that actually ran in all browsers. But what we've seen now that we have these primitives is like some of just the basic core understandings of what a DevTool is are being revisited. So the idea of having to rebundle your site every time you would save or run a bunch of processing on large chunks of your site during development, those are being revisited, and a lot of them are going away in favor of what V8 and Snowpack both do, which is treating your individual files as individual builds and not necessarily having to, oh, Evan, I don't want to speak for you, I think Snowpack might go a little more dramatically in this direction, but thinking of even the bundler as an optional tool in your toolchain. And if you don't need to bundle, you don't care about that, you don't have to, you can kind of bring it in as you want to go when you're ready to tackle performance or to go to production. So all of these fundamental things about how we build websites are being revisited for the first time in a while. It's a really exciting time.

Yeah, it sounds exciting. Evan, I'll allow you to chime in here and tell us a little bit about how V8 is different, what V8 is focusing on, what's kind of in the roadmap in terms of taking it forward as a next-gen build tool. Sure. So for me, V8 started really with the itch that I have for myself because we built Vue CLI, which is webpack-based. And when I built Vue CLI, we had this kind of a lesser-known command called VueServe, which is a global command that just allows you to spin up a dev server for a Vue file without any configuration at all. You just need a file, and you can use that command to spin up a dev server. And I like that, but over time, it's still like, in order to do it, you have to install global Vue CLI, and the whole process is still slower than I would've hoped. I always wanted to have this thing where I can literally spin up a dev server in milliseconds and have something on the screen immediately. When I saw browsers started to land native ES imports in the browser, and I was playing around with it, and I was able to actually just compile a Vue file on the fly in the request, and I had that proof of concept, but at that time, it really was just a proof of concept, because around that time, very few people actually used native ES imports, and I was like, maybe this is just too early, but a year or two later, I realized, oh, all the major browsers today actually ship with native ES imports. Maybe it's time to revisit that idea, but at the same time, I was trying to figure out how hot module replacement would work over it, because that's becoming something that's kind of essential for large-scale workflows. And I revisited the project, finally figured out how to do hot module replacement with native ES modules, and that was kind of the initial shape, how Veed took shape. And I realized this could be more than just a prototyping tool, so at a higher level, Veed is built on top of that and we're trying to really, I think the initial goal was to provide something closer in development experience to Vue CLI, because we want to have a lighter, leaner, modern equivalent to Vue CLI for our users. But along the way, as we build more and more of the features, like move the equivalent features into Veeds, realize a lot of them are not Vue specific, they can actually help be used in other frameworks too. A lot of the stuff is shared, like how you handle CSS or how you want to actually build. In terms of build, Veed is a bit more opinionated because we want to have the tool that handles the dev server and the build process in the same tool, because people are used to Vue CLI doing that. So we kind of want to carry over that characteristics. And eventually, we essentially extract all the things we learned in Vue CLI, combined with these new ideas, and came up with something that... I think one of the interesting things is Veed is designed to be a bit more out of the box, so that existing users of Vue CLI or Create React app can kind of move over a bit more seamlessly, because it kind of caters to what they're used to, like the way certain things are supposed to work.

And so there's been a real move towards other tools to solve bundling using more compiled languages and wasm, you know, I don't think any of these tools would be half as impressive as they are. If we weren't able to rest on the shoulders of ES build and SWC. So a huge shout out to them. They're kind of powering a lot of this at the lower levels. And then yeah, just like letting the browser kind of catch up over the last decade we are now able to rely on these really cool native primitives in the browser, which just drops the amount of work you need to do as a developer. We're tooling needs to do. And you get a much simpler baseline of tooling as a result.

I guess it's becoming sort of a shared convention among the tools, so we kind of do a bit more in that aspect. So yeah, I think at a high level, we really want Vue to be something that you can actually ship production sites with today, because we have existing users who are using a tool that we've built previously. They're already shipping stuff to production, so we kind of want our new thing to be able to let them actually move production sites over, instead of saying this is all just explorative, don't use it for production. So we've really spent a lot of time trying to make sure there's feature parity among these things. I guess, yeah, so in some way we have to make a lot of more pragmatic trade-offs, where say we really hope we can bundle with ESBuild for production, but at the same time, there are certain things still it's kind of hard for us to do with ESBuild directly, so we eventually opted to use Rollup for production builds. So a bunch of trade-offs we made are really trying to just make sure existing users can still get what they're used to, but still get some of the benefits of the new development models during development.

That's awesome, really great work. So I'm gonna, actually, because Swig's mentioned Roam before, and we don't have anyone from Roam on the panel, although they were invited, so we wish they were here, I'll let you take a stab at kind of taking an overview on Roam and how it differs from the tools discussed already, and then we'll move on to more stuff. So I, again, I don't feel qualified to talk about it, but I have talked with Jamie and Sebastian, and so Roam is a, it's not at the same level as Veetz or Skypack or Snowpack, it's more on the level of trying to replace a bunch of tooling, so if you look at their, they actually published, when they announced their fundraising information as a company, they published their investor Slide deck as well, so I would actually share that in the Discord, but essentially they're trying to replace Babel, Webpack, Sass, Storybook, ESLint, Prettier, Styleint, Gulp, Jest, NPM, PostCSS, YesDoc, TypeScript, Cursor, and so on. Sounds ambitious. Yeah, so kind of like the all-in-one tooling, and I actually kind of view it as like Node's answer to Denno in a sense of like, Node has a very defined feature set right now, but it doesn't do a lot of the other stuff that we want like formatting, like linting, where we typically have to configure all this, so you would take an existing Node application and slap Roam on top of it. I mean, it also does bundling, so that's where it competes, but its scope is a lot bigger, and it also has zero dependencies, so they want to write all this from scratch. I think the other strong opinion that they have is they want to write it all in TypeScript, so there's none of the polyglot tooling pieces in here as well, so it's a very strongly opinionated framework. Right now, they only do linting, as far as I know. So the vision versus the reality today is still very stark, but these two people have some of the strongest track records in JavaScript, so it's definitely worth paying attention to.

That's really interesting. So I like the comparison to older tools. But since you touched on it briefly, I'll let you unpack that, ironically, a little bit. And tell us a little bit about the differences. So what you were using until now, and what has been significantly improved now that you can adopt next gen build tools?

Yeah, sure, so I might be the most kind of old man yelling at clouds on this. Because we started looking at this so It was just like a web app dominated space and now there's a ton more options. But at the time, this was back in like 2018, 2019. You just couldn't import react in the browser. You had to basically either use a bundler or use the UMD build, which means you're like window.reactin and window.reactdomin. And doing this more manual approach, it's really just didn't have the same convenience of you go into a web pack and you're actually able to use ESM, and it feels really modern and fresh. But behind the scenes, Webpack was like taking that and doing a lot of work to bundle it for you. So that it would run in a browser that maybe didn't have that primitive that import exports and text. And so a lot of my early days were like, no, you don't need to do all this, but it was only because these primitives were now finally in the browser. And so again, it dominated the last decade because it was really the only way to get a modern developer experience that actually ran in all browsers. But what we see now that we have these primitives is like some of just the basic core understandings of what a dev tool is are being revisited. So the idea of having to rebundle your site every time you would save or run a bunch of processing on large chunks of your site during development. Those are being revisited and a lot of them are going away in favor of what Viet and Snowpack both do, which is treating your individual files as individual builds and not necessarily having to, well, Evan, I don't want to speak for you. I think Snowpack might go a little more dramatically in this direction, but thinking of even the bundler as a optional tool in your tool chain. And if you don't need to bundle, you don't care about that, you don't have to, you can kind of bring it in as you want to go when you're ready to tackle performance or to go to production. So, all of these kind of fundamental things about how we build websites are being revisited for the first time in a while. It's a really exciting time.

Sounds exciting. Evan, I'll allow you to chime in here and tell us a little bit about how Vite is different, what Vite is focusing on, what's kind of in the road map in terms of taking it forward as a next gen build tool. So, for me, Vite started really with the itch that I have for myself because we built Vue CLI, which is webpack-based. And when I built Vue CLI, we had this kind of a lesser-known command card, Vue serve, which is a global command that just allows you to spin up a dev server for a Vue file without any configuration at all. You just need a file and you can use that command to spin up the server. And I like that, but over time, in order to do it, you have to install global Vue CLI and the whole process is still slower than I would have hoped. I always wanted to have this thing where I can literally spin up a dev server in milliseconds and have something on the screen immediately. So, when I saw browsers started to land native ES imports in the browser, and I was playing around with it. And I was able to actually just compile a view file on the fly in the request.

It's interesting that's where you kind of wrapped it up because that's the first question that came in from the community, is actually about opinionated versus configurable as a tooling trend. So can you unpack that a little bit? The question was really Webpack and Babel are both super flexible, but ESbuild is intentionally not, Roam all in one, and you talked about Roam being a little bit opinionated, so a little bit about more opinionated build tools versus the more configurable and flexible ones.

I think it's a false dichotomy essentially. We had a brief period where zero config.js was cool, and then we were like, oh actually, no, everyone needs to config stuff, so we'll try to have good defaults. I think that's what everyone wants. Yup, thanks for that. Awesome. Fred, what are your thoughts? Yeah, I was muted there. I feel like I'm cheating. I actually asked my question trying to just kind of see if this idea works. No, my name is different on Discord, so I promise that wasn't intentional.

No, I think there's something interesting going on here. I don't know if it's as concrete as a real trend, but there is this idea that you see this in Webpack and Babel, this like full customization of a plugin can do anything. You can customize your build entirely. It's this really powerful platform. I'm not seeing that as much in the newer tools, like ES Build is really being intentionally like where it's JavaScript, you can maybe compile something like Svelte or U2 JavaScript, but we're not giving you as much control as Webpack did. I think over the years, it's one of the reasons these platforms are so popular, but at the same time you still have people having trouble upgrading from Webpack 4 to 5 so much longer after its release.

And I had that proof of concept, but at that time it really was just the proof of concept because around that time, very few people actually used native ES imports. And I was like, maybe this is just too early. But, a year or two later, I realized, oh, like all the major browsers today actually ship with native ES imports. Maybe it's time to revisit that idea. But at the same time, I was trying to figure out how hot module replacement would work over it because that's kind of becoming something that's kind of essential for large scale work flows. So I revisited the project, finally figured out how to do hot module replacement with native ES modules, and that was kind of the initial shape, how VEED took shape. And I realized this could be more than just a prototyping tool.

So at a higher level, VEED is built on top of that. And we're trying to really to, I think the initial goal was to provide something closer in development experience to Vue CLI, because we want to have a lighter, leaner, modern equivalent to Vue CLI for our users. But along the way, as we built more and more of the features, like move the equivalent features into VEED, realized a lot of them are not Vue specific. They can actually help, you know, be used in other frameworks too. Like a lot of the stuff is shared, like how you handle CSS or how you want to actually build in terms of build, VEED is a bit more opinionated because we want to have the tool that handles the dev server and the build process in the same tool, right, because people are used to Vue CLI doing that. So we kind of want to carry over that characteristics and eventually we essentially extract all the things we learned in Vue CLI combined with these new ideas and came up with something that, I think one of the, one of the interesting things is VEED is designed to be a bit more out of the box, so that existing users of VCI or Create React app can kind of move over a bit more seamlessly because it kind of caters to what they're used to, like the way certain things are supposed to work. I guess it's becoming sort of a shared convention among the tools. So we kind of do a bit more in that aspect. So, yeah, I think at a high level, we really want VEED to be something that you can, you can actually, ship production sites with today, because we have existing users who have, who are using a tool that we've built previously. They're doing, they're already shipping stuff to production. So we kind of want our new thing to be able to let them actually move production sites over, instead of saying this is all just explorative, don't use it for production. So we really spend a lot of time trying to make sure there's feature parity among these things. I guess, yeah, so in some way we have to make a lot of more pragmatic trade-offs where, say we really hope we can like bundle with ESbuild for production, but at the same time, you know, there are certain things we, still, it's kind of hard for us to do with ESbuild directly, so we eventually opted to use Rollup for production builds, right, so a bunch of trade-offs we made are really trying to just make sure existing users can still get what they're used to, but still get some of the benefits of the new development models during development.

Awesome. Really great work. So I'm going to actually because Swig mentioned Rome before, and we don't have anyone from Rome on the panel, although they were invited, so we wish they were here. I'll let you take a stab at kind of taking an overview on Rome and how it differs from the tools discussed already and, um, and then we'll move on to, uh, more stuff. So I, yeah, again, I don't feel qualified to talk about it, but I have talked with Jamie and Sebastian. Um, and, uh, so Rome is a, is a. It's not at the same level as VITs or Skypack or Snowpack. Um, it's more on the, the level of trying to replace a bunch of tooling. They actually publish when they announced their fundraising information as a company, they publish their, uh, their, their investor slide deck as well. So I would actually share that in the Discord.

I think over the years, it's one of the reasons these platforms are so popular, but at the same time you still have people having trouble upgrading from Webpack 4 to 5 so much longer after its release. And Babel, it's a big ecosystem, but then it has these problems that maybe Roam is trying to solve, and it's kind of all in one stack. So I think there is something that's maybe just a constant push-pull and tooling in the web, but all that power, the customization, and like full control it gives you ends up actually being a hindrance when it's taken to the extreme. And I know we see this with Snowpack a lot when people are asking what does it take to migrate from an older Webpack app to Snowpack? The question is really like it kind of depends how deep in the Webpack hole you've gone. If you've customized every possible import to do these things that aren't really JavaScripty it's not really a Snowpack limitation, it's a limitation of using the browser primitives you've dug yourself into the hole you need to dig yourself out of. So you know it's this interesting push-pull between the two.

Interesting. We want to fit a lot more into this panel, so I'm going to ask you, Evan, just to keep your answer brief so we can move on to some of the questions from the community that are coming in. Folks want to ask this Powerhouse team some questions. So quickly on this one and then we'll wrap up this one. Sure, sure. Yeah, so my personal experience with V is kind of similar, like I think it kind of plays with how Webpack initially started not just only targeting web apps, right, you can actually use it to just bundle a node.js package and ship it for node.js. So it was designed to cover a much wider range of use cases and it still do, right, which just increases the the problem surface and its inherent complexity. It has to be that flexible to be able to handle all these different cases, but on the other hand say Vtorch Snowpack, we are kind of really just focused on the web where we're built with the assumption that you're trying to build a web app, right. When you define the problem space to a narrower one, you can make more assumptions, you can sort of come up with more conventions to make it more streamlined because we know you are dealing with a specific type of problems. But still even within that, there are always kind of this sort of you kind of have to figure out where the sensible defaults really kind of fall. You can only figure that out over time, right, when people actually build things with your stuff and you realize what makes sense, what doesn't.

Um, but essentially they're trying to replace Babbel, Webpack, SaaS, Storybook, ESlint, Prettier, Stylint, Gulp, Jest, NPM, PostCSS, ESDoc, TypeScript, Cursor, etc. Yeah. So kind of like the all-in-one tooling. Node's answer to Deno in, in a sense of like, Node, Node has a very defined feature set right now, but it doesn't do a lot of the other stuff that we want, like formatting, like linting, uh, where we typically have to configure all this. So you would take an existing Node application and slap roam on top of it. I mean, it also does bundling, so that's where it competes. Uh, but it, its scope is a lot bigger. Um, and it also has zero dependencies. So there, they, they want to write all this from scratch. I think the other strong opinion that they have is they want to write it all in a TypeScript. So there's no, there's none of the polyglot tooling thesis in here as well. So it's a very strongly opinionated, uh, framework, um, right now they only do linting as far as I know. Uh, so that's the, the, the vision versus the reality today is still very stark, uh, but these two people have some of the strongest track records in JavaScript, so it's definitely worth paying attention to.

Yeah, that makes a lot of sense. The next questions I'm going to just target one or two of you at a time because I want to get stuff in. So next question that came up from the community. Do you think at some point we'll overcome browser limitations, for example, in terms of massive amount of module loading performance? I'll ask the second half of the question in a little bit. So, let's answer that one quickly. Spix, what do you think? At some point is a very long, long time, period. But the VA team has officially said that I think the limit is something like 100 or like, there's just, it's, it's just like a physical limit as to how many you want to load in parallel. So I don't think so. But maybe the other guys can chime in. Go for it, Evan. Yeah, like my personal, like, I'm not too familiar with how VA plans to solve it, but I think the bottleneck is really in the network, like, even locally, say, with the door snowpack, we are No, No. But we are no bundlers doing Dev, right, but we're still loading all these modules over HTTP requests, there's still an overhead. And when the number of parallel requests are large enough. Like even with zero latency, you're still seeing a lot of overhead. So I think the bottleneck is really in the network, like, even locally, say, with the door snowpack, we are No, No. But we're still loading all these modules over HTTP requests, there's still an overhead. And when the number of parallel requests are large enough. Like, even with zero latency, you're still seeing a lot of overhead. So I think the bottleneck is really in the network, like, even locally, say, with the door So I think it's intrinsically difficult problem when you're trying to load this many modules over the network. So I'm not sure if this is something solvable in the short term in the long term, it may have to require some fundamental innovation at the protocol level to to see this change.

What an interesting segue because that's the second half of the question I'm not sure if you already answered it or not, but basically the other half of the question was, we have HDTV, HTTP to have a tongue twister and NDSM but at the same time, we still tend to be better off with bundling one package. Sometimes with code splitting. What are your opinion is missing in the browser ECMAScript standards to allow working modules, out of the box without any performance drawbacks. We can see right now so I feel like you kind of touched on that solid thread expand on that a little bit. Yeah, I mean it's, it's something that everything is constantly getting a bit better like now we have HTTP three, and that's even better at this multiplexing of resources. So, I'm actually separating multiple files being loaded into almost separate streams within that connection so that one drop package doesn't tank the whole connection. There's a lot of stuff going on at the networking layer that's targeting, not really explicitly but kind of unintentionally as just a nice impact here. Better unbundled loading performance. Now that's still not, you know, at the end of the day, 1000 files versus one file it's it's going to be slower. On that first load time, especially, so it starts to become more of a game of trade offs, I would say, where if you're building something that's more of an application right like your inbox on gmail and it's something that you go to you have an open you go back it's like constantly in a tab and open.

It's interesting that, um, that's where you, uh, kind of wrapped it up because that's the first question that came into the community, um, is actually about, um, opinionated versus configurable as a tooling trend. So, um, can you unpack that a little bit? Um, the question was really like, web hack and Babel are both super flexible, but yes, build is intentionally not Roam all in one, and you talked about Roam being a little bit opinionated. So a little bit about, um, opinion, more opinionated, uh, build tools versus, uh, the more configurable and flexible ones. I'll let you continue that and then we'll move on to, uh, Fred and, uh, I think it's a false dichotomy. Essentially. Uh, we had a brief period where zero config JS was cool and then, and then we were like, Oh, actually, no, everyone needs to config stuff. So we'll try to have good defaults. I think that's what everyone wants. Um, awesome. Fred, what are your thoughts? And yeah, I was muted there. I feel like I'm cheating. I actually asked that question, trying to just kind of see this, no, my name's different on discord. So I promise that wasn't intentional. Um, but no, I think there's something interesting going on here. I don't know if it's as concrete as a real trend, but, um, there's this idea that, you know, you see this in Webpack and Babble, this like full customization of a plugin can do anything. You can customize your build entirely. Um, it's this really powerful platform. I'm not seeing that as much in the newer tools, like ES, since ES build is really being intentionally like where, you know, it's JavaScript. You can maybe compile something like Svelte over YouTube, JavaScript, but we're not giving you as much control as Webpack did and, you know, I think over the years, it's one of the reasons these platforms are so popular, but at the same time, you know, you still have people having trouble upgrading from Webpack four to five, you know, so much longer after it's release and Babble, you know, it's, it's a big ecosystem, but then, you know, it has these problems that maybe Rome is trying to solve and it's kind of all in one stack. So I think there is something that's maybe just a constant push pull and tooling and then in the web, but you know, all that power, the customization and like full control gives you ends up actually being a hindrance when it's taken to the extreme. And I know we see this with Snowpack a lot when people are asking, what does it take to migrate from an older Webpack app? To Snowpack? The question is really like, it kind of depends how deep in the Webpack hole you've gone. If you've customized every possible import to do these things that aren't really JavaScripty, it's not really a Snowpack limitation. It's a limitation of using the browser primitives you've dug yourself into holding, you know. Now dig yourself out of. So, um, yeah, you know, it's, it's this interesting push pull between the two. Interesting. Um, we want to fit a lot more into this panel. So I'm going to ask you Evan, just to keep your answer brief, so we can move on to some of the questions from the community that are coming in. Um, folks want to ask, uh, this powerhouse team, uh, some questions. So quickly.

Uh, on this one and then we'll wrap up this one. Sure. Sure. Uh, yeah. So my personal experience with V is, uh, kind of similar. Like, uh, I think it kind of plays with how Webpack initially started not just only targeting web apps, right? You can actually use it to just bundle a node JS package and ship it for node JS. So, uh, it, it was designed to cover a much wider range of use cases and it's still do, right. Which in here just increases the problem surface and it's inherent complexity. It has to be that flexible to be able to handle all these different cases. Um, but on the, on the other hand, say a Vtorch Snowpack, we are kind of really just focused on the web where we're, we're built with the assumption that you're trying to build a web app, right, when you define the problem space to a narrow one, you can make more assumptions, you can sort of, uh, come up with more conventions to make it more streamlined. Uh, because we are, we know you are dealing with a specific type of problems. Um, and, but let's still, even within that, there are always kind of this sort of, you kind of have to figure out where the sensible defaults really kind of fall, it's only, you can only figure that out with over time, right? When, when people actually built things with your stuff and you realize what makes sense, what doesn't.

Yeah, that makes a lot of sense. Um, the next questions I'm going to just target to one or two of you at a time because, uh, when I get stuff in. Um, so next question that came up in the community. Do you think at some point we'll overcome browser limitations, for example, in terms of massive amount of module loading performance, um, I'll ask the second half of the question in a little bit. So let's, uh, let's answer that one quickly. Specs, what do you think? Um, at some point is a very long, long time period. The VA team has officially said that, uh, I think the limit is something like a hundred or like, like there's just, it's, it's just like a physical limit as to how many you want to load in parallel. So. I don't think so, but maybe the other guys can chime in. Go for it. Yeah. Uh, like my personal, like I'm not too familiar with how VA plans to solve it, but I think the bottleneck is really in the network, like even locally say, uh, Vitor Snowpack, we are no, we're no bundlers doing dev, right? But we're still loading all these modules over HTTP requests. There's still an overhead. And when, when the number of parallel requests are large enough, like even with zero latency, you're still seeing a lot of overhead. So I think it's intrinsically difficult problem when you're trying to load this many modules over the network. Uh, so I'm not sure if it, this is something solvable in the short term. In the long-term, it may have to require some fundamental, uh, innovation at the protocol level to, to see this. What an interesting segue, because that's the second half of the question. I'm not sure if you already answered it or not, but, um, basically the other half of the question was, we have HTTP, HTTP, two, that's a bit of a tongue twister and NDSM, but at the same time, we still tend to be better off with bundling to one package. Uh, sometimes with code splitting. Uh, what are your opinion is missing in the browser ECMAScript standards to allow working modules out of the box without any performance drawbacks. Um, we can see right now. So I feel like you kind of touched on that. So I'll let Fred expand on that a little bit. Yeah, I mean, it's, it's something that everything is constantly getting a bit better. Like now we have HTTP three and that's even better at this multiplexing of resources, so, um, actually separating multiple files being loaded into almost separate streams within that connection. One drop package doesn't, you know, tank the whole connection. Um, there's a lot of stuff going on at the networking layer that's targeting. Not really explicitly but kind of unintentionally as just a nice, um, impact here, um, better unbundled loading performance now that's still not, you know, at the end of the day, a thousand files versus one file, it's, it's going to be slower, um, on that first load time, especially so it starts to become more of a game of trade offs, I would say, where if you're building something that's more of an application, right? Like your, your inbox on Gmail, and it's something that you go to, you have an open, you go back, it's constantly in a tab and open, there is this really interesting performance idea where you're not really optimizing anymore for that first page load. You're kind of trying to optimize for someone who's a repeat common visitor of the site.

And then the caching story of a less bundled site kind of becomes an interesting part of this, where if you can, I mean, looking at the extreme of every file individually served to the user, um, what that means that is that when one changes, you do have the opportunity to only ship that one change, um, to the browser. So instead of resending an entire bundle at every time, you know, any engineer at Google pushes a change or you end up re-bundling, um, the entire site and reshipping that to every user, because it blows out the cache of a single bundle. Um, you get something that's much more flexible. There's a ton of complexity that I'm hand waving away there. Fingerprinting, caching strategies, but it becomes less of a. Every use case. You have to do this thing instead, a little bit more of a trade-off based on your use case, based on performance. And, and again, the networking stack continuing to improve in browsers, really being in this kind of evergreen model where they're improving in a much faster clip than they did 10, 20 years ago, that's super interesting.

There is this really interesting performance idea where you're not really optimizing anymore for that first page load. You're kind of trying to optimize for someone who's a repeat customer a visitor of the site, and then the caching story of a less bundled site kind of becomes an interesting part of this, where if you can. I mean looking at the extreme of every file individually served to the user. What that means that is that when one changes you do have the opportunity to only ship that one change to the browser. So, instead of resending an entire bundle and every time you know any engineer and Google pushes the changer, you end up re bundling The entire site and re shipping that every user because it blows up the cache of a single bundle. You get something that's much more flexible, there's a ton of complexity that hand waving away their fingerprinting caching strategies, but it becomes less of a Every use case, you have to do this thing and instead, a little bit more of a trade off based on your use case based on performance and And again, the networking stack continuing to improve in browsers really being in this kind of Evergreen model where they're improving in a much faster clip than they did 10-20 years ago.

That's super interesting. I actually do want to get to use cases, but I see that there are more questions from the community. So I'm going to Ask the questions from the community. And I think we're going to wrap up with the question about like kind of You know the use cases, the ideal use cases for which for which tool. So the next question from the community is, VIT is the new kid on the block for me. How does it compare to Snowpack? Oh, oh, alright, I'll let Swift take that. Wait, wait, wait. VIT or What, why me, why not Fred? Because it's VIT versus Snowpack. I feel like I don't have any objective I would love to hear Evans answer on this. Well, they're both great. Go ahead, Evan. Go ahead Evan, alright. So I think, you know, in terms of just dev performance, the two projects are very similar. Because we're in both native VS modules with hot module replacement. I think the story differs a little bit in terms of production build, where, as I mentioned before, Vite was designed to be sort of help existing UCI or create React app users move over with a similar workflow. Which means they are used to develop then just bundle and build all with the same tool. So Vite intentionally sort of picks this opinionated pre-configured build setup for you. So that it's just one tool that handles both dev and build and because we sort of forces you to go with the build solution that we've picked for you, we are able to make a bit more assumptions and just optimize a bit more. Because certain things you may need to coordinate between your dev server and the build pipeline because we control both. So we can do a bit more coupling there. Certain things, certain features that you do during dev, we can sort of special case in the build to make it more performant in the end. So it's kind of a trade-off. Snowpack on the other hand, sort of separates the two processes a bit more. You can actually build your files on bundled or you can use the built-in ESBuild optimizer or you can use Webpack.

Technically you can use any bundler to bundle VEET source files too but obviously most users just use the default rollup-based bundler. So the trade-off here is with Snowpack, you get to have a few more options but these different options sort of have different trade-offs. You kind of have to look into them and decide for yourself. Whereas VEET is just say, just use this, we do the optimizations, we figured out a lot of stuff for you. So for people who are used to having one tool handle both, it's a more natural transition and we are a bit more focused on providing you with something that's at least an equivalent to what you're used to. Because it really is the primary goal for us, at least in the VUE ecosystem, is it needs to fill the void of VUE CLI for people who want to move off of Webpack.

So personally for me, that's a major difference. But other than that, you know, there are a lot of areas I think where the two projects are really similar in terms of dev experience, both are blazing fast. And. Oh yeah, another thing is because we, we are opinionated on the build setup so you can easily use build. We are sort of giving you this plugin interface that's Rola compatible, which works both in Dev and in production. This is inspired by WMR. Yeah, I really think that's that's the where the main difference lies. And, but it kind of plays into this higher level goal where VEET is sort of trying to inside the VUE ecosystem we're trying to provide an alternative. That's to Vue CLI.

Yeah, that's a spot on summary I think that's they're really, I forgot. Yeah WMR definitely deserves a shout out as well, probably the third tool in this kind of group that's that's exploring a similar space they're all based on the same kind of core principles of like what technology, we're able leverage to get this performance. And then, like Kevin mentioned I think that's probably the biggest where we fit in the existing kind of features and how kind of what delivers what. I think is where the biggest differences so handling your dependencies. Evan I think uses ES build at this point and roll up in the final bundle is built in. Almost completely flips that we saw a lot of trouble using ES build on some of the like React ecosystem packages. So we ended up using or continue to use roll up at that stage. And just waiting for ES build to get a little bit further until we develop that. Again that's that's from a couple months ago so maybe those already been resolved. And then on the flip side yeah we're trying to experiment with ES build as a production bundler. But you know I get roll up as a much more mature tool there so you definitely get a lot more by connecting Webpack or roll up in our final production optimization so really similar kind of spaces we're playing around and it's it's really cool to see how we all connect the tools differently. I'm sure this will kind of we'll figure it out as we go and grow and this will kind of reveal itself.

And then on the flip side yeah we're trying to experiment with ES build as a production bundler. But you know I get roll up as a much more mature tool there so you definitely get a lot more by connecting Webpack or roll up in our final production optimization so really similar kind of spaces we're playing around and it's it's really cool to see how we all connect the tools differently. I'm sure this will kind of we'll figure it out as we go and grow and this will kind of reveal itself.

Yeah. I didn't even realize until you mentioned like we actually completely the opposite. Yeah. Yeah, it's funny. Awesome. And so, adding to the mix from the community someone asked them they'd love to hear your thoughts about using tools like Basil for building web apps. And you had spoken a lot about the blazing fast performance and that kind of being the primary focus for both your tools. So the question was, are these high performance tools the end game goal. Allow you Fred to continue. Yeah, I now feel like I'm not the right person answer this question, I don't have experience with either of those build systems. You know there's definitely something going on here with how these connect but yeah I don't know enough about them to speak on. Okay, great. So Swix do you want to take it? No. I've also not used those. Okay, so Evan. Go for it. Honestly, I don't. I only briefly know about Bazel because when I was at Google I know like this is essentially the open source version of Blaze, which is Google's internal build system. But like when it comes to, say, web apps, a majority of the time you're still kind of spending calling out to your ecosystem tools, like say you're transpiling React JSX, right? That's not part of Bazel. Or you're trying to compile a view file or a spell file. Those are not handled by Bazel. So, just having a build tool itself being fast doesn't necessarily, it just doesn't constitute the major bottleneck in terms of when you're talking about building an entire web application, right? The bundling and minification of JavaScript, these are all sort of front-end specific. Bazel is a generic build tool that does not concern itself with these specific concerns. So, I don't really know if it actually applies in terms of overall performance. I would say you only get this ESBuild-like, quantum-leap type of performance gain when you actually put all these front-end specific concerns and sort of handle them with a native language, right? The reason ESBuild is so much faster in a full bundle plus minification benchmark is because it does all of this inside Go without actually calling out to JavaScript. The moment you have to actually use an ESBuild plugin to call out to JavaScript, it actually kind of slows down the whole thing, too. I'll chip in with a little bit here, if I can.

Yeah, okay. So, last year I actually did a livestream with Minko Gechev from the Angular core team, and he showed off a little bit of how they use Bazel. And they're actually more focused on remote builds. The two of you are more sort of local dev experience, but for them, they kind of want to scale it for remote building and caching. So, I'll drop the link to that livestream there with the timestamp.

Okay, I'm back. I apologize for that. I had some kind of a technical difficulty. My apologies. There's another question from the community and I didn't want to touch on use cases I don't know how much time we have. So I'm going to ask the community question because that's what folks are here for. So the next question was, do you think at some point Angular will swap Webpack with some other build tool? Is Webpack going to catch up with the market? Or will it become a jQuery of build tools? Yes, let's get to the answers on this one. Angular's got its own ecosystem but it doesn't seem to be growing usage among the newer developers. I think if if you have if we have a tool that's deeply integrated with that webpack. Unless you design it from day one to be bundling agnostic, I don't I think it's going to be a difficult trade-off to say we're going to switch to a different bundler because typically when you use webpack you are going to have very very tight coupling with how its plugins work, how its pipelines work, you're going to rely on a lot of specific stuff that webpack provides.

And that is to I think I don't really think webpack is going to become the new jquery, it's still a powerful tool and it probably is still performing enough for a lot of use cases. And it has some pretty important features that other bundlers don't have like say module federation is something that's kind of interesting, which I don't think is presenting other bundlers at this moment. So there's still a lot of interesting stuff that can potentially happen in webpack. So I think it's really too early to say it's going to become the jquery build tools, there's definitely, I mean it's still huge, right, it's still going to be here to stay for as far as I can tell.

Yeah. Okay Fred I'll let you just quickly answer a question and then we really need to wrap up. It's just a really excellent panel, thank you all. No, I have nothing to add, that was very well said. All right so wow, what a really impressive panel. It was a pleasure to have you all here. There's so many more questions I want to ask, these brilliant minds, but we're out of time. So thank you so much Evan, Swix, Fred for being with us on the NextGenBuildTools panel. They are around on Discord if you want to chat with them and ask them more questions. If you have more stuff you wanted to get answered and we didn't have enough time. Thank you so much for being with us. What a pleasure. Thank you. Thanks for having us.

I actually do want to get to use cases, but I see that there are more questions from the community. So I'm going to ask the questions from the community. And then I think we're going to wrap up with the question about like kind of, you know, use cases, the ideal use cases for which, for which tool. So the next question from the community is Vite is the new kid on the block for me. How does it compare to snowpack? Oh, oh, all right. I'll let Sviks take that. Wait, wait, wait, wait. Vite or, what, why me? Why, why not Fred? It's Vite versus snowpack. I feel like I don't have any objective. No, I'm kidding. I would love to hear Evan's answer on this. Okay, so I'll let Fred start and then I'll hear Evan and Fred out. Well, they're both great. I don't know. No, John, you have to pick. You have to pick, we're not leaving until you pick. No, you're lighting the fence. No, I'm kidding. But go ahead, Evan. Go ahead, Evan. All right, all right. We won't put Sviks in and I'll go first. Go ahead, Evan. So I think, you know, in terms of just dev performance the two projects are very similar, right? Because we're in both native ES modules with hot module replacement. I think the story defers a little bit in terms of production build, where, as I mentioned before, Vite was designed to be sort of help existing UCI or create real app users move over with a similar workflow, which means they are used to develop, then just bundle and build all with the same tool. So Vite intentionally sort of picks this opinionated, preconfigured build setup for you. So that it's just one tool that handles both dev and build. And because we sort of forces you to go with the build solution that we've picked for you, we are able to make a bit more assumptions and just optimize a bit more because certain things you may need to coordinate between your dev server and the build pipeline because we control both so we can do a bit more coupling there. So certain things, certain features that you do during dev, we can sort of special case in the build to make it more performant in the end. So it's kind of a tradeoff, right? Snowpack on the other hand sort of separates the two process a bit more.

Right, you can actually build your files unbundled, or you can use the built-in ESBuild optimizer or you can use Webpack. I mean technically you can use any bundler to build bundle V source files too but obviously most users just use the default rollup based bundler. So the trade-off here is with Snowpack you get to have a few more options, right? But these different options sort of have different trade-offs. You kind of have to look into them and decide for yourself, whereas Vite is just use this. We kind of do the optimizations, we've figured out a lot of stuff for you. So for people who are used to having one tool handle both, it's a more natural transition and we're a bit more focused on providing you with something that's... you know, at least an equivalent to what you're used to. Because the primary goal for us, at least in the Vue ecosystem, is it needs to fill the void of Vue CRI for people who want to move off of Webpack. So personally for me, that's a major difference. But other than that, you know, there are a lot of areas I think... the two projects are really similar in terms of dev experience, both are blazing fast.

Oh yeah, another thing is, because we are opinionated on the build setup, so you can easily use build. We are sort of giving you this plug-in interface that's Rolla compatible, which works both in dev and in production. This is inspired by WMR. Yeah, I really think that's where the main difference lies. But it kind of plays into this higher level goal where Vite is sort of trying to... Inside the Vue ecosystem, we're trying to provide an alternative that's to Vue CLI. So the goals may kind of, you know, skewer a little bit, depends on what you're trying to achieve.

Got it, okay, that's interesting. Fred, do you want to add anything? No, that's a pretty spot-on summary. I think that's—they're really—I forgotten— yeah, WMR definitely deserves a shout-out as well. It's probably the third tool in this kind of group that's exploring a similar space. They're all based on the same kind of core principles of like what technology we're able to leverage to get this performance. And then, like Evan mentioned, I think that's probably the biggest— where we fit in the existing kind of features and how—kind of what delivers what from that model, I think, is where the biggest difference is.

So, handling your dependencies, Evan, I think, uses ESBuild at this point. And Rollup in the final bundle is built in. Snowpack almost completely flips that. We saw a lot of trouble using ESBuild on some of the like React ecosystem packages. So, we ended up using—or continue to use Rollup at that stage, kind of waiting for ESBuild to get a little bit further until we develop that. Again, that's from a couple of months ago, so maybe those have already been resolved. And then, on the flip side, yeah, we're trying to experiment with ESBuild as a production bundler. But, you know, again, Rollup is a much more mature tool there, so you definitely get a lot more by connecting Webpack or Rollup in our final production optimization. So, really similar kind of spaces we're playing around in, and it's really cool to see how we all connect the tools differently. I'm sure this will kind of—we'll figure it out as we go and grow, and this will kind of reveal itself. Yeah. I didn't even realize it until you mentioned, like, we actually completely de-opted— It was a complete flip-root. Yeah. That's funny. Awesome. And so, adding to the mix, from the community, someone asked— they'd love to hear your thoughts about using tools like Bazel for building web apps. And you had spoken a lot about the blazing fast performance and that kind of being the primary focus for both your tools.

So, the question was, are these high-performance tools the end-game goal? I'll allow Hugh, Fred, to continue. Yeah. I now feel like I'm not the right person to answer this question. I don't have experience with either of those build systems. You know, there's definitely something going on here with how these connect, but yeah, I don't know enough about them to speak on them.

OK, great. So, Swicks, do you want to take it? No. I have also not used those.

OK, so Evan, go for it. Honestly, I only briefly know about Bazel because, when I was at Google, I know this is essentially the open source version of Blaze, which is Google's internal build system, but when it comes to, say, web, web apps, a majority of the time you're still kind of spending calling out to your ecosystem tools, like, say, you're transpiling React JSX, right? That's not part of Bazel, or you're trying to compile a Vue file or Svel file. Those are not handled by Bazel. So, just having a build tool itself being fast doesn't necessarily... It just doesn't constitute the major bottleneck in terms of when you're talking about building an entire web application, right? The bundling and minification of JavaScript, these are all sort of front-end specific. Bazel is a generic build tool that does not concern itself with these specific concerns. So, I don't really know if it actually applies in terms of like overall performance. Like, I would say, you only get this like ES build like quantum leap type of performance gain when you actually put all these front-end specific concerns and sort of handle them with a native language, right? The reason ES build is so much faster in a full bundle plus minification benchmark is because it does all of this inside Go without actually calling out to JavaScript. The moment you have to actually use an ES build plugin to call out to JavaScript, it actually kind of slows down the whole thing too.

I'll chip in with a little bit here if I can. Yeah, okay. So, last year I actually did a livestream with Minko Gechev from the Angular core team and he showed off a little bit of how they use Bazel and they're actually more focused on remote builds. So, the two of you are more sort of local dev experience but for them, they kind of wanna scale it for remote building and caching. So, I'll drop the link to that livestream there with the timestamp. Shareel, it's gonna be gone. Okay, I'm back. I apologize for that. I had some kind of a technical difficulty, my apologies. There's another question from the community and I didn't wanna touch on use cases but I don't know how much time we have. So, I am gonna ask the community question because that's what folks are here for. So, the next question was, do you think at some point Angular will swap Webpack with some other build tool? Is Webpack gonna catch up with the market or will it become a jQuery of build tools? So, yes, let's get to the rapid answers on this one. I don't know, Angular's got its own ecosystem but it doesn't seem to be growing usage among the newer developers.

Honestly, I think if we have a tool that's deeply integrated with Webpack, unless you design it from day one to be bundled agnostic, I think it's going to be a difficult tradeoff to say, we're going to switch to a different bundler because typically when you use Webpack, you are going to have very, very tight coupling with how its plugins work, how its pipelines work. You're going to rely on a lot of specific stuff that Webpack provides. I don't really think Webpack is going to become the new jQuery. It's still a powerful tool and it probably is still performing enough for a lot of use cases. And it has some pretty important features that other bundlers don't have. Like I say, Module Federation is something that's kind of interesting, which I don't think is presenting other bundlers at the moment. So there's still a lot of interesting stuff that can potentially happen in Webpack. So I think it's really too early to say it's going to become the jQuery build tools. There's definitely... I mean, it's still huge, right? It's still going to be here to stay for as far as I can tell.