Vite’s bet on Cloudflare (VOID Framework)

Welcome to Syntax. Today we've got myself, CJ, and Scott on the horn. We're talking about VIT's second announcement. We had an earlier episode, we talked about V+, their open- source tool. Another thing that they recently announced, this thing called Void, which is both a deployment platform as well as a VIT plugin that will handle all of your bindings and whatnot. Basically, I I said this and a lot of people got mad, but I said I said that this was like a Laravel or Rails for JavaScript, which is about 87% true obviously, but it got got a lot of people mad. Is this CJ? Is this a Rails for JavaScript? It's like 60% true cuz like one of the things that that uh Rails or Laravel gives us is uh a full OM and like more opinions about where stuff should go. This basically gives you access to all the stuff that Cloudflare makes available like a database and a queue and all these other things that you typically need in an app and then exposes them to be really easy to use. Uh but I guess we'll talk about it. It it does they are giving you an ORM though and they are they are giving you opinions as to where things should go. But but in Rails West it it's like you're you're basically defining like the schema and it's giving you a lot more. Yeah. Very much more structured. I get that. the Adonisjs people had my neck for that. I should not have said that, but we'll talk about it once we get into the database layer because I have ideas about this stuff and I think my ideas are more Rails and Laravelesque than what Void has done. Not to say that this stuff isn't cool, yes. So, what the heck is this? So, the folks behind VIT, it's a company called Void Zero, have come out with a full stack JavaScript framework called Void. It exposes itself via a Vit plugin and it is heavily tied or bound to the the Cloudflare environment and it it gives you a whole bunch of stuff like kind of just set up right away, right? Gives you server actions and and whatnot and it gives you a database, a key value, authentication, better off, you know, like kind of all the stuff that you would want if you're building out an application. and we're going to go kind of go through it and and talk about all the different pieces and and whether or not this is Cloudflare lockin and whether or not this is something that you should be excited for or not. Sick. Yeah, I'm excited to dive into it. Um, it's it's actually very funny because CJ and I had been both uh working on our own frameworks and the amount of things that this landed on that are very similar to mine is both simultaneously disappointing but also very exciting because now what I can do instead of releasing mine is that I can take this and build on top of it. uh or at least possibly because we'll get into some of the reasons why I might not want to do that. But it is very validating to me personally just how many of the choices they landed on that are very similar to what I landed on. Definitely. And I would say they took a lot of inspiration from spelt. We'll get into it, but like this idea of like a separate server file like loaders, actions, and one of the things off the bat is like I also consider this one of the great unifiers, right? like you can use react, view, spelt or solid but the backend layer is the same for everything. I think this is one of the things that's missing in the JS ecosystem is pick a framework and you have a separate meta framework that you have to plug into but this is one meta framework where you can choose the view layer like similar to Astro but this is more like instead of for content sites this is more like full stack apps dashboards those kinds of things. Yeah, it is really cool. So being able to use React views filter solid is really cool. There's I I don't know that you can mix and match them. I don't know that you you would want to, although I know plenty of companies who have have lots of mix and match apps out there, but the like I guess like the templating layer uh can be whatever you want, which is is really neat. You can also so like this is a framework meaning that you can it will do serverside rendering. It does caching, actions, forms, validation, um, tiptotail. It does does absolutely everything for you, but it it apparently will also work with spelt kit, tan stack start, nux, you know, all of those um, things that you may be using. I I think there's probably some caveats as to how much of the stuff works if you bring your own framework, but that's that's sort of the idea here. Yeah, the way I think about it is like it like void is a framework, but it's also a deployment platform. And if you don't want to use the framework, but you want to use the deployment platform, that plugin will allow you to plug it into spelt kit or interesting. Okay. Yeah. Now, now where have we heard of of this type of deployment platform before? Versel. Yes. This is there I I think they're essentially trying to make the versel for for Cloudflare um here, which is like as as much as people say like I I don't like forell or whatever. It's very obvious to a company making money that they are they're by far the best DX for this type of thing. Um and they are doing extremely well, right? Like like lots and lots of people host host on on Versell and it is is a fantastic hosting platform. The the the reasons why people don't like it is because it's expensive, right? But it you can't you can't uh argue against it being a fantastic platform and and they're probably looking at this being like yeah um we should make that for Cloudflare. Yeah. Yeah. Right. Yeah. You know what I do? It is funny because Verscell has like resisted the VIT train for so long even though like you know the even at the detriment of their own projects. Um they've also resisted anything that's not I mean it's not like they've resisted speltkit because they they fund the development of speltkit but like the next platform and the speltkit platform and all these things are are so separate and then uh some of them use v next is like really like we are going to own this whole thing without using anyone else's tools again like to the detriment of the project. And so it feels different for me and I'll tell you why it feels different. It feels different only because this is the stuff I already pick anyways. It's like what if we made a service that like just works with all the stuff you're already using. And I'm like, oh yeah, that's great. And they're like, oh, but that's that's kind of like against the things you you don't like, which is like the Versel next.js style approach. But it's like, well, it's the stuff I like, so therefore it's fine. You know, not Yeah. I don't know how to I don't know how to like part of it. Yeah. So, right. Yeah. I've waffled on this cuz like so for the framework that I'm building I want to support self-hosting. I want to support any deployment platform. So I'm thinking about it even like higher level abstraction of like give you a DB but you could use Cloudflare D1 or you could use uh superbase Postgress or something like that. Whereas this is if you want a DB you're using Cloudflare D1 or if you want um it it also uses like let's talk about that. Um, so it has an OM baked in which is Drizzle and then if you want a database you either have to use SQLite via D1 or it also supports Postgress via Hyperdrive which hyperdrive is Scott you use hyperdrive. Can you explain what that is real quick? No, I use it and I cannot explain it. My understanding is it's like it's a my understanding is that it's like uh it allows for connection pooling of databases. is it's like a layer that sits in between your actual database and your app for serverless applications because uh if you don't then the there's something with the connection I all I know is that I have to use it and it's a necessary evil something that I I do not like using yeah like Cloudflare doesn't have sockets um and if you want to connect to a database you are generally using like like sockets right and so Cloudflare has this product called hyperdrive which will also part of the reason that they have it is like if your database it's not living anywhere close to where your your code is running that that can introduce a lot of latency. So part of what their pitch for that is that like they've got a fat orange pipe from like where your database lives like in like like where where do we host our our our MySQL database? Planet Scale. Planet Scale, you know, if you want to connect like Planet Scale straight to they got a fat pipe from Planet Scales office to the Cloudflare office piping the Yeah. the database between the two fat pipe. Yeah. I I wonder thing I think about this is the local data story because it is so tight. Everything is so tightly integrated. It's like but what about my local data? Do I now have to like step outside uh this? What tools do I like to use that would work well with this? Um, it doesn't seem like zero sync would work super well with this because it takes over so much, but yeah, I I would want to think about that quite a bit because I need I need my local data story. Yeah, there there's lots in the like Cloudflare ecosystem um that just doesn't run on on Cloudflare, right? Like Sharp is one, right? uh it's like it needs C++ bindings and and they either have a like alternative um to running that in Cloudflare or they they've recently just ran uh rolled out containers which is basically just like fine you want to run a docker image on Cloudflare like if that's the last thing that's stopping you then you can do that. Yeah. And if you want to see all of the errors in your application you'll want to check out Sentry at centry.io/sax. You don't want a production application out there that well you have no visibility into in case something is blowing up and you might not even know it. So head on over to centry.io/sax. Again we've been using this tool for a long time and it totally rules. All right let's talk about um type safety. So obviously one of the biggest things in a meta framework is endtoend type safety. Meaning that all the way from your OM database schema, you get types all the way through your route handlers, your API requests, your your page loaders, your your actions from the server into the client. And that is is beautiful. I think like the first time that I had that was probably three or four years ago with speltkit when we were building the syntax site and I was like this is absolutely beautiful. You know, you define your schema in the database. you say, "Oh, this is a page loader that loads these data pieces from the database and we pick and choose and we we map and filter and then we return that data." And then you go into the client side and you start to template that out and those types just flow all the way through and it it's absolutely beautiful. So this of course has that I think most frameworks have this type of thing um these days. Yeah. But this has a couple of extra things too. So like you and the way this they set this up is similar to Feltkit. They have a separate server file. That's where you define your loaders and then in your template file.viewview.sfelt.tsx or whatever you get access to those type loaders. But they also have an API layer that's fully typed. So this is one of the things that they borrowed from nux on the client side. If you do fetch, you actually get type completion as to your API endpoints and it does the smart thing of if that code is running during a serverside render instead of a network hop, it just calls that function directly. Um, I think there's a screenshot with uh uh the fetch request API fetch. Yeah. Right here. So, this is just a regular ass fetch request to an API endpoint, but the response from that fetch is fully typed, right? Cool. Yeah. And like in your editor like you you would get autocomplete for SL API. It knows about what all what all your routes are and like I said, no network hop. like it looks like maybe your server would be requesting your itself, but it's smart enough to know where the code is running and actually just call the function directly. This is one of the thing that really bugs me about Nex.js. Like there's no built-in way to do this. What about RPC here? I It is funny because we we just mentioned loaders and a you know form loaders uh page actions and stuff and I got to say I I'm so far o I'm so far over those. I I like doing that at a route level sucks to me. I I'm past that. And I'm doing everything with the spelt remote functions and async spelt and being able to just call functions and uh do the form actions in a way that's not at a route level because I my stuff my stuff doesn't like think at a route level. It thinks at a component level. They support both, right? So what we just showed was like let's say you have a separate API definition and you want to call it from a a component or a page. That works. And then they also have uh define a loader and an action and then call it directly from from the component. At least from what I saw. Yeah. Yeah. You'd be able to just like very similar to how React server components works or um like page action server actions and and Tanac start where you would just simply import that server action from yourserver.ts file and then it will just replace that with a like a network call behind the scene, right? Like if we take a look at the like the kitchen sink example that they have here, and I've I've just defaced it with some syntax listeners here, but if we were to like add something to it, I'm pretty sure in the when they've coded this, it's I don't know if it's it's using a fetch request or or like an RPC call, but it it doesn't really matter because you just hit it and it will send a network request to the back end and then come back. And on top of that it's also using the whole like idea is very much like inertiajs inspired which is like very much server centric. Your server will compute your state lives on the on the server. Um the props come from the server and simply just will will populate and that's very popular in like non-JavaScript land right like Laravel is huge. Inertiajs is really big in Rails land. This this idea is really popular as well. Yeah. And and Scott, can can we dig in a bit more to what you were talking about for like pages? You don't like the request being tied to pages? Like are you leaning more towards like I'm going to define my API layer separate and then just call it from whenever pages need it? Is that more of what you're talking about versus trying to define them side by side? The way I I tend to work here is I'm defining my API as basically functions. um if I need endpoints then the I have separate endpoints that then just call those functions but in this feltkit way of doing things you're creating just a query or a command or whatever and then you're essentially just importing that into your client side code and calling it um RPC and and at a component level it's way nicer because you you you're often times duplicating a lot of code from loader to loader. If you have a component that lives on one page and a component that lives on the other page, they have the exact same data. Now I have duplicate code or I'm creating an abstraction that I'm importing into both of those layers. It it just gives like I and then what you're doing is that that information comes in at a a loader level, a route level, and you you hot potato that data all the way down into whatever component you need. And now all of a sudden like in a React context now that those props exist and are you know going all the way down the tree rather than uh this component has these props this specific data and it's tied to that component. This is my one of my hugest qualms with all of these frameworks. Um and like for my my example I'm on my my website right now. I fetch in the footer of every single page. I fetch syntax podcast and I fetch my latest tweets and I put them into the footer of that. And the logic for fetching both of those things does should not have to live at a page level. Correct? Right. Like I shouldn't have to think, oh, what page am I on? What pieces of data may I need for this? I the the loader for that data should live in the component for the podcast or the component for the tweet. React suspense makes that very easy. meaning that like it knows when it there is a child that is fetching data and it knows if and how long it should wait for it and and if not like oh it's taking too long I can send the rest of it and then stream that in at a later point. I absolutely love putting the logic of how to get the data in the same component of like where it's where it's being rendering or at least like I don't have to put that in it. And what I have to do in like like Tanstack land is I have to write all these like server actions and then I have to figure out what page I'm on and and then import that into the the page loader and then and then like Scott says you have to weave that data in and out and I don't like that. and React server components has that and now spelt has that with a synchronous spelt which is I absolutely love it. Yeah, I can't go back. Yeah, this is good inspiration for my framework cuz right now what I'm building has page loaders, but basically what we're talking about here is component loaders. Like a component should be able to define what data it needs and that should also tie into the overall cache and serverside rendering layer. Like even though a component is declaring a dependency on some loader data, that should still be serverside rendered. that doesn't mean it needs to be client side. So correct. That's people like we'll just just wait till it loads and then fetch the data. But like I don't want that. And the reason why a lot of these frameworks don't do that is you can very easily make a um a waterfall website where like something fetches something and then that loads another component and then oh I that component now needs to fetch something else and now you make you can make very slow websites uh that way if if you don't know how to properly use like react suspense. Yeah. and and and another thing that was really great about this felt kit implementation of this is with their like their actions what you're doing your form actions or whatever that are these RPC functions because those are all validated by a standard schema you actually can import those functions and spread them into form inputs and then your form inputs get validation in the actual JavaScript and HTML. Big fan. Yeah, big fan of that. What else is is there with it? It comes with Oth baked in um which is using Better O which I thought was pretty interesting to to include it. It seems like a lot of these tools like Drizzle and Better Off and they're they're not that old but I feel like everyone is finally like this is it. Can we stop changing them? Better off rips and it's it's it's flexible enough you can do anything with it which is one of the reasons why I like it. It's easy enough to just drop into anything. I'm a big big fan. So again, this is all the stuff I like. And I I didn't see like Evan didn't show examples of off during the demo, but I'm hoping that it also like by default gives you some pretty zero config stuff cuz like Better Off is nice, but you do have to configure things obviously. But to get like a just a basic username, password login with no config would also be really nice for just the sites you want to spin up like that. I'm I was curious about that as well. like does this just give you like O and like tokens or does it does it give you like users like a like a like a database user that you can then associate stuff and in looking at their like CLI there's void off login oh no that's probably for the cloud provider that's for the cloud provider yes yeah I I think I think that's just for logging into void um but if you take a look at the example code they have here they have import O which is powered by better o. So I'm curious if it like kind of goes one step further and gives you like a Laravel or Rails would give you if it gives you those users or not. I will say just looking at this one slide, it has what it's like dream code, right? Just import the DB and use it. Import KV and use it. Import storage and use it. Import O and use it. So that's nice. Um like we said earlier, this is tied to Cloudflare. So each one of those things has a Cloudflare black backed service that's actually managing all of that for you. Um but and and probably even further it it like does all of the like wrapping of Drizzle for you. Um which is like I look at that and I think like that's not that I have like a what a 26 line lines of code db.ts ts file myself and I simply just import the DB directly from that right and and with the Cloudflare V plugin um it doesn't need like the context to like pull the string out of it you know it can just it can pull it out of thin air from a sync local storage so a lot of these like things I look at and and having used the Cloudflare V plugin with Tanstack quite a bit I think I don't know like it these are not huge paper cuts that I I hit with this type of thing. Yeah, I think it comes down to kind of hiding the details, which is basically what Verscell does for you, right? Like if you want a Reddus database or Postgress database, like they hide the details, you pay a little bit extra and I think that's what they're trying to get at, but it might be in this case like the details aren't that bad because it's like a threeline config file versus just importing DB. So yeah, I don't know. Yeah, it it always is a delicate balance of like do I want to figure out what the wrangler commands are? Um, part of it is like the the Wrangler or the Cloudflare MCP super good. You said it sucks, Scott. No, Wrangler sucks, but the MCP the Cloudflare MC is good. Yeah, you just ask your your agent like make a database and stick it in my Wrangler.json file and and it boop do it for I haven't used some of these Verscell things in a long time, but when they first announced like the Verscell DB and the Versel KV stuff or the key value stuff they were doing, one thing I I I'm struck with is that these are all in one spot. They're all in Cloudflare where with Versell, at least when they launched it, and I don't know if this is still the case, the the key value was on Upstash. The uh Postgress was on Neon. So, like they weren't like running that all through AWS or one spot like everything else was. And I found that to be a little iffy when I was using that that tech before, but it it's been a little while since I I've tried that out. So, this is all in one mostly just bindings um similar similar to how Cloudflare works is you just add a database and then it will communicate back and forth with you. I don't know if that's an actual performance issue or not. I kind of doubt it since Versell is so performance and very likely they're all running on the same server anyway. They're all running in an AWS East one. So the big like feedback and the big like talk that everybody had when this was announced is like is this not just lockin uh to to Cloudflare? Um if it is so tightly coupled to Cloudflare it will this work on self-hosted? Can I use bun? Can I put it on a Raspberry Pi? That type of thing. And Evan came out and says, I want to be very upfront about void being tightly coupled to Cloudflare. The lockin is what makes the DX possible. If you don't want to lock in, then it's not for you and that's fine. V will forever be platform agnostic. Use it with Nitro version 3 or Adonis. The choice is yours. And Void just gives you another option. So I I quote tweeted this unapologetically Cloudflare. Um, meaning that if you want to have Nex.js Versell level of DX, you do need integration between your infrastructure and the actual code that you're writing. Um, and as much as people absolutely hate that because they want to be able to move around to all of the different platforms, it's it's interesting that he comes out and just says like, look, you can do it yourself. And like I've I've done pretty much this whole stack myself several times on on Cloudflare and it's not that bad. But if you want one step further, you're willing to pay for that. Um it will be Yeah. I I wonder a little bit about like when you are picking this stack, are you picking all of the stuff in the stack? And how does that I don't I don't think so. Like it's it's just code. Whatever code you want to run, you want you want to use a different different database as long as it can run on Cloudflare. You can bring whatever whatever you want. That's the main thing like can it run in Cloudflare workers? And if it can use whatever you want, but the thing is a lot of things can't, which is why they introduce things like D1 and and some of these other offerings because it specifically works inside of workers. Mhm. But I I thought what would be kind of a neat um exercise for the team here is like let's go through each of these choices and ask ourselves is this is this lock in you know so like if you're building on top of this thing your database SQLite or Postgress and Drizzle that's to me that's not that's not lock in right um and people say that a lot like oh why are you using this like specific cloudflare database I'm like well I'm just using I try to keep things as standard as possible and if I use drizzle I know that I could in in not every case but like I could move it to SQLite somewhere else and in many cases I could move it to MySQL somewhere else you know or Postgress yeah it'd be a little bit of a a migration because what I think about is like if you're using D1 you're using like that specific D1 binding but if you are running a deployed app that talks to a SQLite database you're probably using lib SQL or terso so I don't know a different adapter Yeah, you you can swap out the adapter. I don't know if that's going to change your table definitions, but that would be the one the one step I'll tell you because in local dev, if you want to use Drizzle Studio in local dev with a like with Cloudflare, you have two options. You use the HTTP API or you write some weird thing that finds the SQLite database on your local machine and then uses the the better SQL adapter for that. And I do that for all of my sites, meaning that I'm running different adapters in prod versus local. And I've had zero issues. I don't like doing that in though just not because there's issues, but it's just annoying. Yeah. Yeah. But I agree. Single single config swap out. It's not necessarily lock in off. Is this lock in? It's kind of one of the scarier things to get locked in on, but it I will say it doesn't seem like it's locking into you into an O platform. It's locking you into an O library, right? as far as this goes, you still get all the benefits of better off. Like you're hosting the users like there's no like user limit or anything like that. Yeah. Yeah. You're hosting it. You're not paying for O specifically. And then again, if you wanted to migrate off of this, it's as simple as just exporting those tables and then bingo bango. You're you're not like you're not having to rewrite your off. And let me tell you, there's nothing worse than uh having to change your off platform or or change the uh the algorithm or something because when I had level up tutorials, it was on Meteor and I wanted to move off of Meteor. I ended up having to write my own Meteor compatible O package to avoid having to make all the users re-update their passwords and stuff like that. Yeah. Key value. I use the Cloudflare key value quite a bit and the API is is very simple. It's get put delete or whatever it is and then there's a TTL that you can put on it very similar to like like a Reddus API. So, kind of lock in, but also if you wanted to move away from that, I'm I don't think that that would be a big lift. And I don't know if they showed it in their slides, but if they're using the unsto, which comes from unjs, it has adapters for Cloudflare, Dino KV, uh, how did I not know this? So, I don't know if they showed it in their slides or not, but if they are, then actually it's it's not lockin because unsto uses the same API. It's it it exposes all the things that you talked about but with the same methods calls and then all you have to do is swap out the adapter to choose okay I want to talk to Reddus or I want to talk to cloud cloud for KV. So we're a sponsor. How did I not know about that? I know about but just click on click on getting started and then click on drivers and you'll see they support everything. Oh, or drivers at the top if you click on click on that absolutely every KV store and you just swap out the the adapters. I use Dino KV Cloudflare KV. Oh man, this all this whole unjs ecosystem is the best, right? There's like unpicture un whatever. If you're worried about lock in, some person that writes nuxed for a living has written unjs version of whatever that is and it will come to save you. Yeah, cuz a lot of these plug into nitro as well. But yeah, I I don't know. I will say like if they're not using n storage, then yeah, it's a little bit of luck and you're going to have a little bit of migration pain. But maybe, but here's the thing, just make your own. Like, yeah, the thing about this is that you can get the Cloudflare binding directly and then if you don't want to be locked in, then just build your own take. Yeah. Write a like a six line six lines of code um where you can import and export this thing yourself. True. AI. Um, let's loop this in with like I guess like there's there's Cloudflare cron, there's Cloudflare Q's and and there's Cloudflare AI. Um, I would say that these things are fairly high on the lock in aspect. Um because if you're building on top of durable objects, there are some open source implementation of durable objects now with the same API which is great, but I would say those are pretty high in on the lock in, but a lot of people are willing to take that tradeoff for like the the DX or the the cost for this type of thing. Yeah, I will say it is lock in. But one thing I do like I I like that this is baked in. That's something I do like about Verscell, like uh being able to have crowns baked in, but like cues are something that I explicitly never take advantage of because I just don't ever set it up. It's like which is the dumbest thing to say. I' I've built I' I've worked with cues before, but like it's one of those things that like if it was there and I didn't have to do any work for it, I would use it a hell of a ton more. I I I I totally agree. I have a project. I'm I'm working on my like users.te website and I'm moving it over to Cloudflare and there's there's one thing that is like a fairly large ingestation process and it needs to wait and and all of this stuff and it's a perfect use case for for cues and and normally I would just stick that thing in like a long running endpoint which I did with our transcripts as well on the syntax site but since the cues were so easy they were just there. Um, I was like, "Oh, might as well." You know, I don't have to set up a whole thing for it. So, this is one thing that is more Rails or Laravel like because they come with systems for this. So, this will be interesting because like you're saying like if it's there and devs know that they can use it and they don't have to set anything up, we can build more complex systems that use cues in the right way instead of having like a long running endpoint. I do agree lock in because you're tying it to the specific cloudflare way of doing it. Well, like we should say as well, like people don't mind that right now because it is so cheap. But as as much as we love Cloudflare here, they are a public company that is beholden to their shareholders, you know, and the the $5 could become 50 at at some point. So hopefully not. I'm I I don't think it will, but that's why I I I also am asking these these questions as well. React Hano page routing um all of this stuff like like page routing itself um page handlers defining this stuff somewhat of a special API but the whole request response fetch um react hono this stuff is just standards web- based you know I could take a a handler from my react hono application and move it into a spelt kit handler and and do very little um work and it would just it would transfer over very well. Yeah, I will say huge points for using building this whole thing on Hono because Hono is great and um yeah, I like it. I'm big fan. Big fan as well. Um one thing we didn't is is a question and I asked this in their chat room. I said like will you a be able to self cloudflare your own void apps? meaning that like will you if you're deploying a void app, can you deploy that to only to void or can you just take this adapter and and deploy it to your own cloudflare given that you're going to have to do all the wrangler commands and whatnot yourself? And they said they don't know yet, which is kind of kind of interesting quite honestly. Like maybe you can't deploy this to your own Cloudflare account, but you have to use the the Void Cloud one. I I think if that's the case, I'd probably be be a a big no from me on on these types of things because I would want to use my own account. Um by yo, bring your own Cloudflare, I I mean I agree with you. Yeah, I I don't want to I don't want to put my stuff in another place and have to worry about DNA. Like I got all my stuff at Cloudflare already. I would love to just keep all my stuff there as well. But I will say this is what Verscell brought to AWS, right? It made it it hit all the details. you can deploy with one command. You don't have to do anything. And I don't think Versell supports like setting an AWS key or anything like that. Like they they upcharge you and that's how it goes. So I think with void it's probably going to be their business model which at the end of the day I think like right now we all know the Cloudflare stack and we're it's easy enough for us to set it up but it at a point if we start using this then we don't have to worry about that. But it does come down to like what is what's the premium right? How much more is it going to be to use void versus like doing the stuff directly on Cloudflare? Cuz personally, Cloudflare isn't that complex that it might be worth that much more of a premium, right? And Cloudflare is trying to build their own version of like Versel for Cloudflare, you know, like they're trying to make it as good as it's not there yet. Um, but they're they're trying. gets better. I think another thing to think about is like not us developers who know the Wrangler commands, but like there's this whole new swath of of like vibe coders who are building things and like man that's a tidy ass little package um that you can just boop and it it it pushes it. Yeah, I probably should have said that, but you know what I mean? Like, you know, this is a great totally batteries included and then like the the agents love Nex.js and Verscell right now because it is a tidy ass little package. So, I think so. Mhm. I have a question. Do you guys think this would be possible to use in something like an Electron situation given that you're not actually even hosting it somewhere? But let's say you wanted to take advantage of the the uh the non-cloudflary things. I don't know why you would do that, but I'm just like wondering. Cloudflare has like workerd is the javascript runtime. Like it's not noode.js. They have their own javascript runtime. And when it runs locally via something called mini flare, it will try to replicate most of those things, right? It replicates the databases, replicates as key key value, um quite a bit of it. There's some things like um browser rendering. It doesn't. Um what are what are some of the other ones that they have? The image resizing API that doesn't work locally, which is kind of a pain in the butt. Um but like yeah, would this be a thing that you could just stick the local version of that in like an Electron app and just get the whole Wrangler experience? Yeah, I don't know. I think it makes sense. Like I think what you're talking about, Scott, is like you want to use speltkit routing in an Electron app, right? So like could we use this voids page based routing in an electron app? Um that that kind of thing. Yeah. Because what I don't want to get into a situation like if I'm going to buy into this stack which uh you know I I I I've bought into spelt kit so hard that I know it inside and out and I can use it to build Electron apps or I can use it to build Tory apps or whatever. But like if I'm buying into this stack, am I now forfeiting being able to use it in other contexts like that? Yeah, maybe. Yeah. Yeah. My gut feeling is yes because it's so tied to Cloudflare and it's like their build their build output is a Cloudflare worker, right? It's not something that runs on Node.js. So probably, but I don't know. We'll see. I mean, I think that's right in dev. Yeah, that's what I was thinking is like you you just run the VIT server next to your Electron app. I've done it. Like when I did my receipt printer thing, I ran the Nex.js dev command and I had close to 2,000 people visiting it at once and the dev server handled it fine. I was like, why are we not just running dev in production? That's half a joke, but also it's kind of That's great. It's good. Yeah. So, I'm I'm wondering with this, how many things we've yet to learn about this? like what does this actually look like? I can't wait to get my hands on it. I can't wait to use it. Uh for me, everything clicks just a little bit different when I I get in into the actual code. So, I wonder how my understanding or thoughts on this will change after uh we we know more. I as well. I also don't think a lot of this is built yet. So, I have a feeling that they're just listening to what everybody is saying and getting feedback for it and then they are kind of going to be building around those thoughts. So, in the comments down below, let them know your thoughts if you would use this or not cuz I'm sure they're going to be reading it. Yeah. Feedback is priceless. Your feedback is a gift. Veback. Yes.