I did not expect this...

It's no secret that Vit has taken over the developer world. If you're building on front end and you're not using Vit, you're almost certainly missing out. It

just makes life better. It's the

all-in-one bundler at the core of many different frameworks now. Whether you're

just building with vanilla React or using bigger things like Astro, Tanstack Start, SpeltKit, or more. That's why I was so excited when Evanu announced the company being built around Vit Void Zero. This is also why I was really

Zero. This is also why I was really skeptical when they announced VIT Plus, the private closed source, paid for version of Vit that would handle a bit more. And that's why I'm so excited

more. And that's why I'm so excited about today's announcement that Vit Plus is here in alpha and is no longer closed source. Vit Plus is now released as an

source. Vit Plus is now released as an open-source repo under the MIT license as the new unified tool chain to build with VIT. I am genuinely really hyped.

with VIT. I am genuinely really hyped.

The idea of so many of these parts of your project management, be it packages and dependencies, your actual environment, the testing, scaffolding, packing and bundling, all is one cohesive tool set, even including like

linting, formatting. This is one of

linting, formatting. This is one of those things the web dev world has historically been missing because the tools we use are constantly in flux and changing. But as more and more of our

changing. But as more and more of our tools have been centralized around void zero and their little ecosystem, suddenly this is getting really promising. I'm already using the

promising. I'm already using the majority of the tools they are referring to here. So, what does it look like to

to here. So, what does it look like to move over to V+? That's a great question and I haven't tried it yet and that's why this video is going to be a bit different. I'm going to go through

different. I'm going to go through setting up and using V+ for the first time live. I'm not being paid to cover

time live. I'm not being paid to cover V+ or anything around here. I am not an investor in Void Zero. I missed the round sadly. I am being paid though by

round sadly. I am being paid though by today's sponsor. How many languages does

today's sponsor. How many languages does your website support? If you're building real applications for real users, you're probably leaving over 90% of the market on the table if you only support English. Yes, that's right. 90% of the

English. Yes, that's right. 90% of the market, 90% of the world does not speak English. So why are you only supporting

English. So why are you only supporting it? And maybe you are supporting other

it? And maybe you are supporting other languages. And if you are, you're almost

languages. And if you are, you're almost certainly suffering because the tools to do that right are horrible except for one, general translation, which has fundamentally changed how I think about localization. When they hit me up to

localization. When they hit me up to sponsor, I did a deep dive on the product and ended up so obsessed that I've since become an investor and adviser. I just spent a bunch of time at

adviser. I just spent a bunch of time at their office, they actually gave me a monitor, funny enough, because I just I love what they're building. This would

have saved me so much time at Twitch, it's hard to put into words. I think

you'll understand once I show you a bit of the code because general translation is built for developers. In the React version, pretty much everything is a component. You wrap your app with the GT

component. You wrap your app with the GT provider. And now whenever you're in a

provider. And now whenever you're in a given component that needs a translation, you just wrap the text area with the T component and you're done.

Wait, what if you need a variable though? What if something's dynamic and

though? What if something's dynamic and you don't want that translated? Well,

they have a component for that, too. You

wrap the user.name here with ver and you're done. But not everything fits in

you're done. But not everything fits in JSX so simply. Like what if you need to pass a prop to something that is a translated string? Obviously, they have

translated string? Obviously, they have that handled too using their hook, the GT hook. You can pass placeholder

GT hook. You can pass placeholder wrapped text and you're good to go.

They've handled everything from branching to plurality to shared strings, dynamic content, and so much more. And I'm telling you from

more. And I'm telling you from experience, building this stuff yourself is hellish. But more importantly, having

is hellish. But more importantly, having a service that supports every language is a miracle. The amount of users you're losing because your site doesn't work in their language is insane. And now you can set everything up with just one

click. They built their own agent that

click. They built their own agent that can run on app router or Mint lefi to do the translation for your whole project for you. They even have an automerge

