Welcome to Syntax Today. We've got myself, CJ, and Scott on the horn. We're talking about Vite's second announcement. We had a earlier episode. We talked about Vite plus, their open source tool.

Another thing that they recently announced JS thing called void, which is both a deployment platform as well as a Vite plug in that will handle all of your bindings and whatnot. Basically, I said this, and a lot of people got mad. But as I said I said that this Wes, like, a Laravel or Rails for JavaScript, which is about 87% true, obviously, but it got Yeah. Got a lot of people mad. Is this CJ, is this a Rails for JavaScript?

It's, like, 60% true. Because, like, one of the things that that, Rails or Laravel gives us JS, a full ORM 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.

But I guess we'll talk about it. It it does They are giving you an RM, though, and they are they are giving you opinions as to where things should go. But but in Rails Wes, 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 Adonis JS 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 Me too. My ideas are more rails and Laravel esque than what Voigt has done. Not to say that this stuff isn't cool. But

Yes. So what the heck is this? So the folks behind Vite, it's a company called Void Deno, have come out with a full stack JavaScript framework called void. It exposes itself via a Vite plug in, 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? It gives you you you server actions and and whatnot, and it gives you a database, a key value, authentication, better off, you know, like, kinda all the stuff that you would want if you're building out an application.

And we're gonna go kinda go through it and and talk about all the different pieces and and whether or not this is Cloudflare lock in and whether or not this is something that you should be excited for or not.

Sick. Yeah. I'm excited to dive into it. It's it's actually very funny because CJ and I had been both, 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. Yeah. 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 Svelte. We'll get into it, but, like, this idea of, like, a separate server file, like Node, 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, Vue, Svelte, or Solid, but the back end layer is the same for everything. I think this is one of the things that's missing in the JS ecosystem JS 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. That it Wes really cool. So being able to use React, Vue, Svelte, or 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, 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 server side rendering. It does caching, actions, forms, validation, tip to tail. It does does absolutely everything for you, but it it apparently will also work with SvelteKit, 10 stack start, Nuxt, you know, all of those,

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 wanna use the framework, but you wanna use the deployment platform, that plug in will allow you to plug it into SvelteKit or Yes. Handstand Start. Okay.

Yeah. Now now where have we heard of of this type of deployment platform before?

Vercel.

Yes. This is there is I I think they're essentially trying to make the Vercel for for CloudFlare, here, which JS, like, as as much as people say, like, I I don't like Vercel or 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, and they are doing extremely well. Right? Like like, lots and lots of people host host on on Vercel, and it is is a fantastic hosting platform. The the the reasons why people don't like it is because it is expensive. Right? But it you can't you can't, argue against it being a fantastic platform. And and they're probably looking at this being like, yeah.

We should make that for Cloudflare. Yeah. Yeah. Right. Yeah. You know what? I I do it is funny because Vercel has, like, resisted the Veat train for so long even though, like, you know, the even at the detriment of their own projects.

They've also resisted anything that's not I mean, it's not like they've resisted SvelteKit because they they fund the development of SvelteKit. But, like, the next platform and the SvelteKit platform and all these things are are so separate, and then, some of them use v. The next is, like, really, like, we are gonna own this whole thing without using anyone else's tools again, like, to the detriment of the project. Yeah. And so the 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 Yeah. 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 Vercel Next. Js style approach. But it's like, well, it's the stuff I like, so, therefore, it's fine. You know?

Yeah. Not yeah. I don't know how to I don't know how to make it out of my brain. Part of it. Yes. Right. Yeah. I've waffled on this because, like so for the framework that I'm building, I wanna support self hosting. I wanna 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 d Node, or you could use a Supabase Postgres or something like that. Whereas this JS, if you want a DB, you're using Cloudflare d one. Or if you want,

it it also uses like, let's talk about that. So it has an ORM baked in, which is Drizzle.

And then if you want a database, you either have to use SQLite via d Node, or it also supports Postgres via hyperdrive, which hyperdrive is Scott, you use hyperdrive. Can you explain what that is real quick?

Node. I use it, and I cannot explain it. My understanding is it's like it's a my understanding is that it's like, it allows for connection pooling of databases.

It's like a layer that sits in between your actual database and your app for serverless applications because, if you don't, then there's something with the connection. I I all I know is that I have to use it, and it's a necessary evil, something that I I do not be using. Yeah. Like, Cloudflare doesn't have sockets.

And if you want to connect to a database, you you Yarn generally using, like like, sockets. Right? And so Cloudflare has this product called TypeScript, 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?

