Towards a Unified Toolchain for the Web // Evan You

This talk focuses on V Plus, an innovative project building upon the foundation of the V framework. The speaker discusses the motivation behind developing a new bundler specifically designed for V, addressing limitations of existing tools like ESBuild and Rollup. V Plus aims for compatibility and performance, offering enhanced capabilities for modern web applications that require more efficient handling of resources. The speaker explores the challenges faced in assembling a cohesive and efficient toolchain, detailing how they have created a unified system with components like OX Linter and OX Format. As web development increasingly merges with AI, the talk emphasizes the importance of fast and integrated tools to optimize developer productivity.

applause for our last talk of the day. >> [applause] >> All right. Hello everyone. Glad to be here again. So this this year I'm going to be talking about V Plus which we already kind of know what it is. We revealed it at V Conf last October. But that was like a super early sort of just like telling everybody like we're actually working on this thing and

what it's supposed to do. So a few months later it has come a bit closer to the real thing. But it's a big scope, right? So I kind of want this talk is more about like explaining where how do we get this idea to do this thing? Where did it start? What did we have to do? Like really what what what's the work that's actually involved in

building something like this and where it is now. Okay. So obviously V Plus it all started with V. I assume a lot of you probably have heard of V. Many of you probably use it in some way. Do you raise your hand if you you've used it? Woo. Okay. I'm not going to bore you with the the long original story of how V started cuz we have

a documentary for it. So if you haven't watched it, go to YouTube. Just search for the V documentary. It's pretty cool. Um so the the real starting point of me thinking about this started with just still like it's within the V scope, right? I was just thinking about okay, like how can we make V better? What are the problems that still exist in V and right? The

fundamental issue is V. Let's be honest, right? V V7 and all the versions before it's a layer that kind of glues together ES build, roll up, SDC and a bunch of other things. V in itself is not really a bundler. It never had been, right? We rely on other bundlers like ESBuild and Rollup. And this creates problem, right? So, again, I won't go into too much details,

but these problems are happening lobbying there. They're written in different languages, have different behavior trade-offs, different performance trade-offs, and our conclusion is, okay, like let's build our own bundler. For Veet, only for Veet. Well, it's not only for Veet because you can use Road out directly as a ESBuild/Rollup replacement because our design goal was to build a bundler in Rust that has ESBuild feature parity and Rollup

API compatibility. And it also has to be faster than than both, right? So, obviously much faster than Rollup, and we're pretty close with ESBuild cuz ESBuild is like amazingly fast already, right? Road out is slightly faster on some systems, slightly slower on some systems, but we are in the same performance category with ESBuild. Okay. Um And as we are building the bundler, right? Uh So, we had

a talk talking about building your own framework. Any of you here have tried to build your own bundler before? Okay, not many, right? It's a pretty pretty niche, pretty specialized field. Uh but if if you think about how to build a bundler, you like we'll realize, okay, like we need a parser, we need a resolver, we need a transformer. We need to do all these things, especially

considering if we're trying to reach for ESBuild feature parity, ESBuild does a lot of stuff out of the box. It transforms TypeScript, it transforms JSX, it does minification, it does uh a lot of stuff, okay? So, we need all of these things, right? With Rollup, Rollup core is actually pretty lean. It's pure ESM. Like you actually have to use a plugin to resolve node modules. Like that's

a resolver plugin, right? ESBuild does all of this out of the box. So, in order to do all of that, we need a essentially a full list of tools to support the bundler itself. So, we looked at the options and turns out um it's it there are a lot of options, right? Like even within JavaScript world, uh you have many, many different parsers. So, if you've worked

at the tool chain level, you probably know there's like Babel, Acorn, Esprima, uh SWC. ESBuild wrote its own parser, right? So, they all all of these different parsers have slight different ASTs. There is a semi-standard called ES tree, but not every parser really adheres to it. Like ESLint has its own AST format. So, it's like it's a mess, right? So, and the the worst problem really is

like when you think about the minification and the transformation, like Babel. Babel is the main transformer everybody uses, right? Babel has its own AST, has its own parser. And then there was a plugin called Babel minify, but nobody uses it because it just doesn't work well enough. So, everybody uses uh Uglify uh and later on Terser, right? We probably a lot of you probably use Terser. Terser