for you. They even have an automerge setup where if somebody merges code that isn't translated properly, it will make the adjustments, add the components, generate the translations, and get that merged in and deployed for you. The more

I read about these guys, the more I want to add it to every single one of my apps. Stop losing 90% of your users, and

apps. Stop losing 90% of your users, and translate your app at sidv.link/gt.

Where better than to start than the getting started section. Hop over to my terminal. Setting up Vit Plus. Do I want

terminal. Setting up Vit Plus. Do I want Vit Plus to manage my node versions?

Interesting. So they have an NVM FNM style thing here as well. Wait, that

means this might be great for having in like a Docker image or an agentic environment where everything is managed by this. Hm. It's corpac plusni because

by this. Hm. It's corpac plusni because it can be used for installs and everything. Very interesting. Do I do

everything. Very interesting. Do I do this chat? Do I let V take over my node

this chat? Do I let V take over my node management? Chat's all saying yes, I

management? Chat's all saying yes, I have to do it. You can enable it later if I want. I'm going to enable it now and hopefully I don't regret it. Here we

are. Let's do a new app. V plus monorreo app or library. I like the idea that the starting point supports all of these.

Very promising. Going to start with something stupid. We'll just make a

something stupid. We'll just make a game. The models are okay at this now,

game. The models are okay at this now, so it should be fun. Um, what do we want to make the game? Universal package

manager. I'm thinking universal paperclipip, but as a person who maintains a big open source project, which package manager would I like to use? I thought it was a package manager.

use? I thought it was a package manager.

I am surprised to not see bun in here, but I get it. PNPM is recommended. Makes

a ton of sense. Which agents are you using? Ooh, I like this a lot. You can

using? Ooh, I like this a lot. You can

select which agents you're using and make sure you have the right MD files for it. I would recommend, and I know

for it. I would recommend, and I know they never will, for various like political allegiance things, not literal political allegiance, but business allegiance with Versel versus

Cloudflare. Skillsh is really cool as a

Cloudflare. Skillsh is really cool as a way to install skills in a reusable way that will sim link the skills across the different folder paths that are expected. Thankfully, agents MD is

expected. Thankfully, agents MD is quickly becoming a standard only claude ignores it. I will add Claude in here.

ignores it. I will add Claude in here.

Don't really need to add a cursor rule.

If it has the agent MD, it should be fine. Also, open code and AMP and others

fine. Also, open code and AMP and others all use the same agents MD. I think

co-pilot should support as well. This

will also be fun to read those agent MDs and see what they're doing. We can also add the VSS code so it will handle like editor plugins and whatnot. Set up

pre-commit hooks to run formatting, linting, and type checks with autofixes.

I used to hate pre-commit hooks, but I'm coming around to them in an AI world. I

was told by the team I should try the VP check and VPN commands, and I'm very down to do exactly that. VP check. Okay,

that's pretty absurdly fast. It did find formatting issues, but it just ran across my entire codebase in 332 milliseconds. It's not like the biggest

milliseconds. It's not like the biggest code base to be fair, but like it's still 15,000 lines of code. Let's see

how much of it can fix. Okay, it did manage to fix a lot of them there. Uh,

now the pre-commit hook is failing. You

know what we'll do? Fix all the lint errors that come up with VP check. I

also want to try the env command. What

can we do here? We can set it up. Let's

try that. Okay. In order to use the venv stuff where it controls your node version, you have to manually add it to the zish rc. So, have it work in things like VS Code and cursor. You also have to add it to your profile. a little

annoying that they don't have like a command I can run that lets me do this like vpenv setup should say hey we have to do these things hit y to do this first step it will edit this it should

be set up already uh vpenv doctor okay apparently the doctor command will do it should be first in path demanding to be the first thing in my path is a bit bold like I have a lot of [ __ ] in my path

you're not that special guys come on what does the pin command do this affect the project or does this affect my computer okay it creates node version in the project and pins it to the latest