PlanetScale.

PlanetScale. You know, if you wanna connect to, like, PlanetScale straight to they've got a fat pipe from PlanetScale's

office to the CloudFlare office, pnpm in the Yeah. In the database between the two. Tap pipe. Yeah. I I wonder one 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, this what tools do I like to use that would work well with this? It doesn't seem like Deno sync would work super well with this because it takes over so much. But, yeah, I I would wanna 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, that just doesn't run on on Cloudflare. Right? Like, Warp is one. Right? It's like it needs c plus plus bindings. And and they either have a, like, alternative, to running that in Cloudflare, or they they recently just Sanity, rolled out containers, which is basically just like, fine. You wanna 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 sentry.io/syntax.

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 century.io/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

Let's talk about, type safety. So, obviously, one of the biggest things in a meta framework is end to end type Sanity, meaning that all the way from your ORM 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 ESLint, and that is is beautiful. I think, like, the first time that I had that was probably three or four years ago with SvelteKit 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. Then you go into the client Node, 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 I think most frameworks have this type of thing,

these days. Yeah. But the and this has a couple of extra things too. So, like, you you and the way this they set this up is similar to SvelteKit. You have a separate dot server file. That's where you define your loaders. And then in your template file Scott vue dot svelte dot t s x 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 Nuxt.

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 server side render, instead of a network hop, it just calls that function directly.

I think there's a screenshot with

the The fetch request. Wes 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 timed. Right? Cool. Yep. Yeah. And,

like, in your editor, like, you you would get autocomplete for slash API slash AI.

It Node about what all your 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 Next. Js. Like, there's no built in way to do this.

What about RPC here? I it is funny because we just mentioned loaders and, you know, form loaders, page actions and stuff. And I gotta 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 Svelte remote functions and async Svelte and being able to just call functions and, 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 wanna call it from a a component or a page. That works. Mhmm. And then they also have,

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,

like, page actions, server actions, and and 10 start Wes you would just simply import that server action from your .server.ts file, and then it will just replace that with, 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 Node don't know if it's it's using a fetch request or an 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, inertia JS inspired, which is, like, very much server centric. Your server will compute. Your state lives on the on the server. The props come from the server and simply just will will populate. That's very popular in, like, non JavaScript land. Right? Like, Laravel is huge. Inertia. Js 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're talking about for, like, page you don't like the request being tied to pages? Like, are you leaning more towards, like, I'm gonna define my API layer separate and then just call it from whatever 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.

If I need endpoints, then the I have separate endpoints that then just call those functions. But in the SvelteKit 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, RPC.

And at a component level, it's way nicer because you you you're oftentimes duplicating a lot of code from loader to Node. 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 Node, 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 or 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 are, you know, going all the way down the tree rather than, this component has these props, the specific data, and it's tied to that component.

I see. This is my one of my hugest qualms with all of these frameworks.

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. 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 suite.

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. Yep. 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 rendered or at least, like, I don't have to put that in it. And what I have to do in, like like, tan stack 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 Svelte has that with asynchronous Svelte, which is I absolutely love it. React. I can't go back. Yeah. This is good inspiration for my framework, because right now, what I'm building has page Node. 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 server side rendering layer. Like, even though a component is declaring

a dependency on some loader data, that should still be server side rendered. That doesn't mean it needs to be client side. So that's that's people like, well, just just wait till it loads and then fetch the data. But, like, yeah, I don't want that. And and the reason why a lot of these frameworks don't do that is you can very easily make a, a waterfall website where, like, something fetches something, and then that loads another component. And then, oh, I'm that component now needs to fetch something else. And now you make you can make very slow websites, 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 the SvelteKit 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 auth baked in, which is using better auth, which I thought was pretty interesting to to include it. It seems like a lot of these tools, like Drizzle and BetterAuth, and they're they're not that old, but I feel like everyone is finally like,

this is it. Can we stop changing them? Yeah. BetterAuth 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. Yeah. And I I didn't see like, Evan didn't show examples of auth during the demo, but I'm hoping that it also, like, by default, gives you some pretty zero config stuff. Because, like, BetterAuth is nice, but you do have to configure things, obviously. But to get, like, just a basic username password login with no config would also be really nice for just the sites you wanna spin up like that. Node I was curious about that as well. It's like, does this

just give you, like, auth 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 auth login oh, no. That's probably for the cloud provider. Oh, you're That's for the cloud provider. Yes. Yes. Yes. I I think I think that's just for logging into void. But if you take a look at the example code they have here, they have import auth, which is powered by BetterAuth.