again has its own parser. it's based on the UglifyJS parser because Terser is a fork of Uglify. And so, when you're building a typical Webpack application, Webpack uses Acorn as a parser, by the way, right? So, if we think about like the traditional like a legacy application where it's like Webpack, Jest, uh Babel plugins, Terser, right? A single piece of code gets parsed by three to four

different parsers and then like transformed and mangled around and generate all the source maps and merge together, right? That's why the in the old days these Webpack plus Babel builds are so slow because it's just extremely inefficient because of the fragmentation and inconsistency. So, if you were building a just a bundler, it won't really solve much because then people will still be using Babel and it will

still be slow, right? So, we can't really stop here. We have to just go deeper if we really want the best best performance and, you know, the best So, take a step back and think about like why how do we get here? Like why are we suddenly dealing with this kind of problem? We're just building web applications, right? You're supposed to just write a HTML page and

put it online. That's how it's supposed to be, Well, the thing is we stopped building these simple pages long time ago. We are starting to treat the web not just as a page display thing. It's now an application delivery platform, right? We're shipping real apps on the web. So, we're building bigger and bigger things, right? All the problems and scaling issues that you run into with the

traditional application engineering, they all apply to web applications now, right? So, as your files getting larger, you need modules. JavaScript didn't come with that. So, we came up with our own mechanisms like AMD, CJS, ESM. We're now finally like everyone's like you should use ESM, but we're still not quite there yet. There is reusable code distribution. So, people built NPM. Actually, previously there was still a thing

called Bower. How many of you have used Bower? Right. Okay, so then there are too many requests. So, you need bundling. Let's just like put everything together. The the crudest form of bundling was really just concatenate all the things together, right? And when you concatenate, you realize, okay, like all these variables are global. They will pollute one another. So, I have to wrap everyone in a IIFE

in a in a function closure and make sure to add a semicolon at the end of it because otherwise your first closure will be calling the second closure and it just goes crazy, right? Um so, not going going to go through the whole list, but you get the point, right? All these are real problems that we run into when we try to build more ambitious stuff, which

the JavaScript language itself just never thought about these things because Brendan Eich invented the language in 10 days and he was like, "This is just for one-off scripting. It's not meant to build anything ambitious." And turns out JavaScript developers are like, "Yeah, we're going to build Gmail with it." Um so, now we are faced with these problems. okay. So, we started inventing tools. JavaScript developers started inventing

tools to solve our own problems, right? So, there are tools written in JS for JS, right? These are kind of the OGs of JS tooling now, right? Babel, Acorn, Esprima, Browserify. How many of you use Browserify? Right? It's it's pretty pretty cool when it first came out. Then there's Rollup, Mocha JS, Uglify, Terser, ESLint, Prettier. Like I'm putting ESLint and Prettier in this category because we're we've

built something much faster. Um Grunt, npm, Yarn, right? So, these are tools all written in JS for JS. And many of them are great pieces of technologies. They solved the real problems that JS devs are facing. In no way say I'm saying like any of these are bad, right? They came at the right time to solve the right problems. But we are seeing these some of these

tools are running into the limitations or or just like we're just building too like the things we're building now are too big, simply too big. They're too complicated, right? So, tools written in JavaScript and also like the fragmentation problem I said, like in the whole pipeline you're using different tools to process your code repeatedly with different parsers and merging them back together. That makes things slow. So,

this next gen, we call it the tools written uh in native languages for JS, right? So, it's native for JS. Starting around like 5 to 6 years ago, I think uh ESBuild was probably the one that made everyone realize like, "Okay, JS tooling is actually pretty slow." Right? When it came out, like the thing is still on ESBuild's ESBuild's uh homepage. It's like the graph showing like

uh webpack plus terser takes like 100 seconds, where ESBuild is like 100 ms or 1 second or something, right? So, literally 100 times faster. Um and then there's SWC, uh there's Oxc, there's Biome, which kind of evolved from the Rome tooling. And then there's RSpack, which is the Rust pack uh Rust port of webpack. There's Turbopack, was ironically created by the original author of webpack, but it's

not actually a a fork of webpack. And then there's Row Down, which is built by us. There's TS Go, TypeScript team is rewriting TypeScript in Go. There's Turbo Repo, NX. JSR, the registry and client are written in Rust, I believe. Volt. Actually, they Volt rewrote the thing in in TypeScript, got to take them off this list. And then obviously there's Bun, which is written in Zig and