thing. Okay, that's what I wanted it to

thing. Okay, that's what I wanted it to do. That's good stuff. That means it's

do. That's good stuff. That means it's much easier to have different node versions across different things on your computer.

Oh, that I actually really like. That

makes this much more compelling. Like

the the hell of managing like F&M and all these other things and having it work for other people on my team that use different things. Gh, this is great.

This is good. I was skeptical of V+ managing my node versions, but they do this right. This is good. One of the

this right. This is good. One of the better things I've seen so far. And the

lint being so fast is really cool as well. I'm happy I was told to like go

well. I'm happy I was told to like go try that quick. It is actually insane how good the GPT 5.4 model is in codeex for these types of things that I can just tell it to go do the thing and it

will figure it out. And now all of the linting is handled. The fact that it takes under half a second across everything here is insane. The

formatting took 341 milliseconds. The

linting took 247 milliseconds. That's

absurdity. Like genuinely. Okay, the bun run lint command is similarly fast for me. It took.19

me. It took.19

seconds of user time. So not that big a difference, especially considering that we're using ESLint before. Yeah, I

really want to try this out on a project like T3 Code, but making that migration there is going to be significantly harder than it is on a project like this. Yeah, I'm happy. This is good.

this. Yeah, I'm happy. This is good.

This is good stuff. I see where they're going here. Let's take a look at this

going here. Let's take a look at this initial start. I'm actually quite

initial start. I'm actually quite curious. First, we'll look where we

curious. First, we'll look where we always should start. Package JSON

version zero type. Cool. Dev commands.

VP dev build TSC and VP build VP preview VP config. It does have V+ as a dev. So,

VP config. It does have V+ as a dev. So,

it should be able to resolve VP in all of these. I was wondering how this would

of these. I was wondering how this would work for somebody on my team who isn't yet using V+. That seems to handle it fine. They can still just PNPM rundev

fine. They can still just PNPM rundev and it should work. But, uh, if they pmpp install, this should be fine, too, because it is just pmppm under the hood.

Nothing too sus yet. Let's hop into the source and see what we have. Okay, not

using a framework. It didn't actually ask during setup if I want to use React or anything like that, which was surprising. I expected them to to ask me

surprising. I expected them to to ask me if I wanted to use any of the many many templates they have for building with any framework in Vit. They didn't. I am

sure there is some solution for that somewhere, but yeah, not what I'm here for yet. The main ts file just renders

for yet. The main ts file just renders in the hash app like ided element in the page this content and also binds random things for the ticker and whatnot. Does

it have any JavaScript in here that triggers? No. Pretty boring stuff. The

triggers? No. Pretty boring stuff. The

counter is where we handle that logic.

All vanilla.js as we saw here. No

dependencies only devs. So nothing is being bundled in your output by default.

And speaking of things included by default, got to check out the agents MD V plus start. Interesting. It starts

with a tople title tag. This is where I'm going to start having hot takes. I

find that a lot of templates and projects and scaffolds are still treating the agent MD files almost like a readme. More so like a readme for the

a readme. More so like a readme for the team that built it, not for actually building with their tools. Ideally, V+

would only need two or three lines in here and then it would point to docs or other resources if the agent needs more context. I shouldn't need to start with

context. I shouldn't need to start with all of this information, especially this early in and it should not be a top level title like this. Like this is the

document that's supposed to be used for all of the things that I do in this project with AI. This is too V+ specific. If I saw somebody try to

specific. If I saw somebody try to commit this agent MD in one of my projects, I would probably yell at them just like straight up. There's no reason that the agent needs to know the create

command in a project that I've already created. I hate to be so critical here,

created. I hate to be so critical here, but like a lot of the value of something like V+ is how well it can streamline a lot of the like agentic DX having everything integrated in one place. This

is not it. This is so far from how working with agents is supposed to work.