So I'm curious if it, like, kinda goes one step further and gives you like a Laravel or a Rails would give you if it gives you those users or not.

I would 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 auth and use it. So that's nice. Like Wes said earlier, this is tied to Cloudflare, so each one of those things has a Cloudflare backed backed service that's actually managing all of that for you.

But And and probably even further, it it, like, does all of the, like, wrapping of Drizzle for you, 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 Node, d b dot t s file myself, and I simply just import the d b, directly from that. Right? And and with the CloudFlare v plug in, 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 Scott of these, like, things I look at and and having used the Cloudflare v plug in with TanStack quite a bit, I think, I don't know. Like, 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 Vercel does for you. Right? Like, if you want a Redis database or Postgres 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 three line config file versus just importing DB.

So Yeah. No. No. Yeah. It it always is a delicate balance of, like, do I wanna figure out what the Wrangler commands are? Yarn of it is, like, the the Wrangler or the Cloudflare MCP, super good. You said it sucks, Scott? No. Wrangler sucks, but the MCP or Cloudflare Node is good. Yeah. You just ask your your agent, like, make a database Yep. And stick it in my Wrangler dot JSON file, and and it No. I

do it for you. I haven't used some of these Vercel things in a long time. But when they first announced, like, the Vercel DB and the Vercel 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 Vercel, at least Wes they launched it, and I don't know if this is still the case, the the key value was on Upstash.

The, Postgres was on Neon. So, like, they weren't, like, running that all through AWS or Node 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 Yeah. It this is all in one slide. Mostly just bindings.

Yeah. 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 kinda doubt it since Vercel is so performance. And very likely, they're all running on the same server anyway. They're all running in a AWS east one.

Yeah.

So the big, like, feedback and the big, like, talk that everybody had when this was announced is, like, is this not just lock in, to to Cloudflare? If it is so tightly coupled to Cloudflare, 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 wanna be very upfront about void being tightly coupled to Cloudflare. The lock in is what makes the DX possible. If you don't wanna lock in, then it's not for you, and that's fine. Vite will forever be platform agnostic. Use it with Nitro Vercel three or Adonis. The choice is yours, and void just gives you another option. So I I quote tweeted this as an unapologetically CloudFlare, meaning that if you want to have Next. Js Vercel level of DX, you do need integration between your infrastructure and the actual code that you're writing.

And as much as people absolutely hate that because they want to be able to move around to all of the, 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 Vercel. 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.

It will be.

Yeah. 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 think so. Like, it's Yeah. It's just code. Whatever code you wanna run, you wanna you wanna 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 JS, a lot of things can't, which is why they introduced things like d one and and some of these other offerings, because it specifically works inside of Workers.

Mhmm. But I I thought what would be kind of a neat, 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 if you're building on top of this thing, your database, SQLite or Postgres and Drizzle, that to me, that's not that's not lock in. Right? 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 standards as possible. And if I use Drizzle, I know that I could in 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 or Postgres. Yeah. It'd be a little bit

of a a migration. Because what I think about is, like, if you're using d one, you're using, like, that specific d one binding. But if you are running a deployed app that talks to a SQLite database, you're probably using LibSQL or Tersho.

So Yeah. I don't know. A different adapter. Yeah. You you can swap out the adapter. I don't know if that's gonna change your table definitions, but that would be the one the one step. 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. It's just just for I agree. Not because there's the issues, but it's just annoying. Yeah. Yeah. But I agree. Sing single single config swap out, it's not necessarily lock in. Auth.

Does 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 you into an auth platform. It's locking you into an auth library. Right? So, like, as far as this goes, you still get all the benefits of BetterAuth. 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 auth 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 Scott, like you're not having to rewrite your auth. Man, let me tell you. There's nothing worse than, having to change your auth platform or or change the, 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 auth package to avoid having to make all the users reupdate their Yeah. Passwords and stuff like that. Yeah.

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 JS, and then there's a TTL that you can put on a very similar to, like like, a Redis API. So kinda 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 Unstorage driver, which comes from on JS, it has adapters for For other things. Yeah. Like CloudFlare, Deno.

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 locked in because UnStorage uses the same API. It it 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 wanna talk to Redis or I wanna talk to cloud Cloud for KV. So We're a sponsor. How did I not know about it? What is the way I know about it? Oh, yeah.

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 adapt. So I use Deno KV,

Cloudflare KV. Oh, man. This all this whole on JS ecosystem is the best. Right? There's, like, unpicker, on whatever. If you're worried about lock in, some person that writes Nuxt for a living has written on JS version of whatever that is, and it it will come to save you.