extremely fast, right? So, native tools. How Just how much faster are they? Right? SWC is 20 to 70 times faster than Babel. Oxc link first ESLint, right? So, you get the idea. A lot of this um comes from the raw speed of the line compiled languages, and also because these native languages are able to leverage modern CPUs parallelization a lot better than JavaScript. JavaScript is single-threaded, even

with worker pools. Like you still incur a lot of data passing, right? So, even orchestrating, say, plugins through a worker pool, it doesn't fundamentally change the fact like JavaScript is CPU-inefficient. especially on a beefy dev machine, like when you have 12 cores, you'd want to use all of those cores. Um okay, so, but it's still fragmented, right? So, we set out to change that. Um So, when

we were This is the conclusion we came up with when we started thinking about that idea like way back before, right, a lot of these tools got a lot more mature, right? So, uh I actually started a company to sort of solve this problem because I realized, okay, I can't write all the code myself. I have to like find a way to be able to pay people

to work on these problems. Uh and starting a company seemed like, you know, a very realistic way to achieve that. So, that's why uh that's how Void Zero came about, right? So, we maintain a bunch of projects, Vite, Vitest, Rollup, and oxc. And uh these new logos are pretty recent. We just did a whole like rebrand to pull all these open-source projects into a coherent sort of

identity and branding. So, uh this is kind of aligns with the our goal of trying to build something that's more unified, that a system that works together really well. Uh at the high level, we have uh oxc, which is kind of like the most low-level infra layer that comes with the parser, transformer, et cetera, which is used in Rollup. It supports Rollup. Rollup uses all these oxc

pieces. And then, Rollup supports Vite. Vite supports Vitest. And Vite and Vitest are the most direct developer-facing things that a lot of people use. Um and just to get here, the things we had to build, right? Um, it's a massive scope, right? Cuz like just say just start with a parser. Parser is like the first thing you you need in this whole whole thing. 100% ECMAScript 262

spec compliance is actually pretty hard. Like we spend a lot of time setting up the right infra to trace track spec changes and make sure like we pass test 262. And like Babel doesn't even pass the whole thing. Like a lot of the funny things we only got we realized only got into is like when we're building the parser, we find bugs in Babel. Like when we're

building the transformer, we find bugs in Babel. When we're building the linter, we find bugs in ESLint. And then the formatter, we find bugs in Prettier. So it's like we had to like also like cuz sometimes we find the tests just don't pass. We're like, "What's What's wrong here?" And we realize, "Okay, like it's actually a bug in the upstream reference implementation we're trying to trying to

port." Right? Um so tons of work getting this to where they are. Um And in doing the transformer is probably the the part that took the longest time because we literally have to port all the Babel transforms, including all the uh preset env, which is the syntax lowering parts like you make your future syntax downgrade to ES2015. We decided to stop at at ES2015 because going lower

would take like maybe 2 more years or something. So we're like, "Okay, like modern JavaScript, this is where it stops." and we take a lot of care in performance, right? Oxc has probably the it's the fastest in a lot of categories. Not in the minifier space, interestingly. In minifier, there is a Go-based minifier that is very very fast. But uh what we did is Oxc minifier has

probably the best speed and compression ratio, like anything that's faster than that has worse compression ratio, and anything has better compression ratio than that is significantly slower than So, OX lint, right? Uh this is the first kind of application thing that is built on top of OXC, and when when we tried to promote OX lint initially, the biggest feedback from people is like, "I can't move over

from ESLint to OX lint because it doesn't support JavaScript plugins. I have so many custom rules and like ESLint plugins I want to use." So, we spent a lot of time making the Rust core work with JavaScript plugins, and try to solve all the problems of how can we efficiently pass the AST from Rust over to JavaScript without having to do a expensive copy. So, we came

up with some black magic called raw AST transfer, which actually moves the chunk of AST memory from Rust to JavaScript through a shared array buffer, and then lazily deserialize it as your custom plugins visitor visits the AST tree. Right? So, that keeps it fast, keeps it without, you know, slowing it down to a crawl when you use JavaScript plugins, but keeps the core fast. So, we just

recently reached 100% test compliance with the ESLint plugins. So, most of your ESLint custom rules and plugins should just work with OX lint now. If it doesn't, please report a bug. Right? Another important thing we ship is type-aware linting. Powered by TS Go, right? Type-aware linting in ESLint is problematic because because it involves running TSC in a separate category, and then there's a lot of back and