There is no reason that my agent in an already admitted project needs to know the create command or the migrate command, much less all of the other random stuff in here. Like, it does not need to know about the task cache.

That's not a problem that my agents need to care about. I know there's some void zero people in chat. Please tell me this is just some random AI generated slop and not something you actually put work into cuz this is this is really bad.

Like I'm just deleting both of these files. They are hurting more than

files. They are hurting more than helping. First feedback. If you are

helping. First feedback. If you are using this yourself, do not answer the which agents are you using question because those files are actual garbage and it'll make the model perform worse.

Confirmed from our friends over at void zero. Still alpha. They're not done

zero. Still alpha. They're not done tweaking that yet. Good. It needs to be trimmed to hell. And it should probably be a skill. Yeah. Or at the very least tucked away in some docs file that gives

more info like doc/v plus context and just tell the model that that exists rather than the agents MD being so clogged with garbage. Apparently, there

are other templates that could have been used that don't come up initially when you use the vcreate command. That's a

little annoying to learn about. Now,

this is a shorthand set for popular templates including tan stack start, next app, nux, react router, view, standard vit. Interesting, they don't

standard vit. Interesting, they don't have a like more vanilla reacty one like this. is so interesting where it's like

this. is so interesting where it's like in between where Vit was where like the defaults were very vanillay and as minimal as possible and something like create next app or tanex start that

includes a lot more vit plus definitely skews in that direction of more like the lack of a vanilla react option here is a choice and it's probably a good choice I am not going to do that though because I

want to use everything as vanilla e as possible let's try actually running it vp dev now I have the local host starting point and a counter that works.

You know what? I'll bring back this and I'll do what I wanted using V+. Check

out the V+ docs for more info on how to use it. Cool. There we go. This is a

use it. Cool. There we go. This is a slightly better agent MD. We'll start

with this. Well, I will add this on Git.

Cool. Let's make it a game. Hop into the best AI coding app ever built. We got

universal package maintainer here. We

can now drag and drop reorder. [ __ ] yeah. I want to start building this

yeah. I want to start building this game. Let's make a plan for a first

game. Let's make a plan for a first version. Plan mode. Do I want to save

version. Plan mode. Do I want to save vanilla? Switch to react or plan for

vanilla? Switch to react or plan for back end. Definitely switching to react.

back end. Definitely switching to react.

Save local state. Cool. All submitted.

While this is running, I want to try the other things they added. Specifically, I

want to try the VP migrate command.

Let's find something that is migratable.

How about lawn? Let's see how this goes.

Fire like use is currently using bun.

So, I guess we'll move it to PNPM. Set

up pre-commit hooks to run formatting, linting, and typeing. Sure. As agent

instructions. Ooh,

we're skipping those. We're definitely

skipping those. ES code. ESLint Oxlint.

Oh, first fail. Unsupported package

manager bun. I told you I want to use PNPM. Just switch. Ah, I get that you

PNPM. Just switch. Ah, I get that you don't want to support bun, but a lot of us are on bleeding edge stuff. Like, if

you're using V+, you are a bleeding edge dev. The people who are going to first

dev. The people who are going to first be trying V plus are the same people who have been trying and using bun for a while now. You got to support us here.

while now. You got to support us here.

Like at least let us move out. That's a

pretty big miss in my opinion. And now I have to spin up quad code to make this project V+ friendly. Move from bun to PNPM. Look at our plan for the game as

PNPM. Look at our plan for the game as we're waiting for all that. This looks

good. It's a pretty [ __ ] big plan.

YOLO. Oh, the model never passed the plan via the plan tool. That's annoying.

That means the sidebar will never show anything. The amount of random quirks we

anything. The amount of random quirks we have to fight with these models and harnesses every day with something like T3 code is annoying. Everybody's asking

why they don't support bun. My

assumption is because bun is a moving target and isn't it's not in Typescript.

It's probably not as easy to manage, but I'm not the creator of V+. I don't know.