Yeah. Because 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 Unstorage, then, yeah, it's a little bit of lock, and you're gonna 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 wanna be locked in, then just Build your own Take that there. Yeah. Write a, like, a six line six lines of code, where you can import and export this thing yourself.

True.

True.

AI.

Let's loop this in with, like I guess, like, there's there's Cloudflare Cron, there's Cloudflare queues, and and there's Cloudflare AI.

I would say that these things are fairly high on the lock in aspect, 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 trade off for, like, the the DX or the the cost for this type of thing. Yeah.

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 the Vercel, like, being able to have Crohn's 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 Yeah. Which is the dumbest thing to say. I've I've built I've I've worked with queues 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 a hell of a ton more.

I I I I totally agree. I have a project. I'm I'm working on my, like, uses.tech website, and I'm moving it over to Cloudflare. And there's there's one thing that is, like, a fairly large ingestion process, and it needs to wait and and all of this stuff, and it's a perfect use case for for queues. 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 queues were so easy, they were just there.

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 queues 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. Wes, like, we should say as well. Like, people don't mind that right now because it is so cheap. But Yeah. 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.

Yeah. 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, Deno, page routing, all of this stuff, like like, page routing itself, page handlers defining the stuff, somewhat of a special API, but Mhmm. The whole request response, fetch, React, Deno, this stuff is just standards Wes based. You know? I could take a a handler from my React Hano application and move it into a SvelteKit handler and and do very little,

work, and it would just it would transfer over very well. Yeah. I will say huge points for using building this whole thing on Node because Hono JS great. And, Wes,

I like it. I'm big fan big fan as well. One thing we didn't is is a question, and I asked this in their chat room. I said, like, will you 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 gonna have to do all the Wrangler commands and and whatnot yourself? And they said they don't know yet, which is kinda kinda 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.

BYOC, bring your own Cloudflare.

But I I I can agree with you. Yeah. I I don't wanna I don't wanna put my stuff in another place and have to worry about Deno. Like, I got all my stuff at Cloudflare Flare already. I would love to just keep all my stuff there as well. But I will say, this is what Vercel 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 Vercel supports, like, setting an AWS key or anything like that. Like, they they they upcharge you, and that's how it it goes. So I think Yeah. You're right. With void, it's probably gonna be their business model, which Mhmm. 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 gonna be to use VoIP versus, like, doing the stuff directly on Cloudflare? Because, 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, Vercel for Cloudflare. You know? Like, they're trying to make it as good as it's not there yet, but they're they're trying. Yeah. You wanna get better at it. 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, that you can just boop, boop, boop. Type it to the point, and it it it pushes it. I thought, yeah, I probably should've said that. But you know what I mean? Like, this is a great totally batteries included. And then, like, the the agents love Next. Js and Vercel right now because it is a tidy ass little package. So I think so. Mhmm.

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, the non Cloudflarey things. I don't know why you would do that, but I'm just, like, wondering. Cloudflare has,

Like, worker d is the JavaScript runtime. Like, it's not Node. Js. They have their own JavaScript runtime.

And when it runs locally via something called MiniFlare, it will try to replicate most of those things. Right? It replicates the databases.

It replicates its key key value, quite a bit of it. There's some things like, browser rendering. It doesn't 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.

But, like, yeah, would this be a thing that you could just stick the local version of that in, like, a Electron app and just get the whole

Wrangler experience? Yeah. I don't know. I I think it makes sense. Like, I think what you're talking about, Scott, is, like, you wanna use SvelteKit routing in an Electron app. Right? So, like, could we use this void page based routing in an Electron app?

Yeah. That that kind of thing. Yeah. Because what I don't wanna get into a situation like, if I'm going to buy into this stack, which, you know, I I I I've bought into SvelteKit 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 Tori 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. And my gut feeling is Wes 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 Wes run it in dev. Yeah. That's what I was thinking. It's like you you just run the Vite Vercel next to your Electron app.

Yeah. I've I've done it. Like, when I did my receipt printer thing, I ran the Next. Js dev command, and I had close to 2,000 people visiting it at once, and the dev server handled it fine. Yeah. I was like, why are we not just running dev in production? That's half a joke. Also, it's got a That's great. That's great. It's good. It's great. 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.

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,

we we know more. I as Wes. 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 kinda, gonna be building around those thoughts.

So in the comments down below, let them know your thoughts if you would use this or not because I'm sure they're gonna be reading it. Yeah.

Feedback is priceless. Your feedback is a gift.

Feedback.

Feedback.