forth between TSC and ESLint. So, it usually will make your linting like 5 to 10 times slower, at the very least. So, we decided to go with TS Go. Uh there's also a little bit of diversion here because biome decided to do type aware linting using their custom type synthesizer, which means they're basically building a type inference engine themselves. which we decided is not the right way

to go because that you will forever be playing catch up with the official implementation and you will never reach 100% coverage. All right, the only way to do pure type aware aware linting is leveraging the the authority the the actual source of TypeScript. And luckily the TypeScript team is like, let's build a faster TypeScript. So we essentially uh extended TSGo to build a linting setup on top

of it and integrate it into oxlint, which means we kind of had to vendor it and we have part of like go binary and rust binary in the same thing. But that's the way it is because go is the most you know, pragmatic language for the TypeScript team to port Uh but this is working surprisingly well, right? So when you run oxlint with dash dash type aware,

it just runs all type aware rules. And then there's ox format. We just recently reached 100% conformance with prettier. So again, you can just move from prettier to ox format and just enjoy like 30 to 45 times faster formatting. it also has a bunch of things like tailwind class sorting support. and uh you know, we're going to add more stuff to it basically to cover a lot.

So ox format is currently in alpha. So uh there are some prettier features that obviously doesn't cover. So the 100% conformance is for JavaScript TypeScript. But it it can actually run prettier plugins, which means you can like format view files or other things with ox format, too. Uh row down. So again, bundler. Like I said, bundler is a very specialized uh very specialized field. Um we again

had essentially merge the scope of ESBuild with the API and the plugin ecosystem of Making sure Rollup plugins actually work in Rōdan. on top of these, we also have to add things that only Webpack has. For example, stuff like uh chunk splitting control. Uh Rollup's chunk control it has an option called manual chunks, which is not as powerful not an equivalent to Webpack's. ESBuild doesn't even have

any control over chunk splitting behavior. So, we know like in production, you need that, right? So, Rōdan actually has Webpack sort of capability equivalent chunk splitting control. We also shipped a lot of thing recently shipped lazy barrel optimization, which means if you have big barrel files, we'll actually only compile the parts that's actually used. And then, we give you things like plugin hook filters and native magic

string, which allows you to keep using your Rollup Rollup plugin syntax, but you just add a few things to make it work faster in this Rust-based world, right? Don't let your JavaScript plugins slow things down. Uh it is Rōdan has recently reached 1.0 RC. It's pretty stable. Actually, I think it we are like at like 4 to 5 million weekly downloads now, which is surprising because uh

a lot of it comes from Angular, probably. And then, there's the V8 integration. So, V8 is the version where Rōdan goes uh becomes the default. Um stable soon, right? Um So, over the year, right? Over the past year of Rōdan, we just we shipped a lot more features, but also made it much faster. So, this is just over 1-year course period, Rōdan got 33% faster, producing 34.5

smaller bundles, and shipped more features. Right? So, um this is the the velocity we want to be moving at. And Vitest, Vitest is a very, you know, Vitest worked because it's kind of like a Jest plate replacement, drop-in replacement. Ironically, the author of Jest, uh the um the the the person who made Jest and managed the Jest team at Facebook now works at Voiro. So, uh he's

now like, "I'm fighting with my past self." But, we want to, you know, uh so so Vitest has browser mode, which is now stable in V4. It has visual regression testing, Playwright traces. So, it's a it's a very comprehensive test runner, uh especially for front-end work, right? So, when you think about feature completeness, I'm not trying to dunk on Bun, but like Bun test it just like

does very little compared to Vitest. Um And then, there's Vite 8. Currently, it's in beta, and we're aiming for stable Vite 8 in March. So, that's next month, okay? After the Lunar New Year. and then, um it's going to be fully Rollup-powered, which means Vite 8 has only Rollup dependency, no ES builder Rollup anymore, consistent behavior between dev and prod, built-in TS config paths support. You no

longer need Vite TS config paths, that plugin. I've seen it so many times, I decided okay, let's just get the get rid of the need for it. We should support it as a built-in, uh and that'll be faster, right? Rollup Vite, which is a previous package that we used for people to proto uh test with the Rollup-powered Vite, it'll be deprecated, and everybody should just upgrade to

Vite 8. And there's this experimental feature in Vite 8 called full bundle mode. As you know, Vite is unbundled, and things can be slow if you have too many source modules. So, full bundle mode essentially goes back to with lazy compilation and just increases the startup time for extremely large applications. So, this is something we've been testing with the Linear team. Linear, uh the the task uh