If Alex is still here and has information on why they're not supporting bun, I would love for him to include it. The fact that it's not node

include it. The fact that it's not node based and it's not just a package manager is my assumption for why they don't include it. It's also kind of a competitor. These are two different

competitor. These are two different paths to one unified tool for everything. I just I'm imagining there's

everything. I just I'm imagining there's enough conflict between the two.

Apparently, it's planned.

It's not there now. But yeah, let's try the migration command again. Migrate.

Yes. Skip. And we've now migrated. Oh,

the Oxent type checker does not support base URLs. That is annoying. Apparently,

base URLs. That is annoying. Apparently,

there's a tool to remove it. Okay, ready

for the most annoying complaint ever?

This is really petty. Okay, here's a certy keyboard. I use a certy keyboard.

certy keyboard. I use a certy keyboard.

Most of you use a certy keyboard. If

you're on one of those weird European ones, I'm sorry. Cordy for life. When I

have to type in npm install, I do npm space I. I am going to hold up my left

space I. I am going to hold up my left hand here and with my right hand, npm space I one-handed. If I had to do PNPM, same deal. PNPM space I. If I have to do

same deal. PNPM space I. If I have to do bun, it's a bit more of a reach, but bun with the B is still hitable with my finger, the pointy finger of my right

hand. The V is too far. This seems

hand. The V is too far. This seems

stupid and trivial and silly, but this is the first package manager I've had to use where I feel like I have to two-hand it except for yarn, but I was not typing yarn a whole lot. Yeah, VPI is um a little bit more annoying to type. Even

though it's fewer keys, I have to use my other hand. Just a a silly thing I

other hand. Just a a silly thing I noticed. Felt like it was worth calling

noticed. Felt like it was worth calling out. It's dumb, but like these

out. It's dumb, but like these ergonomics are silly. Huh, that's not great. Some store function I was using

great. Some store function I was using broke as a result of this migration. BP

install. That is really not great. Uh,

get status get broken swamp out main.

Oh, I hate pre-commit hooks. Let's make

sure this still works. Yeah, it still works on the main. So, something in that migration broke. [ __ ] that's annoying.

migration broke. [ __ ] that's annoying.

There's a very minimal app. I also

noticed that my dev command got broken by this too. This dev commands a bit custom. I have concurrently where I run

custom. I have concurrently where I run the web and convex commands with different colors. Vde dev- 5296 and I

different colors. Vde dev- 5296 and I run the bun command. This is my dev command. But when I ran the migration

command. But when I ran the migration interesting, it didn't change. VPI and

then VPDEV. Interesting. It looks like it hijacked my customdev command and didn't use it. So now that I did the vpde dev command, it did its own dev

command instead. Is that correct? Oh, I

command instead. Is that correct? Oh, I

have to vp rundev. I don't mean to be rude to my friends at V+. You do know this is the single biggest complaint we

have about bun, right? You do know the fact that when you run bun test that it doesn't use the test script we have here has like led to us almost moving off of

bun for T3 code. Right? The thing we put in scripts should always take precedent 100% of the time. I know this sounds like a petty hill to die on. This needs

to be fixed before you're out of alpha.

Hard stop. If there is a dev command in the script, the dev command should be used. There is no good reason to have a

used. There is no good reason to have a customdev command that takes precedence over the one that I wrote. Bun build is the same deal. Yes, bun build and bun run build can be different. Bun test and

bun run test can be different and that is a very bad thing. Do not carry over the biggest annoyance of bun in your design here. This is bad. This is not

design here. This is bad. This is not one of those like agree to disagree opinion things. This is just bad. Is it

opinion things. This is just bad. Is it

always run? You always have to put run to run one of the scripts. So they're

not doing the shorthand like bun as bundev that is just shorthand for bun rundev. This doesn't have any shorthands

rundev. This doesn't have any shorthands at all for things that are included in scripts. You have to do vp run script

scripts. You have to do vp run script name that okay I get it. But don't give us these built-in commands that are overlapping with the ones that we

already have. At the very least, this

already have. At the very least, this should immediately give you a are you sure you don't want to use the dev command that you already have in your like script tags. At the very least, this is not good UX, especially as a lot

of people again are going to be moving off of bun for this. This is confusing.

BP rundev should behave better here. Oh,

great. V command not found. Wonderful. I

was hoping it would migrate that too. I

have to do vpdev port 5296 for that.

That's annoying. Okay, now now we're getting into like hellish orchestration like you need to know what you're doing world hell. I need this dev command to

world hell. I need this dev command to run the webdev dev server as well as the convex backend dev server at the same time. I just use concurrently. It's a

time. I just use concurrently. It's a

really simple way to do two things at once. The vde dev doesn't work anymore

once. The vde dev doesn't work anymore cuz we no longer depend on v. V's no

longer a package. So the vp rundev command has to call vpdev. that I hate that VP rundev is going to trigger vpdev

and like npx convex dev. This is

not loving that. And we're still getting errors from use store atom.get is not a function. Let's just ask an agent. We'll

function. Let's just ask an agent. We'll

let that do its thing. And while that is trying to fix itself because I just spun up a cloud code in the background to try and fix things. Somebody said I'm missing the run in the script. No,

because if I do vp rundev, it's going to recursively call this command forever.

So I have to use vp rundev to trigger the script dev command. So I can trigger vpdev the non-script command, the vit dev server command, which is different from v rundev or sorry vpr rundev. This

is the problem. This as an all-in-one solution, it's now like clobbering its own namespace and it's getting way less clear what I actually need to run. Well,

with that all going, our game apparently is done. Let's give it a shot. VPD dev

is done. Let's give it a shot. VPD dev

left behind.js. Our new package maintainer on call package published readme currently describes ambition more than behavior. Okay, this is a really

than behavior. Okay, this is a really awful page it started with, but we can work. Publish patch and we can keep

work. Publish patch and we can keep publishing patches. Just hammering the

publishing patches. Just hammering the button. You can buy a readme glow up

button. You can buy a readme glow up using your downloads. Can add CI badges.

Shameless launch thread. Post a dramatic founder story thread about semicolon liberation.

Okay, here's what we're going to do.

We're going to do what I always do. When

I have an app that works and the UI is garbage, I open up a cloud code instance. Soon I'll be able to open this

instance. Soon I'll be able to open this cloud code instance in T3 Code, barring anthropic causing us more problems. And then you won't even have to use another terminal tab for this. This UI is garbage. Cool. Let that do its thing.

garbage. Cool. Let that do its thing.

Interesting. Okay. Apparently, there

were stale directories. It did not properly clean out the old node modules when I did the migration. That's Claude

Code's fault as much as anything else.

We'll try VP rundev again. Okay, it

looks like there's something actually wrong. Like something's actually just

wrong. Like something's actually just broken with this setup with Tanstack. I

don't know if it's Tanstack query or Tanstack start, but uh yeah, the latest Vit and Vit Plus is not working with this project. What previous VIT version

this project. What previous VIT version were we using? Uh it was using Vit 717, but they have a TANS stack start

template. So, I'm a little confused why

template. So, I'm a little confused why it wouldn't work other than like my Tanstack depths being out of date. It

does not look like it actually updated all the Tanstack packages. This is

another instance of cloud code being [ __ ] garbage. It's 50% things that V+ is doing different that my tooling and in my repos just aren't ready for yet.

50% cloud code being actually [ __ ] useless. This is what I get for trying

useless. This is what I get for trying it for anything other than like quick UI changes. Let's grab the same error. I'm

changes. Let's grab the same error. I'm

going to give like the exact same prompt to T3 code with codeex just to make a point. I just migrated this project to

point. I just migrated this project to V+ and now I get errors. Please fix