tracking software, right? Uh it's a it's actually a big Beat app. Uh so, they've been using Beat since beta days and we essentially are working with them to test roll down Beat. They're already on Beat and uh full bundle mode, they're also the first adopter. Yeah. So, State of JS 2025, I kind like we just kept doing what we did. So, I'm not going to like talk

too much about it. We're proud of the love that we get from the community. So, what we hope to see next year is more of our stuff like OX Linter, OX Format, and maybe Beat Plus also on the list. finally getting into Beat Plus, right? Let's We built all of these things and we want to put it into this thing called Beat Plus. Um how many how

much time do I have left? Maybe like 5 minutes. Okay. 5 minutes for Beat Okay. So, we we are doing some redesigns, right? So, if you have watched my talk from last October, obviously like there's a lot of like iterations and just figuring out what is the best form factor. So, the obvious parts is we are integrating all of the tools that we're building together. So, Beat

Dev and Beat Build is powered by Beat and Roll Down, right? They work exactly as Beat Dev and Build. There's Beat Linter, that's powered by OX Linter, Beat Format powered by OX Format, Beat Test powered by Beat Test, and Beat Lib powered by TS Down. TS Down is the Roll Down based TS Up successor. So, it's a it's a dedicated library Comes with a lot of things

that helps you structure your your package nicely for publication. And then there's VP new. That's just a scaffolding and generating part. So you can define your custom templates, too. And some of the more interesting stuff, right? Cuz like all the existing stuff is just like we're just stitching the the dependencies together. You can technically just individually install all of these. That can be tedious to manage all

these versions. So we make it a bit simpler for uh with V plus. But like there are some additional things. Um VP run, VP install, VPN. So these are the things that gets a bit more into the tool chain territory or even run time territory. Um so what does VPN do? It's a node node js version management thing. So it replace It can actually fully replace things

like FNM and NVM. so and then um when you install V plus for the first it'll ask you if you want it to be the node js version manager. Uh even if you say no, right? It'll just leave your global node and NPM stuff untouched. But in your If you're in a V plus powered project and you have things like dot node version files or path manager

field in your path JSON and you do anything with VP dev or VP build, it'll automatically make sure it's using the right version of those things. So that is also what V VP install does. It'll just uh it'll infer the right path manager to use. So you don't need to think about which path manager you're using anymore. Uh if you have the path manager field set, VP

install always use that exact version. It's kind of like a core pack equivalent. And plus like N foo knee equivalent. I don't know how how many of you have used this. I've been using it forever. Basically, it it just makes sure when you run, you just you always use the same install command. Uh, but it'll just automatically use the right package manager to do the install for

you, right? So, you can switch between projects using different manage package managers, and it'll do the right thing. Um, and also like like corepack, it will fetch the right version of that and cache it for you. So, it's like a package manager manager. And then VP run, uh, by default, it'll work just like npm run. Uh, it's a task runner, right? So, if you have npm scripts,

it'll run that script. but it gets more powerful because you can actually, uh, there are some flags that allows you to run tasks in a monorepo in the right topological order, kind of like NX. And then you have often caching. So, if you say VP run with {dash} {dash} cache, or you can set the cache on globally, it'll intelligently cache the scripts you've run. Without By default,

it doesn't even need config because we've implemented at the file system level, it'll know which files you've touched during a task and it'll just cache things in most cases. Um, especially for the built-in commands like VP build, we can just confidently cache all of that stuff if your files didn't change. Right? So, uh, I'm just going to do a really short demo. okay. So, going to remove

this whole So, the installation will be like this. You just like curl https vplus.dev/install and pipe it into bash. Obviously, you should look at the script before you pipe it into your terminal. But after you've done it, uh, actually, I can probably just do it here. don't install this yourself because it's probably going to break on your machine, so. Not sure if the Wi-Fi here Okay, cool.

now I have a global binary called VP. Has a bunch of commands and um if I do VP env ls, it'll This is basically FNM equivalent. It shows I'm using this, right? So, let me do VP new. So, I can just create a V plus application. It'll use PNPM. It'll ask you some AI-related stuff because we want to work with with AI. So, let's do a React

uh why not? So, V plus application. So, uh take a look at the thing. It's It This is actually like exactly the same with the the vanilla V application. I'm showing, you know, the simplified version here uh just to save time. It's the exact same V config uh except now you can actually have additional blocks like langs, right? Every command that we have have a corresponding So,