them. Probably need to upgrade the tan stack packages. And isn't it nice being

stack packages. And isn't it nice being able to like look at the image in a real UI with like a real chat experience?

Every time I use one of the CLIs for code stuff, I regret it. And as soon as I go back to the UI, I'm like, "Oh, this is how it's supposed to be." Like

actually having a UI where you can select text properly, copy things, look at images, switch between things without memorizing 1500 [ __ ] hotkeys. It's

just so much better. I am saying this all as a terminal person, too. Oh, look

at that. I found the likely root cause.

The workspace has fixed Tanstack versions installed at once. So, this is probably the bun to PNPM change that broke things. And it's finding way more

broke things. And it's finding way more things that are broken and fixing them.

Look at that. And look, this is like actually useful context. I'm comparing

the user's in progress dependency edits with the current install state before I touch anything. If node modules is just

touch anything. If node modules is just stale, a clean reinstall plus version pinning is safer than layering more mismatched upgrades on top. The runtime

stack now makes sense. Use store is being handled on router store without aget method which only happens when tans router builds a server style store on the client that points to an incompatible tanstack package set around

the is server start integration, not your route code. Look at that better model. Look, it found other CSS things

model. Look, it found other CSS things it has to fix too for build. Good [ __ ] BP rundev. Look at that. Codeex fixed

BP rundev. Look at that. Codeex fixed

it. Thank you, Codeex and T3 code. gonna

keep going to clean up other things it perceived as wrong. But we did it.

Reddit just ended up being package version changes. As always, these things

version changes. As always, these things aren't as simple as just running a CLI command. Unless the CLI command is

command. Unless the CLI command is codeex, then it probably would have been that simple. But like actually though,

that simple. But like actually though, pretty significant migration to change out from V 7 to V 8 plus swapping all of our linting, all of our typeeing, all of

our formatting and everything over to be ox based, rust based, and V+based.

It's cool. But the real test is how does this affect build times? And for

reference, this is a project that is currently using Tanstack start with V7.

Takes about 28 seconds to build. It is a relatively small app. I would not expect to see a meaningful improvement.

Hopefully, it's not a regression, though. We shaved a second off, boys.

though. We shaved a second off, boys.

All of this work, we've rewritten the entire ecosystem in Rust, and now we're 1 second faster. This is obviously sarcasm. This is totally fine. This is

sarcasm. This is totally fine. This is

an app that builds fast already and it builds fast as well. It is what it is.

It is also using PNPM instead of bun, which means the install command is going to be slightly slower. So, there is that to account for as well. But that does not mean this whole thing was slow. It's

still lightning fast and I wish I had a bigger V app to test with. Worked fine

here though. So, yeah, the cloud code run has been going for over 15 minutes and it has not changed any code yet. It

loaded the front end skill and now it's just sitting here thinking it might eventually do something. This part is interesting on VIT. I hadn't seen this.

V Tasks, a powerful new open source project shipping as part of Vit Plus provides the core task runner for V+'s built-in commands as well as package JSON scripts via VP run. Vit task

orchestrates tasks across workspace packages with automated input tracking so it can fingerprint dependency aware execution. So tasks run in the correct

execution. So tasks run in the correct order based on your package. JSON

dependency graph and explicit depends on declarations. Multi-command scripts like

declarations. Multi-command scripts like TSC and VP build are split into subtasks and cached independently. That's huge.

This really is going for like the turbo pack alternative with all of this. And

then a familiar CLI. VP run mirrors the interface of PNPM run including monor repo support reducing the number of new concepts you need to learn to adopt V+.

Yeah, you know how I feel about all that. So here's an example of generating

that. So here's an example of generating icons which you might want to cache the outputs of instead of regenerating it.

So now in your VP run generate col icons generates icons in the first run and skipped entirely if nothing changed on subsequent runs. You edit a source file

subsequent runs. You edit a source file or the specified icon theme environment variable changes, the task will rerun.