run, stuff like this. if you have run here, like you can say So, by default, VP doesn't do caching. But, uh you can do tasks here where you can define a bunch of tasks similar syntax similar to Turbo pack, right? So, VP run can also run tasks defined here. You can explicitly define whether a task should be cached. You can orchestrate task dependencies between your mono repo

packages. You can opt out of certain thing You can like manually specify what inputs it should use for cache inference. By default, you don't need to do that because we infer most of the stuff for you. And then there's another thing called true. Um if you do that, then all the scripts in here I need to change these like we just recently changed that. all the stuff

here will also be cached when you do run. So, you don't need to use something like NX or Turbo Repo to get that behavior. So, just quickly see VP build. So, right now we have a behavior that actually caches things by default like cache hit. So, if I do VP run build Oops, no that argument. Uh something breaks. Okay. No previous cache entry found. Okay. So, now

output replayed. We actually can cache like So, one thing to note here is like you are using this syntax here, right? So, this is just like two scripts stitched together. You're using like this. We're able to parse this part and identify that these are two separate steps and cache them separately. So, the TSC build step has its own cache and then the VP build has its own

cache. Right? So, if you only change something that's used during type checking but not in the actual build, the second the second step of the thing can still be a lot of more features. So, actually I think there's a new version file here, right? So, here if I do node V it's showing the right version. So, if I 22 and node V Oops. It noticed that I

don't have no 22, so it'll download it. And now I'm using node 22. uh and if I do VP install, it will make sure it's using PNPM and the right version for me. Uh I can also do like VP install G. This will install it. So, the interesting here is uh And when I install things globally this way, uh this is what I have installed globally. It'll

list the version node version it was installed with, right? So, one thing one pit peeve I have with FNM is with FNM when I install things globally with NPM, and I switch into a different node version, all those global packages are gone, right? So, we don't have this problem here because uh we we remember which node version you installed that with, and even if you are currently,

say, VPN use uh and you run serve, this global, it'll actually still be run with the node node version you you installed with. So, you never have to You just installed it once, you don't have to like think about it after you switch versions, right? Um so, and everything else kind of works as expected. VP links, VP dev, VP build, it's just like exactly the same as

a dependency at the wrap. And the idea here is we want to make getting started with JS dev as straightforward as possible. So, you stop thinking about like, "Oh, I need to first install Node.js, and then I need to understand what a node version patch manager or node version manager is, then I understand the difference between all these patch managers and patch manager managers, what is corepack?"

Uh so, like just to to make things simpler. final bits of this. Why I believe that fast and unified toolchain matters more in the AI era, because this is what everyone's talking about, right? So, if we think about coding agents and the way we code with AI, it's really just a loop of like LM calling tools and decide what to do next. But, tools tools actually plays

an important role in making sure this loop can continue correctly. There are guard rails, normalization, make things more grappable, validation, fast testing is extremely important. So, to facilitate the loop and make the loop smoother, faster, make the agent do less mistakes, right? And there are things like MCP, cool skills, and we want to integrate that into V+ so that it ships with its own skills. It ships

with its own engine CMD. When you upgrade V+, it'll just update its own engine MD parts in your uh in your file and reference the updated skills that comes with the package itself, right? Um and the idea here is AI drastically accelerate how how how fast we ship code. So, this is before AI. We spend a lot of time writing code and we just wait a little

bit of time for tools, right? So, if you spend the whole day just like working on a big problem, and then you wait for a 1-minute build, you're like, "Yeah, that's fine." Right? But, with AI, you're like, "I have an idea and AI just crunch through it like in 10 minutes." And now you're like, "That 10 minutes, you you spend another 5 minutes waiting for it to

build." You're like, "Also, when AI is trying to iterate, every loop it's like, 'Oh, I'm spending another 5 minutes on just linking the code base, right?' Imagine you can squash that 5 minutes waiting for the tools down to 10 seconds." Then how much more efficient your agents will become, right? So, that's AI plus better tools. You uh after AI, the tools actually are taking up a larger

percentage of the time you're spending before you actually ship, right? So, AI with better tools squashes both the time AI spend writing code and also squash the time it's waiting for the tools. So, that's why we think it's essential and that's what we are aiming for V plus to be in the age of AI for web dev. Thank >> That was a fantastic closer. Thank you so

much Evan. So, going to hand it back to Wessel Man Iris to close it off.