That is cool. I like this. And I like that there's a d- cache like simple call here to just cache the result. That's

great. This is still going. Now that we have the pnpm cache, it'll be fun to see if our build times are any better. Oh

yeah, that is actually better. Down to

22 seconds. That's a meaningful shave from 30-ish to 20-ish. Good stuff. Nice.

And I'm sure a lot of my time is being lost to the deployment process for Convex. Not that it's like a lot of

Convex. Not that it's like a lot of time. It's still just seconds, but like

time. It's still just seconds, but like that's fast as [ __ ] I have put so much effort into trimming build times in my apps. It's actually one of the reasons

apps. It's actually one of the reasons I've been so happy to be using less of Nex.js type stuff because even with Turbo Pack, the build times are still garbage. So getting down to 22 seconds

garbage. So getting down to 22 seconds on a a real build here for an app that actually has users and customers is pretty [ __ ] cool. I won't lie, that is dope.

Cloud Code finally finished updating the game. Don't necessarily love where it

game. Don't necessarily love where it went with it. incident. Hacker News

found your package and immediately invented a use case that you never promised. Good [ __ ] There's some funny

promised. Good [ __ ] There's some funny ideas in here. Also, it's silly, but this stupid [ __ ] online thing I see isn't every like GBT 5based UI and half of the clawed ones, too. So dumb. Yeah,

everybody's saying this looks sloppy.

You're all right. It definitely does. I

do love the promise here. a future where we no longer have to juggle node version managers, package managers, a multitude of individual tools, their config files, or all of the hell managing upgrades for

all of them. I see where this is going, and I am genuinely excited for us to get there. The fact that I could change all

there. The fact that I could change all these commands to just use vpdev instead of vit or pnpm or any of like 15 other options is promising. The fact that I could gut all of my weird linting and

type checking stuff and move as much of it over to VP commands as I could is exciting. VPLint being able to just lint

exciting. VPLint being able to just lint files is dope. There's a future where a lot of that decision fatigue that we're all feeling nowadays can be reduced down meaningfully. And generally speaking,

meaningfully. And generally speaking, the more streamlined and centralized and simple solutions we have for the problems that we build solutions around, the better. But you combine this with

the better. But you combine this with the other thing that the void team is working on, which is a better way to deploy your V apps across the web as full stack applications. I see where

they're going. This is a very exciting

they're going. This is a very exciting future where everything you need from your database to your package management to your CSS to your runtime in the cloud can all be provided with one solution.

And if anyone is going to be able to figure all of this out, it is going to be Evanu and his team as well. Of

course, even if Void is currently built heavily on top of Cloudflare and Vit Plus is built heavily on top of VIT, I mean, of course it is. It's Vit Plus.

There is a direction here that is exciting and I am actually very excited about it. There's a lot of little things

about it. There's a lot of little things that could be better here. There's a lot of random edge cases I hit throughout this and I expect the team to do what they always do, embrace the opportunity to make things better. I've been working

with VIT forever now. I use it for so much stuff. I was one of the first

much stuff. I was one of the first people to use Vit with React. I was so early they put me in the documentary for it. I'm excited. I see the potential. I

it. I'm excited. I see the potential. I

am not feeling it yet, though. That's

the difference. I see what this could be. I'm excited about what this could

be. I'm excited about what this could be, but I personally don't see myself using it for a whole lot just yet.

Thankfully, it's open source and there's a ton of promise in where they're going with it. I'll be sure to keep an eye on

with it. I'll be sure to keep an eye on it, as I'm sure most of y'all will as well, but for now, not necessarily the thing I'm going to start using for all my projects. Just a thing I'm very

my projects. Just a thing I'm very excited for the future of. Curious how

y'all feel. Are you hyped on V+ or is this something you're going to skip for now? Let me know how you'll feel. And

now? Let me know how you'll feel. And

until next time, peace nerds.