Episode 64 - Delaney Gillilan

React made a lot of us feel powerful, then maintenance made a lot of us feel tired. Drew Bragg sits down with Delaney Gillilan, creator of Datastar, to argue for a different kind of “modern web” one that keeps the browser’s strengths front and center and keeps your app logic where it belongs: on the server. If you’ve ever looked at your dependency graph and wondered how you got here, this conversation is a reset.

We get concrete about what Datastar is and how it works: a tiny reactive framework built around HTML, data attributes, and signals, with a plugin system that stays out of the way. Delaney explains why most state should live on the backend, why duplicating validation and business rules in the client is wasted effort, and why hypermedia is still the simplest way to communicate what a user can do next. We also unpack the “send strings to the browser” philosophy and how that changes performance, complexity, and even team collaboration.

Real-time is where it gets spicy. Delaney makes the case for Server-Sent Events (SSE) over WebSockets for many apps, leaning on normal HTTP semantics, built-in reconnects, and streaming compression to ship tiny DOM diffs efficiently. From there we talk CQRS as a mental model for command intent vs view updates, plus what this means for Ruby on Rails developers weighing Hotwire, Stimulus, and upgrades. We close with two bold companion projects: Rocket, which makes Web Components more declarative, and Stellar, a Tailwind alternative that uses parametric CSS variables for a modern design system workflow.

If you enjoy deep technical takes on reactive UI, server-driven rendering, SSE, Rails, and modern CSS, subscribe, share the episode with a friend who’s stuck in SPA fatigue, and leave a review with the part you disagreed with most.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Honeybadger
Honeybadger is an application health monitoring tool built by developers for developers.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Transcript

Welcome And Guest Introduction

SPEAKER_03 0:00

Hello everyone and welcome to another episode of Code and the Coding Coders Who Code It. I'm your host, Drew Bragg, and I'm joined today by Delaney G. Delaney, I'm gonna let you pronounce your last name since I keep screwing it up. And also give us a brief introduction of who you are in case folks don't know who you are.

SPEAKER_00 0:16

Sure, my last name is Gillilin. It is phonetic, but it is hard to say. So, yeah, my background is I've kind of been in and out of the web space for since the original dot com rush. And for me, it was more of an interesting platform because it's the one sandbox that everyone can kind of agree on. So I've done a lot of interesting stuff around gambling, video games, military applications, all using the web more as a platform and a sandbox than in the way that it's normally intended to be used. So I've kind of used and abused GLSL and all kinds of crazy stuff to do some interesting projects. But in doing all that, I kind of came to a moment where I'm like, this is too hard, this is crazy, this is the wrong thing, and started with first principles, ended up with this project that's now called Datastar and some other projects around it to basically try to fix the web, not just take it back to the early 2000s, but actually use the modern web with the simplicity that we missed out on from those days. So that's kind of what I'm now known for. Unfortunately, I ironically hate JavaScript. So the idea of being known as a JavaScript framework author makes me really sad. But sometimes you have to have someone that hates something to make it better.

SPEAKER_03 1:28

So you hate it, so you want to do less of it, and you figured out a way to make yourself have to do less of it. I guess that.

unknown 1:35

Yeah.

SPEAKER_03 1:36

So the way this is gonna work for anyone new to the show is I'm gonna ask Delaney three questions. I'm gonna ask him what he's working on, kind of blockers he has, and what's something cool, new, or interesting that he wants to share with all of us. It can be something he recently read, discovered, learned, built. It doesn't have to be coding related, but this is code and the code encoders who code it. So it absolutely can be. So let's get this party started. In pre, I was expecting you to say, I'm working on Data Star. But according to you, Datastar is done. So before we dive into Data Star, what are you working on?

SPEAKER_00 2:11

You know, I'm just trying to do a quick little in and out project, 20 minutes in and out. I'm just trying to fix the web completely. So yeah, I have some attempts at that. So basically, I think HTML for the most part is a really good declarative syntax. So that's kind of good enough. That's fine. JavaScript has been a bane for everybody, and so I fixed that with Datastar. And I have one other project which is basically I understand all the reasons why Tailwind exists and why it was built, but it doesn't match the modern web. So I built a thing called Stellar, which all the problems that you have with Tailwind are now solved with Stellar, which has just come out. So basically, I'm just trying to solve the web first. The irony of all this is that I built all these things because I was starting to build my own database and said, man, I would really like to have an embedded UI that looks really nice, that works everywhere. Hey, the web would probably be the best way to do this. So the irony is I've now pretty much solved the web so I can go back to building my database. So it's like a three-year journey in and out.

SPEAKER_03 3:12

Yeah, it's super easy to just solve the web.

SPEAKER_00 3:14

Yeah.

SPEAKER_03 3:14

Can't be that hard, right?

SPEAKER_00 3:16

I mean, the thing is that we're pretty close. That's the people I don't think people realize because there's so much hatred for the NPM node module black hole and like the sysyphis and task of getting something built nowadays. But yeah, the actual platform is pretty solid. There's a lot of things that are really great about the platform. We just have done this crazy layering on top that's made it very hard for people to see how much has been solved in the meantime. Sure. Yeah, we can actually get back to that.

SPEAKER_03 3:44

Yeah. The first web pages I ever wrote, I was like, this is so cool. And then I learned React, and at first I was like, this is so cool. And then I started maintaining like React spas, and I'm like, this is no longer cool. Yeah. This feels way harder than the stuff I used to do for not much benefit, which the reactivity part of it is super cool. Like we have some React at work, very small amount because it's designed to solve a very small problem we have of a high user interaction part of our app. But it sounds like, at least from reading through the Datastar guides, and for anybody who doesn't know, I learned about Datastar when I had a recent episode go out where we were talking about live components and it was very reactive view components. And someone was like, This is really cool, but datastar already solved this. Why don't you talk to Delaney? And I was like, I don't know Delaney at all. Now I know Delaney. And after looking up some Datastar stuff, it sort of sounds like, why would you use React when Datastar exists?

SPEAKER_00 4:48

It's a really good question. And the thing is that this isn't born out of like me being a contrarian. The irony is I've put out, like I used to have top secret clearance and I worked on a bunch of military stuff, and I would use the web because it was very hard to get a binary to go through all the processes of being signed off on. Like there's a lot to do there. Whereas making a web app basically allows you to get things sandboxed in a very good way. So to me, it was a deployment platform, and I was doing really low-level stuff, but I was basically pushing against Vue and React install it. And I basically got into the weeds of like, okay, this isn't good enough. How do we fix this? And I started like trying to fix it. And what I ended up doing is basically the equivalent of Phoenix Live View. Because I was doing a bunch of spa stuff. Like I know the internals deeply of View and React and all that. Like I got into the weeds trying to say, okay, how do I fix it? And I basically made a Go version of that protocol where it's basically doing the equivalent of diffing on the back end and sending down the diffs, then you update that and then you get a live over WebSockets. And the irony is I spent a year and a half on that, making a really low-level binary protocol. And I looked at some stuff from like an HTMX example, and it was faster and better than the thing I did. So the irony is that I will throw shade at the spa community completely because I was part of it and it said, hey, I'm trying to do it this way, and it's just terrible. And the weird thing is for people that don't know Datastar, we are even like people compare React or something and Hotwire in size, like oh, hotwire is so much smaller and stimulus. Data star is five times smaller than hotwire. It's tiny. It's 11K, it is the world's fastest signals library, it's the world's fastest morphing strategy. It does all this in 11K, and it is dead simple to do. And it's also language agnostic. So the thing is, what you can do is what you learn from, hopefully, we'll get into is that as a Rubyist, you can be using the same style of mental model as you would in C or any other language. So you can actually have a community of people that are actually talking about the web again, not talking about this framework of the week. So the weird thing is we're a back-end agnostic backend framework for the most part. But we still have when it comes to reactivity on your page, we are literally the fastest thing there is in the world of JavaScript. So we're in this weird dichotomy that we believe most of your state lives in the back end, but the stuff that you do in the front end, we are by far the best in class. Nothing competes right now.

HTML Data Attributes And Plugins

SPEAKER_03 7:12

Yeah, it does seem that way. I haven't fingers to keyboard played with it, but I've seen a few videos now. I've gone through the guide a handful of times, like at various levels, and the dead simple part is 100% accurate. I think it was really smart to just use the data dash attribute. The one thing that I guess threw me off or prevented me from just being like, oh, HTMX clicks is like it's HX-whatever. And I'm like, okay, whole new set of things to learn. But like data-anything just feels like it belongs in my HTML anyway.

SPEAKER_00 7:48

Well, here's the thing that I've gotten into fights with Carson, who's the guy behind HTML. I love what they're doing there, but like it doesn't go far enough in my opinion. Like it doesn't solve the whole problem. It's a library, not a framework, first of all, and that's fine. But it also doesn't actually solve the problem. Here's a perfect example of I follow the specs of HTML specifically. And the reason why is there's already, for people that don't know, there's data-star attributes are part of the spec that says you can put any string in there that you want, and it becomes an insertion mode key value store that you can do whatever you want with on that element. The reason why that's important is because you put a spot into it, that means that the back end, the actual like turbofan and the optimizers and all that stuff, they know that that data set exists and they do all the right calculations on that. So instead of trying to deal with unknown attributes and do all kinds of crazy stuff, you're actually letting people optimize for the optimized case. So the thing is that in Datastar, we actively tell you we don't wrap things and try to hide things. Most people come in and go, oh man, I didn't know this existed in HTML. Oh, I didn't know this existed in CSS. We are not trying to hide things from you. All we're trying to do is get to a declarative, reactive expression, and that's it. Because the thing is, those don't exist in JavaScript. And what I mean by that is like when you set up a Excel spreadsheet and you're doing formulas, you're setting up a reactive relationship between things, right? When you say like this plus this is the sum of these two other cells, that kind of thing, you're setting up relationships. The thing that's built into the browser doesn't have that concept of like, oh, this thing's gonna drive this thing, this is drive thing. So all we do is data star, and the reason why it's so small is we just say, how do we turn this into a reactive expression? And then everything else is a plugin. Literally everything else. So the core of data star is actually about three kilobytes. So everything's a plugin after that. So you get things like data class, data adder, data this, but it's really a paradigm shift in the way that most spaws and stuff, or even hotwire, all that, they're trying to wrap things and try to like make their own little ecosystem. Data star is just like saying, what are the things that are missing to make this declarative? And then everything else gets out of the way. That's it. It gives you a very simple concept.

Signals And Where State Belongs

SPEAKER_03 9:56

Yeah, and the idea of signals is pretty interesting to me, where it's like that's the thing that when this value changes, there's like a cascading effect of like, if you're listening to this value, everything's gonna get run, whether it's a full-blown expression or it's just a display. And that makes a lot of sense. That feels slightly reacty, but I like that those signals. Well, I guess talk a little bit about the signals and how you want them to be used properly. Because I have all kinds of goofy ways I could use them.

SPEAKER_00 10:29

Well, the thing is that most people coming from a spa background, which is most people coming from the web nowadays, they want to use signals everywhere, like all the signals all the time. And there's examples, most examples in Datastar, unless you have like inputs that where you're actually binding to someone's input that they're allowed to change, there's very few signals on a page. That's the irony, is that even though Datastar has the world's fastest signals approach, we say you should only have a handful of them on the page at any one time. So it's one of those weird things of like we can handle 10,000 signals on a page, no problem. But why are you putting 2,000 things on a page as opposed to just the things that people can interact with? So there's a big move towards what's called isomorphic rendering, which basically means your back end looks like your front end. And I think that's complete hogwash. It doesn't make any sense. The thing is that state needs to live where state lives. Most of your state lives in your back end. When you do validation, like if you're doing client-side validation and then you send it to the server and you don't trust it anyway, and then you have another set of validation here, you're just doubling your work. You're not really getting anywhere if it's fast enough to do. So my thing is state needs to live where it lives. So there's things where if someone has a mouse movement, that should be tied to a signal, because then you can drive other things on the page that are instantaneously that the mouse control is owned by the client, right? But the click, like the logic of what is allowed and not allowed, belongs on the server. So people tend to put state in the wrong place, and that's why you see tons of JSON getting sent down. You see all this polling, you see all this stuff, is because they're putting state in the wrong place. So they're having to recreate the entire world of state in the client, and that is just a recipe for disaster. One of the beautiful things about the web is hypermedia. And the idea of hypermedia is you show what you display declaratively what you want the person to see and what they're allowed to do next. That's it. They don't have any logic on a H like in pure HTML, there is no logic saying why this is a bank transfer, why this is paying your taxes. There's no logic of that. There's just here's the view, and here's what you can do next.

unknown 12:23

Yeah.

SPEAKER_00 12:23

Once you really embrace that, things get so much simpler because most of the state lives where it's supposed to live. That's it. It's a pretty simple concept. We're not doing anything magical. That's why we're so small.

SPEAKER_03 12:33

Right. So, I mean, it sounds like a simple concept, but it's not always been it's simple in theory, not always simple in practice. Maybe it is if you're using Datastar.

Why SPAs Happened And Why Now

SPEAKER_00 12:44

Yeah. Well, and the thing is that there's a clear delineation of why this happened. We had Ajax back in the day. Like the thing that happened is basically server tech at the time, like if you look at Apache, it was basically creating a new thread or Glassfish or any of these. You were basically creating a new thread for every request. Well, that doesn't scale to thousands of people and it didn't work. Like it worked fine when you had one or two core machines, right? Like this idea was okay because you're gonna do sharing anyway, but it doesn't match the web of today. So the problem is that spas were trying to say we want more interactivity on the browser. We need to make Google Maps. We can't do all that logic on the server because the per thread thing doesn't work when you scale up. All that's been solved since then. So the mental model that people have of why spas exist was to solve a problem that's already been solved. So they made this complicated thing, and it's basically a boiling frog thing of it just got worse and got worse and got worse and got worse. And no one kind of sat back, me included, to be clear, Datastar could have existed more than a decade ago. There's literally no reason why it didn't exist 10 years ago, other than everyone just was kind of being the frog and going, well, this is just I guess Vercel is now like one more NPM module, and we got this. It just got worse and worse. And I'm part of that problem. So, like, go fix it. So we fixed it. Sure.

SSE Versus WebSockets For Real Time

SPEAKER_03 14:00

Sure. The one big difference, I think. So being a Ruby on Rails developer, I'm using Hotwire a lot. One of the ways that we do the real-time updating or the I click this button and everyone else sees the result of that button click is via WebSockets. But in Datastar, you guys are using SSE, which is server send events, yes, which is not a new protocol, but it was very new to me. I've been doing this for a while now. Why is that like I'm just learning about this protocol? Uh, yeah. It's been around for a hot minute.

SPEAKER_00 14:35

I fell into this trap too for years. So I was doing a bunch of military stuff where I was sending direct GPU information about radar sites and doing millions of blips per second kind of stuff, like really low-level stuff. And the thing that I thought was like WebSockets is the future of WebSockets solves all problems because I just get my socket. I can do whatever I want. You basically get the equivalent of a TCP socket. Once it does the handshake, you get it. Now I can do anything I want. The greatest part about WebSockets is you can do anything you want. The bad part is you can do whatever you want. And the reason why that's bad is all of a sudden you can't do cookies because once you upgrade, you can't change out cookies. You now have to write your own compression stuff. And then when you write a compression, guess what? You're doing it in JavaScript. You don't have access to the actual C stuff. It's basically its own island. And now you have your own equivalent of cords to deal with. Like you have all these things, sticky sessions. When you break off, you have to do auto try to reestablish. And so what if the server switches and all this? Like you're basically eschewing the entire HTTP stack once you get that upgrade handle. Like once you get a socket, you're on your own. What data store does is people think SSE is a new protocol. It's not. It is literally just a different response type. So instead of text slash HTML, you're saying text slash event dash stream. And then what happens is there's this like data colon and then your data. There's a couple of extra things, and you do two new lines, and that just basically means flush to the end. So it's just a text format. That's all it is. Yeah. So here's the things that are really neat about that. First of all, it's a normal fetch. There's nothing special about it. So you just get normal fetch semantics. That means all your proxies, all your stuff, it's just normal web traffic. There's nothing special about it. There's no kind of weird reverse proxies. You have to do nothing of it. It does not exist. The other thing is has built into it the idea of auto-reconnect. So if you get lost, you can actually say, I want to reconnect, and this was the last message I did see. So that can is just built natively into it. The other thing that's interesting is that the one thing I thought was really dumb at first was like, oh, this is just for text. That's not really that useful. But one thing that's come around in the last 15 years is that you have streaming compression libraries are now native to the browser. Like Brottly and Z standard, not only do they compress per message, but they actually compress in a stream, which means if you start doing a table and you get table like TR, TD, TD, TD, TD, that all becomes like single bits on the wire. So the irony is that the text format, because they already know about all the stuff in the dictionaries and stuff, like they actually become smaller than sending the binary version. So you have this text format that's dead simple to write that compresses to tiny amounts, and it also is just normal HTTP. So you get all the benefits of just a regular web thing, but you also can send anything down, which means we can send down signals and we can send down new patches of elements and we can morph them in very similar to how Hotwire does it, but we actually work with the Hotwire team to make that faster better. So ironically, if you're using Ideomorph from Hotwire, Micah is the guy behind that. We have the fastest version of that as well. So ours is faster than the one that you see in Hotwire by quite a bit.

SPEAKER_03 17:40

Yeah, that's a fairly new addition to Hotwire and Turbo that I think it was Turbo 8.

unknown 17:46

Yeah.

SPEAKER_00 17:46

Well, then here's the problem if you're coming from a Hotwire perspective. There is the like the standard WebSocket morph stuff that's now doing redirects and links, and now you're having to go and pull again. So you're doing this request reply, request reply for every message. That basically you do the redirect stuff, right? You do the 304s, is how you morph in new stuff. But the data star way, you only send data when the server wants to you basically keep that connection open once you start, which means you've now just half your RTG time and you can make responses that are independent of requests. So by default, data star is actually completely collaborative by its very nature. If you want to go, I don't know, because it's mostly audio for you, we can go and play a game of a billion checkboxes, have exactly the same state, real time live, and play like a game, and there's no extra code. It's like a few hundred lines of code to build the entire thing. So data star by its very nature is collaborative first, whereas the problem with stuff obviously in a hard wire is that you have this all this basically request reply and relinking stuff. You have the frame stuff, you have the streams, you have this kind of HX boost style thing by default. Like there's all these things, and it's not all of it's not using fibers and the async stuff. Whereas the data star way is basically async and fibers first, and it's simpler because there's not a you use streams for this situation, but then you use the 304, the link stuff for this morph strategy. No, it's all dysmorph all the time, all over streams. In some ways, it's simpler because we just built for the hardcore case first, and then everything else is simple from there.

Rails Upgrades And The Datastar Bet

SPEAKER_03 19:17

Right. I think the hardest pitch for Data Star to Ruby on Rails developers is not even just datastar is better than Hotwire. Hotwire is what Rails ship with, and anyone who's been doing Rails for a reasonable amount of time and has had to maintain a Rails application knows the closer you stick to what Rails gives you out of the box, the easier your upgrade experience is. So what's the plan for that?

SPEAKER_00 19:45

So my idea is datastar itself, the core concept, like unless the web browser actively changes what's supported, datastar is done. It's done. So your upgrade path is you can upgrade to whatever you want because you won't be subject to all the turbo and stimulus changes that are happening. You just you're just opting out of that, like you just don't need that anymore. That is part of Rails that you don't have to be beholden to. You're not waiting until someone makes a change there because it's an unnecessary thing, because not only is it bigger, it's slower, and it doesn't do as much. So the irony is that, for example, Datastar is smaller than HTMX or Alpine, and it does everything that both of us do combined. So it's one of those things of like, there's a reason why we're so much smaller. It's not a like, yes, it's kind of nice to boast that like, hey, we're small and we're you know we're faster and all that. But the idea is that it's so simple that there's not that much to change. There's not these great upgrade paths, it's done. And also, one thing to be clear is that data star internally is built on a plugin system like a game ECS. So if we completely foobard something in there, you could literally pop that out and put something else in, and nothing about data star changes. It's all built on plugins, the entire stack is. So we can be wrong, and you don't have to change anything about your code because it's all declarative. Like, for example, when you do SQLite, when you say create index or like query plan, you're not having to think about all the B tree underneath or like how they're doing their thing. You're just saying create me an index in the best way that you know possible. Like it's all declarative, right? Datastar is much more declarative in its nature, so that if we make huge updates, your code doesn't change. Right, right. So if anything, it's much, much simpler and it's actually better than the hotwire path. Like, I really do think if DHH looked at really gave Datastar a try, he would agree that it's better than Hotwire. Hotwire came out of a necessity at the time that does not exist anymore. Okay. I would love to see him actually try it because like it would be an interesting conversation because I really do think it solves the core ideals of Ruby of being simple and elegant and all the things that are intended by the language. It does that to a deep degree.

unknown 21:56

Right.

SPEAKER_00 21:57

It just happens to be in JavaScript, unfortunately.

SDKs Across Languages And Community

SPEAKER_03 21:59

Yeah. Such as let well, I mean Turbo is in JavaScript, stimulus is in JavaScript because we have we have helpers that allow us to not feel like it's in JavaScript. The SDK that you guys have for Ruby for Datastar is pretty basic. You're not getting the same kind of helpers you get out of all the Rails helpers with Turbo. You get a bunch of helpers out of the box, ways of writing it on the server side that doesn't feel like you're writing anything other than your standard Rails and Ruby, which almost made it feel like the idea was okay, fine, Rails has hot wire, but Hanami doesn't, or Sinatra doesn't. They can, because Hotwire is also a back-end agnostic deal. But was that intentional where it was like, okay, we'll keep this SDK super simple that way if you're doing Sinatra or Hanami or whatever the new next Ruby framework is, you're just good to go and we'll let you figure out the integration stuff, or is there a plan for, yeah, we'll do the Rails stuff, and then maybe if Hanami gets big enough, we'll do the Hanami stuff?

SPEAKER_00 23:05

Yeah, no, it's a good question. So the one thing that's interesting, we have SDKs for about 14 or 15 languages at this point.

SPEAKER_03 23:12

Yeah, there's a there's a lot.

SPEAKER_00 23:13

Well, the reason why is because I don't know if you know, but the SDK is basically three functions. You implement these three functions. And you're done. There's guidance, and the thing is it's that doesn't sound like a lot, but at the same time, it's guiding you in a way of setting up compression correctly, doing all the right things. Like there's an ADR, those three functions have a big old ADR to say here's why and what you're doing. But the thing is that, like, for example, in Go, everything's built around a standard lib. Like there's an HTT server and all that. There's any language that has this stuff, but for the TypeScript community, we have the TypeScript SDK, but we also have people that have done ones for Hano or for Express, those kinds of things. So it's not just a back-end agnostic framework, it's backend and framework agnostic. So the thing is that our Ruby community isn't that big right now. The only reason why is because it's not built in. But I do think as people use it as rail authors, one thing, a curse and a blessing of Ruby is that you can monkey patch to your heart's content, which means if you want those helpers, you're a couple lines away from saying, hey, I'm gonna build an SDK on top of this. Like you can build the monkey patching that you want to see on the objects on your controllers as you choose. We just haven't seen that in the closure space, there's a proliferation of different people doing different and in Python, those two languages have so much expressiveness in their languages that we've seen a huge uptake in the different kinds of projects built on top of Data Star as more of a framework on top of it. And I see that Ruby would be the exact same, you just got to get someone in there. Because I think for me, a Sinatra style thing with helpers seems like the right would be kind of more in line with the data ethos than the entire Rails, do everything, embrace the magic kind of thing. So, but there's nothing about data star itself that's it's completely agnostic to that. So I would like to see that's one of the reasons for like coming and talking to you. Like, there's literally no reason why the Ruby community for Datastar isn't bigger than it is. Right. There's no technical reason, it's a social problem, not a technical one.

SPEAKER_03 25:52

Datastar is a really is surprising that DHH hasn't played around with it because he's all about that conceptual compression. He says it all the freaking time.

CQRS Mental Model And Full Page Morphs

SPEAKER_00 26:03

It is a manifestation of that, even if we disagree on specific details, sure. In fact, if anything, I would love for him to see it and tell me why it's wrong. Because that would actually be more insightful. Like, for example, when you talked about the TypeScript stuff, I will say that this is actually kind of funny. Like when the data star stuff first dropped like three years ago, it was like, here's all the features, here's all the things. DH would hate it. Because it was right when you're saying TypeScript is completely useless, TypeScript's bad. That was on the cons and on the pros, is that DHH would hate it. So it was the plus and minus of like, but the thing is what he was saying, he clarified later that TypeScript doesn't show any value for us, right? It's too complicated for us. And I get that. So it'd be interesting to see what he sees in what Datastar is. Tell me why this isn't the best thing to happen to the web in a long time. Because I know it sounds like I'm hyping it, but it's just like now that it's done, I don't want to go on podcasts, I don't want to do a bunch of talks and stuff about it. I just want to get back to what I'm doing. Hopefully, someone else kind of takes that mantle going forward. Uh, like I know we talked about doing this for a while. So, like, this is talk season right now, and I'm not doing a talk on it anywhere because it's like figure it out for yourself. It's already the fastest, best thing. So if you're interested, great. If not, okay, cool. I'll go back to doing normal stuff.

SPEAKER_03 27:15

Something that generally comes along with that conceptual compression, though, is mental model shift. Where you're used to doing it this way, but if you just change your mental model a little bit, everything gets simpler because you're now able to function within side of this conceptual compression. Like, what does that look like for datastar? What are the big areas where it's like, this is probably how you're used to doing it, whether it's traditional HTTP stuff or it's spa stuff. Yeah. You might have to tweak your approach to get the best value by doing X, Y, or Z.

SPEAKER_00 27:51

That's a great question. So we actually have on the website, because we kept running into this issue, we actually have the Tau of Datastar, which actually goes through what we think are the best ways. There's nothing about Datastar that says you have to build this way, but if you do, your world gets better, is the CQRS style, like command query responsibility segregation. And the idea of that is that when you're building things in Datastar, normally with most things, you'll do a request, it'll get a change, like a morph kind of thing, and then send it back as the way people, even if you're doing hotwire or if you're in spas, you send a request, you get back JSON, and then you turn it into the dev. So the Datastar mental model for people that really hit things hard is your commands are your intent of like you clicked a button, you did a thing, you said, hey, this person moved a mouse. I'm gonna send a command to the back end saying, I would like to make this change. Not I made this change, it's basically saying, here's a stream of different things that I'm trying to affect the page in. And then that is completely separate. So you're doing that in your back end, you're handling that request, and then instead of sending a response, you send basically a 200 saying, yep, got it, it's good. And then on a separate event bus type thing, you basically let other people know that this is a change that happened. And then on another channel, you basically say, when you start up that page, you basically say, Hey, give me updates for this page that I'm looking at. And so that's an open connection. And then whenever something gets affected, you send down basically a revised version of the view. Yeah. So by separating those things out, what happens magically out of that is that all of a sudden, like let's say you're doing a to-do, right? And you're adding and removing stuff from a to-do. You're sending those commands off, it's updating, seeing if it's valid, all that stuff, and then it's updating a key value store. Well, some other person could be listening to that key value store and then basically updating. Now it doesn't matter if you change it from one page or someone else changed it, or it came from a back-end process, everyone's looking at that same view at the same time and get the exact same state. So you cannot get out of sync with each other. And now all of a sudden, you can do stuff like there's an example that we use all the time of like a game of life that's played in real time. Uh, you probably saw it, right? Like, yeah, yeah, yeah. So it's a real-time game. To be clear, that's a rendering demo. So it's actually sending 2,500 individual divs every single frame, and it's updating that live, and it can work on a 3G phone. So it's fast. Yeah, and that's the thing. It's actually not that fast. It's a rendering demo showing how even if you do things wrong, it still is fast.

SPEAKER_03 30:17

Well, it feels fast.

SPEAKER_00 30:19

That's kind of the point, right? Is that we can do some crazy things. So the other thing that's interesting is that data star is built as a progressive performance, not progressive enhancement, but progressive informance. So, what I mean by that is that normally people can just send down the entire page. They just you send the whole page because of the compression, it's actually like just the diffs between it. So you send your big fat morphs down. But you can, if you all of a sudden got into an issue, you can basically only target one part of the page and just update that because everything technically is out of bounds all the time, kind of like the HX boosts a little bit. It means that you can target select stuff, but most of the time you have a mental model of just sitting down, here's the state I want the thing to be in. So the irony is I built it to be the super performant thing that you only target certain things, blah, blah, blah. But we found that it's so fast that you could just send the whole page down. So ironically, it feels a lot like JSX in that you know how you just are declaring what you want the page to look like and it does all the V DOM stuff. Well, our V DOM is like broadly compression. So we don't have to logically think about any of this stuff. You just send down the page as you want it, and you get the thing. So that's a weird mental shift for people because they're so used to like you can't do that. You can't send down a whole new page, but we have things of like the game of life, the 2500 divs. We have now have production apps that are now doing the equivalent of full Excel, like the equivalent of Excel in the browser. We have companies that are doing that, and it's faster by orders of magnitude than the spaway. Because people said, Oh, this is great for back-end processes, but it can't work for a map or for Excel spreadsheets. Well, what our one of our biggest success stories is literally a spreadsheet app, and then like on our website now, we have an open map 3D view as one of our examples that we just throw in. Because we are the fastest version of client-side state, but the whole point is you should have very little of that. So that's kind of the thing is that we are just the fastest way to do this stuff. And the irony is that it's less code. I don't know Ruby enough to make this guarantee, but I can make this guarantee in almost every other language that I do know. If you tried your hotwire and stimulus stuff and you tried it in Datastar, it is gonna be less code and it's gonna be faster. I have yet to been proven wrong in any language so far. I'd believe it.

SPEAKER_03 33:22

Yeah. Just going through the guides, just seeing some of the examples, not actually writing the code though, but like I definitely could see it being less code. Yeah. Whether it's going to click the same way that like maybe Hotwire does because Hotwire is built in is a TBD. Once I play with it more, I'll be able to speak better to that. But it does seem like damn, instead of having to write a whole stimulus controller, like I'm inlining a lot of this stuff. Yep.

SPEAKER_00 33:54

Well, we have a different vibe than like we have a Discord server that's very active. And the irony is that we have, I think, around 4400 stars on GitHub, but we have 2200 people on our Discord, which means I don't care how many people use Datastar, but my thing is that ratio is crazy. Yeah, people that are starring one click are now also in the Discord. So the thing is that you have a community where like Hotwire, I will tell you, I tried to get hotwire running in Go, and it's an utter nightmare. Like it does not work very well. I didn't want to go off and build all this stuff, but you know, I ended up doing it because Hotwire did not work in Go. It is built for Ruby, in especially Rails. It's built in this ecosystem. The way Datastar is built, everyone in every language can talk to each other. Like you're talking about compression, but the idea that I can have a conversation in Zig that is able to talk to a Rubyist about like what's the best way to define these helper functions and all that, there's something magical about that. That you grow as a community by being able to see the beauty in each language, as opposed to right now where everyone's living these little tribes of like your Hotwire people do not talk to other people outside their domain because it's just so much tribal knowledge learned. Whereas the Datastar Way is just using what's already in the browser. So if anything, everyone learns to use the browser better.

SPEAKER_03 35:13

Yeah, Hotwire definitely was supposed to be or has the capability of being like back-end agnostic, but obviously being bundled in Rails gives Rubyists a big advantage over it because all of the helpers, it's just so easy to get running on Rails. Luckily, it does work in others. I haven't met anyone who tried it in Go, but I've met plenty of Python people who have tried it in their various frameworks and are using it to success. But yes, datastar is so much simpler. It really is crazy simple.

SPEAKER_00 35:52

My thing is in the Go SDK, there's a bunch of helpers built in. Like there's speculation rules where it automatically like dumps speculation rules into your page for you. It does some nice redirects, it executes scripts, it does all the like there's things in the Go one even that are helpers that aren't in the Ruby one. But again, you have to get Ruby us in there to really like starting to fight it out on like what they want to see. And that's the thing is that one thing I do see at the Ruby community is people that are just like, hey, I just want to get my stuff done. It's not like Linux distro hopping. You're like, yeah, this is good enough for me, it's good enough for what I'm doing. If it wasn't, I wouldn't be using Ruby and Rails, right? Like if I need something more hardcore, so it's almost pragmatic to a fault in that they're not seeing there's no reason to upgrade, but as soon as you try, I like that's the thing is I want to have a conversation now that you're kind of interested in it, have a conversation after you've actually built something with it. I'm not good at selling it because I'm like, if you don't want it, then don't use it. But like it's so much it's weird to me that now look back at if I go to like the web dev on Reddit and I see the things that people are complaining about, it all seems like this crazy, weird. Like, we are kind of the small little cult that looks at the outside world going, y'all are crazy. What is going on here? It seems so ridiculous how many hoops people jump through just to not use the web as it's intended. So this is the thing that's really hard for people. Like you're talking about the thing that feels different about Datastar, and it's embracing the fact that your job as a web developer is to get strings to the browser as fast as possible.

SPEAKER_03 37:28

You are the fastest thing you can do in the thank you for oversimplifying my job, but yes, you're a hundred percent correct.

SPEAKER_00 37:34

The sooner you get it into a string format that you can hand to the C and C side, the faster it is. Because it still has to do that work. If you send VDOM or JSON and it still has to do the work of turning into a string that gets parsed, that's still what has to happen. So by realizing that what's my job is to pass butter, like your job is to pass strings. That is your job. And as soon as people embrace that, a lot of the things that you see people do seems crazy. Because what they're doing is they're basically rebuilding the entire back end state in local state and keeping this weird cache of like what state is, and then still turning into strings. It's like someone having a VM to then try to write a bytecode in to not deal with their VM. It's turtles all the way down. It's like, but we already have DOM parser is built into the thing. As soon as you hand it, you get back a DOM object. That's the it can handle millions of DOM nodes a second.

SPEAKER_01 38:28

Yeah.

SPEAKER_00 38:29

Why not just send strings to the browser and let it do its job? Your job is to send strings. People do not like that fact.

SPEAKER_03 38:36

I don't know, it's weird.

SPEAKER_01 38:38

Yeah.

SPEAKER_03 38:39

The one thing that I'm very interested when I start trying, when I start playing with it in earnest, is gonna be I really like stimulus for the convention of like, this is how I organize my JavaScript. I have to write some JavaScript, not a lot, it's sprinkles, but I can write a little bit of JavaScript and I can attach it to whatever element I want. And there's a basically like a convention to do it. I don't have to think too much about it. But Datastar doesn't seem to really have that. It has all of the attributes, you can do everything in those attributes. It almost feels a little like I'm teetering on the edge of going back into jQuery soup.

SPEAKER_00 39:17

I understand exactly what you're thinking. The weird thing is like jQuery was so right and yet so it was right for the wrong reasons. It was these sprinklings of things, but the problem is it at the time the backing couldn't do enough stuff. So I will say I will highly, highly, highly recommend going through the guide, going through the stuff, then coming onto the Discord and going in the data-Ruby channel and show us a production issue you're actually running into. Because most of the time when people I know exactly the feeling you're feeling, I get it. Like we get it all the time. And the thing is, you're like, it can't be this simple. There's a super complex thing, you're dumbing it down because you want to like hype your framework. I get it. It sounds like I'm telling you show us a production issue that's actually an issue, and we'll and it you all of a sudden you'll start deleting code and going, Oh, because the thing is once you get the cycle to the server where it's not like request reply, request reply, but it's just sending commands, acting and having a separate stream for doing the actual updating and rendering, so many of those problems that you're used to running into just go away. Like they just go away. And what's an example that you're thinking of right now that you're like, this can't work?

SPEAKER_03 40:29

I need more organization than this. I don't think I have anything where I'm like, oh, you know what? I don't think it'll work for this case because I'm just thinking, as I'm like looking at it, I'm like, yeah, it has to be more how we can do this. But it almost is the same way from when I went from jQuery to stimulus. I mean, there was some React and Vue.js in between that, but even when I first looked at stimulus, I was like, uh, you know, there's something I'm missing. And then it was like, well, no, it's just a really nice way of organizing your JavaScript so you don't get back into that jQuery soup. And I like that. I like that there's a kind of a defined, there's guardrails. I can still get it, I can still make it really fucking messy if I wanted to. And I have seen some messy stimulus controllers, but at least there's some guardrails. Data starter almost feels like a slightly sharper knife, where it's like, if you really want to, you can make this hard to grok.

SPEAKER_00 41:27

The thing is that I this excites me because it's like, cool, show receipts. Like, I I like I'm looking forward to seeing what because the thing is, I really do think that the signal and the reactive approach, the irony is that even though like I tend to like lower-level languages, I really do think Datastar is the best version of FRP functional reactive programming on the web. It takes the ideals and says, once you have reactive signals, it says when this thing changes, this thing updates, and these things affect these things, a lot of that structure that you had to put in place goes away. And then because all these signals and all this stuff, all these expressions were set up in your back end of choice, means that you use Ruby to define Ruby stuff and that the contents of a the equivalent of stimulus for you is stuff that you define in Ruby using Ruby constructs to then generate that text, because it's just text, just strings. Now all of a sudden, most of your logic is in Ruby. So you're in the language of your choice using the tools of your choice, which means most of that structure that you're looking for was already in your it's like saying templates can't be that simple. They have to have more logic. And it's like, yeah, yeah, the logic of how you define your view controllers or whatever is in your Ruby language. That's where all your work is. So that's the beauty, is that all that work doesn't magically go away, but that structure that you need actually lives in the language of your choice. Yeah. It doesn't exist even in the JavaScript. The JavaScript side is just the final declarative thing. It's just like saying SQL can't be, you can't just say from foo equals bar. You have to have generated that somehow. Well, yeah, you generate in the language of your choice, whether that's an RM or just concatenating strings. Yes, that's all it is. So all I'm saying with Datastar is you can have that same kind of like create your SQLite query however you want. That is logically simple. It's easy to vet, it's easy to test. Data star has now solved the web by making it more declarative. So it's just a set of strings, not a huge set of JavaScript. So I basically issued your problem by like, I reject your reality and substitute my own. You just don't need to do that anymore.

SPEAKER_03 43:25

Yeah, yeah. I'm very interested to give it a try. It always is like I can read a guide numerous times and come up with all of these thoughts, but it's once I start actually building something with it that I'm like, oh, I like this, or okay, this is a pain point. Then I go to your Discord and go, this is a pain I'm having, and someone will be like, that's because your mental model's wrong.

SPEAKER_00 43:48

And I say go to the Discord sooner than you think. Because each language has different semantics on like why and how you would build things. Like the helpers that you're looking for, you might say, Hey guys, do you have ideas of like what's a good version of this helper? And Isamon, which is the guy that does the Ruby SCK, he'd be like, Oh yeah, yeah, we can just add those. Like, cool. Like we can just have a separate module for Rails that does like basically wraps up. But the thing is, the reason why most of that stuff doesn't exist is because once you get into it, you may go, I don't need any of this.

SPEAKER_01 44:16

Right, right.

SPEAKER_00 44:16

Yeah. That's the part that I'm actually more interested in the next conversation of having like, okay, that you've had all the guardrails off, you've had the knife the way it is. It's like having a Suba on a lightsaber. There's no guardrail on a lightsaber, like either you know how to use it or you die. Like it's kind of that thing of like maybe you don't need as much of a guardrail as you think you do because everything's so simple, it's a mood issue. So I'm more curious to see where that goes for you and tell us what we're missing. Because we're very much we're reactive to the community in that, like we don't build stuff just to say, hey, let's wrap this thing and wrap this thing. It's like what are the things that you need and let's explore that.

SPEAKER_03 44:58

Yeah, and do you actually need them?

SPEAKER_00 45:00

And the thing is, most people come in saying, Oh, I want this, I want that, and then they actually build something and go, Oh, never mind. It's a daily thing on our Discord, is like, oh, right, you must unlearn what you have learned.

SPEAKER_03 45:10

Yeah. Related to Datastar, but very different from the technical stuff we've been talking about that I did want to touch on because I'm curious about it. I don't run any money making projects or have businesses or anything, but I'm always curious. So, some of Data Star has that pro version as a way of like funding development, etc. Like, how do you decide what's free? How do you decide what's pro?

SPEAKER_00 45:37

Okay, so there's kind of gone through a couple different Different iterations. The first thing we did is we were basically getting to the 1.0. We're now like there, we're just like literally we were actually deciding if the next RC is literally just 1.0. In my mind, that's it could have been a bug fix. Most of the stuff could have been a bug fix. So we a while back when we were making signaled library faster and all this stuff, for a while there, when I first came out with data star, it literally was here's three plugins, here's how you write your own plugin. Good luck, everybody. Because I basically like if you use data on data signals and data in knit. I think those are the only like I basically had a couple of ones that I used, and I'm like, this is good enough for me if anybody needs plugins. But what happened is people started coming in and saying, Hey, how do you write this plugin? How do you write this plugin? And it was just so easy for me to write them that I was like, oh, let me do an example first for you before you start writing plugins. Like, let me make sure the plugin system worked correctly before I start telling people just write whatever plugin you want. So over time, over the years, we ended up with a ton of plugins. But what I found is a lot of the plugins people should not be using. So the irony is like when we did the whole revamped, we basically forked our own project and like redid everything. And I said, these are the plugins that people actually need. And the rest of these you shouldn't use and their support burden. So what we did is we actually rewrote like when we were rewriting them, we actually put them in pro because we're like, if you're gonna be a support burden, we want you to actually pay into the project. Yeah, that's fair. So a perfect example one that people got really mad at people get mad at this. The irony is the old plugins are 100% there. Not only that, is the people have made community versions of this stuff. In fact, there's literally a project called Data Spa, which I highly disagree with, but again, go for it. Do your thing, have fun. But we don't have to support it. So we're in a weird spot right now where some plugins I think you should not be using, which are in pro. But there are things like, for example, I have a data animate that rivals, if not, is better than anime.js out of the box that makes it all declarative. That's really exciting. The problem is that plugin is so big, it's almost as big as all of Datastar, right? Like it does all the animation stuff. So it's like a green sock or something like that. So it's plugins that are too big or that are out of scope or are things that I don't think you should use. For example, that is data persist. People want to use data persist all the time to basically save it off to local storage, right? The problem is now you have a cache on your cache. Now you're trying to save state locally that actually should have gone to the server. And people are like, well, what if it's just for a light or dark theme? Most of the time, you want to send that light or dark theme because you might change the images that you're using, you might change subtle details. It's not just a light or dark of tailwind CSS if you do things correctly, right? So and there's also things like data replace URL, where basically people want to mess with the use signals to drive the URL. Sure. And people are like, well, yeah, why is that a pro thing? That's but the problem is what happens when you are updating at 144 frames per second. Now your history is completely blown out. Almost always when you're doing that stuff, you're using it wrong. You're doing something that's going against hypermedia, it's doing a spa-like thing. So a lot of the stuff is either too big or complicated, or stuff that actively goes against the tau of Datastar. So sure, that's part of it. But the other thing is now we also have things that are pro features, like we have it at full inspector, because in the browser, SSE is kind of hard to like it, doesn't always work, the debug panel. So we have a full inspector that does all that kind of stuff, does all the tracking of your signals on the page. When you hover over it, it highlights where it's used on the page, all the events that are coming in, all the SSE. It's a pro tool. And then I have the stellar thing that I just did, which I think is a tailwind killer, and all this stuff is part of a lifetime license. So you help the project. Some people bought the license and don't use any of the pro features. They're just like, I want to help the project because it is under a 501c3. It's set up in that way. It is a nonprofit. So me and Ben, the other guy that runs the thing, we didn't want to be in a situation like Tailwind was where if data store is successful, we want to have some money coming in that is equal to the success that we have. Whereas with Tailwind, all they're doing is competing against everybody else doing Shad CMs and the boots. Anything they do isn't really helping grow the community. So we have more of the kind of like a game engine or Pico 8 style thing of like, if you do pro features, it's like buying the game and then all the mods are available for free forever. But you have this core engine that is paid so that if it does become a super big thing, then the project could become self-sustaining, possibly. It's more of an experiment of like you use Stellar for a day, which we haven't talked about, or used any of the pro features for a day, you've now paid for the license for the rest of your life. So people say it's expensive for a JavaScript framework, but it also has a tailwind killer. It'll have a whole framework library, a UI library coming soon that's also agnostic to language. So now everyone can be using the same components agnostic of language. These are all good things, in my opinion. So yeah, it's more about sustainability if it gets too big.

unknown 50:27

Okay.

SPEAKER_00 50:28

But if it's not big, it doesn't make that much of a difference. We actually added it up over the year that we have far less than a minimum wage doing it. So in fact, I haven't taken a single dime out of it. It's there so that we can pay for like going to conferences or running the website or stuff like that. If you're gonna be a burden, you should be no, that makes sense.

AI Tools And The Race To The Middle

SPEAKER_03 50:48

That totally makes sense. Yeah, yeah. Yeah. It's always interesting to me. It's like, cool, we have an open source project and we have to make money on it. How the hell do you do that? Like, how do you decide what to do?

SPEAKER_00 50:59

And I don't think you do. Problem is that there's really two ways, because I work at Scenadia uh during the day. Like my day job is working on Nats, which is an open source project for real-time distributed messaging and stuff like that. And it's open source, and I know all the media, like it is building a company that's not VC based, that's doing open source, I think is basically impossible. So my thing is more I want it to be that if it is seen as a net good for the world, that it can help pay for being able to actually go to a conference. Like, that's all I want out of it. Like it's a more of a pay-forward thing, and also part of the thing, too, is I just wanted someone to prove me wrong. I'm not a great speaker, but I did a UtahJS conference like a couple of years ago, where I basically said, I think Datastar is really good, and like someone proved me wrong. And since then, no one has, if anything, it's gotten I'm I'm much more confident than I was during that talk. And I was like doing real-time stuff at 140 frames per second, like real-time 3D stuff in the browser, and it was fine, and it worked fine. The thing is that if it is seen as an I do want to need to explore, but also there's a good chance that like if it at all became successful in the way that like Tailwind is just the default, I would probably give most of the stuff away. Like, once it's like, oh no, this is paid for the development of the thing, then just give it away from there. I want to be able to support other developers and other things. So the 501c3 really is set up to do that, it's there to help developers in the long run. We just don't have enough to really make that a possibility yet. All right.

SPEAKER_03 52:29

Super dangerous, loaded question, but I feel like I have to ask it at this point. Like, there's no way around it. AI, how do you use it and how does it work with Data Star? Poorly.

SPEAKER_00 52:41

And what I what's been really interesting is Datastar is tiny, right? It is so small that it'll fit in any context window, even the nano ones, even the like the tiny, tiny windows of context. It's so small. And yet when you try to build something with it, most things like the codexes and the clods and the Geminis, they basically say, Cool, I'm gonna start making a React app. The thing is, they're so overfit to the data that they've been trained on that you can make them work with the data star thing, but we actively don't try to hit the like data star is so simple. And the thing is, this is the thing that I think you'll run into, is that you're gonna get to start doing stuff on a page and you're gonna literally say, That's it. And the problem is it's so surgical in where you use it on most pages. A data star site is whatever your framework of their it's a Sinatra site that happens to have some data star on it, like it completely gets out of the way in a way that uh is not the norm. So the LLMs don't help you. You don't need LLM to help make you a website that does data star. It's a non-issue. So the thing is, I think the LLMs in general are faster. Like I'm a pretty fast typer and it types faster than I can. When I say, hey, make this change in 20 places and do this thing with that, like change these text cases to this thing, it's great at that job. It's a good aggregator of information, not has no intelligence. So if it sees patterns, it'll do those patterns. The problem is most of the web is sloppy Next.js garbage. And so it goes to the median. Like when you're talking about a bell curve, it's never gonna make you something innovative or interesting. It's gonna give you the middle of the bell curve. But that's where most projects go to die. There's nothing interesting going on there. Now it depends. If your job is to basically make websites for plumbers, right? Or for like local businesses or like an accounting firm, those jobs are dead. So the thing is, all you're doing is like going towards the median. People are gonna realize they can get that for themselves. Those kind of things are dead. So I always try to work on the outlier things that are interesting. So for me, it's a tool, but I think it also is the death nail of the junior programmer. Like you don't have that time to really explore and learn how to be wrong and get an opinion of things. I don't know what to do for younger people.

SPEAKER_02 54:58

Yeah.

SPEAKER_00 55:00

But again, it's a transformative tool, and yet most of the time, the way it's being used is complete slot. What's interesting is I only use it for things I already know. I have this specific thing I need to change in this way, this pointer needs to change to this, I need to make this area and allocator, check all the usages of this, like that kind of stuff. I like I know what I need to do, I just do it faster. But when people use it to explore things they don't know, I think that's crazy. Like it's never right, ever. So, and the thing is if it's right, it's right in the for the wrong reasons, and that's more dangerous. So I think it really does make you more of the developer you already are. To me, I say it's a scalar on your vector, which it's just like whatever direction and pointing you are, it just amplifies whatever that is. So if you're a lazy developer, you're gonna be lazier. If you're like really hardcore and you want to work on three different projects, you're gonna work on three different projects and you're gonna be able to go faster. So I don't know. I think people have collectively lost their minds. But what else is new? But I think it's one of those things of like there's something beautiful in it, but the beauty is also the horror itself. It's like it's almost impossible to do anything in life without taking someone else down just because of our global economy. It's built off the backs of somebody somewhere, somehow, even if you don't feel it directly. But you have to be aware of that, you have to be cognizant that there's a cost to this. And I don't know what's gonna happen in the next five years, given that it's so heavily subsidized right now, and the debt servicing on these companies is gonna destroy it well before technical breakthrough. So to me, I use it, but also at the same time, if it went away tomorrow, I wouldn't it wouldn't bother me at all. So I don't know what average developer means anymore. Especially lead code is dead, but I also thought lead code was a complete waste of time anyway. Can't disagree with you there. So but the thing is that like lead code now goes away. So what defines a good developer? It's the projects they actually put their effort into. I don't know. Like it's not even a race to the bottom, it's a race towards the middle. And that's the interesting thing. It's not the complete garbage because it wouldn't get popular enough to get into the training data, and it's not the stuff like Datastar, it just doesn't care about. It cares about getting the mean. So it's a race to the middle means that there's gonna be bigger jobs. I'm from the middle of nowhere, Wyoming, and trying to get a single book on was incredibly hard to do, right? Like I had to order out for months to get a book on QBates, you know, that kind of thing. So at the time there was a desert of knowledge where I just did not have access to anything going on, and it feels like now we're in such a flood of information that it's basically the same as a desert. The ocean is a desert from the top surface. Like when you're on a rowboat and when you're in the middle of the desert, it's the same feeling. Like there's nothing around you, you have no access to water, there's nothing there. So the weird thing is we're flooded with information, but it still feels like a desert.

SPEAKER_03 57:48

It's really hard to drink from a fire hose.

SPEAKER_00 57:51

Yeah. Well, and also the thing is that everything you learn right now is useless. Like even the MCP stuff, all of a sudden it's oh no, not that. It's skills, it's this, it's that. You might as well just hold back and keep building stuff in the meantime. Find a use for it if you can, but don't let it keep you up at a night. I think it's the FOMO stuff that's VCs are built around the idea of looking for high amounts of volatility. Venture funds and all that are built around volatility, not around innovation. So you have to know who's pulling the strings of again, we're talking about it, so they succeeded, but there's the one CEO that said not being a developer is now a virtue in this new world. Like the replica, like, but we're talking about it because it's built to build in FOMO and aggression. It is intended to do that. That's the intent. So, like, do you feed into that or you just take a more stoic approach of like embrace that this is what they're trying to do? I don't know.

SPEAKER_03 58:48

I don't know what the right answer is, but I just feels like it's impossible to get away from it, so gotta ask. I also don't know. I'm kind of crowdsourcing how everyone else is using it. What do they think of it? Yeah, I've found some really useful ways to use it in my day job. I've been exploring a ton with it. Like my usage has gone up exponentially in the past couple of months. It's still not doing a lot of code writing for me, it's doing a lot of like validating my thoughts or showing me why something I think might work, might not work, or things like that.

Blockers: Adoption And Discoverability

SPEAKER_00 59:29

I'll tell you right now, I have some stuff going on in the background that's happening right now while we're talking. One of them, for example, is I've been really digging into Odin a lot. I think Odin's a beautiful language, it's basically C fixed for me, which is wonderful. And the thing is that there's some things that kind of suck in that space. Like, for example, they don't have a good HTTP server story, but there are C projects like H2O, which are have a great story. So writing bindings between those things is just a row process. So I have it going off and doing a complete binding generation of that, and it's great at that. Another thing, I think NixOS is this like is way better than Docker at being able to make exactly binary reproducible versions of things. Like NixOS is a really interesting project. But the thing is, the configurations tend to be a bit of a nightmare depending on Wayland and all this other stuff. But giving that to an LLM and saying, hey, I want to be in this state, and it is a reproducible state, and if it ever gets something wrong, I can rip it out and pull it back in. And that kind of thing, it can write configs faster than I can. That's amazing. So it's taking on projects I wouldn't normally do because I wouldn't say, give me all the H2 bindings. Like I just would try to figure out Swig or some other project to try to make that happen because I just wouldn't tackle it. Whereas now I can tackle it because it's all rote stuff that either works or doesn't work. There's no opinions in there, it's just work. Right. That part it's beautiful at, and I see value in it. But the thing is, people are using it to like define my neighbor, is using it to sell their house because they think this other thing's gonna happen and this thing, and like their logic makes literally no sense, but they got it from ChatGPT, and they're literally selling their house and moving because of it. I don't know what to do with that kind of information, right? That is a kind of psychosis. There's gonna be winners and losers in that thing, or I'm just wrong, but then the whole world burns if I'm wrong. So I don't know. Either way, I have to be okay with it.

SPEAKER_03 1:01:21

And it's sort of like when JavaScript frameworks got big, right? There was a new one or a new thing to learn every other day, every week. Feels a lot like that too, just like you said.

SPEAKER_00 1:01:33

I think there's a good chance of the boiling frog again of people don't realize how much they have lost the ability to actually be cognizant and understand what code is doing. Good things are gonna come out of it because it's like you're gonna see the people that are actually really interested in coding. Because coding has kind of become a somewhat of a status thing of like coders get paid well and they get to work remotely and all this stuff. Like the people that actually want to do the work are gonna be the ones that stick around. So it's gonna be a great filter, but I think that that in the long run is a good thing. The VC funding stuff has to the actual financials don't make any sense. So my only hope is that local model generation figures out its own thing. Because I would love to have things that are trained specifically on my code base or the Linux kernel, or like here's how SQLite does things, and like that kind of local training for your own models. I think that long term going forward, people are like, hey, here's my model of how I do things, and here's my thing. Hey, let's collaborate. Like, there's a beautiful future in that, but the VC backed giant models that are burning water sources and rainforests, I think that is an untenable thing. So yeah, there might be some good that comes out of it, but not in the next five years.

SPEAKER_03 1:02:44

Yeah, we'll find out. The next question, because I know we've covered so much in our what are you working on? What kind of blockers do you have? But since Datastar is done, don't really have blockers there. What do you have as a blocker?

SPEAKER_00 1:03:00

So my blockers right now are I want to be done. And the thing is, to me, programming is always a tool for extending your abilities. And my thing is again, it seems like a weird boast until you start actually playing with it, but the web, the JavaScript is done. All the things that you are concerned about are non-issues, and I can't explain that until you try it. So that part's done. The web just being a non-issue is pretty cool. CSS now, to me, with the stellar stuff, is basically done. I have the stellar UI stuff to do, and then I'm going back to working on my database when I have time. I think that's the thing that's really what I got interested in in the first place is like, how do I solve data at large petabyte scales? And that's the project problem that I'm going back to. So my blocker is that I want to help everybody else so I can get back to the thing that I was doing originally. But I think it's a net good because I become such a better developer dealing with other people's intents and like telling people no. I've gotten much better at that. And so my blocker is literally getting back to the thing that I wanted to do, my original intent. But also the problem has changed in my head over time. So kind of like the LLM to make you more what you want to be. The database I would have written before data starting, the data, the one I wrote after it is a very different database. Am I missing one more thing? My blocker is am I on the right road mentally to move forward? Because that's a big project. I mean, obviously, that's a huge project. And the question is, do I have the right mental model and do I need more time thinking about it? So that's probably my only blocker for things moving forward because everything else is kind of rote. Like we are gonna be doing Stellar UI, which is the set of components, and that's just knocking through all the things that are available in Daisy UI or Shadsian or like that's just work. That's not a blocker, that's just stuff to do. So if you would have talked to me a year ago, I would have had a huge list of blockers, but I'm in this excited point where not only am I not blocked, but I think most of the web is not blocked. If they really gave it a try, I think most people would go, that's it, and I can just get back to work. There could be a huge impact. I just don't know how to make that impact. I'm not like a big speaker, I'm not a I don't have any clout in the Twitter verse or anything like that. I really do think if it's not Datastar, it's something that looks very, very similar to Data Star. If someone could make a better version of it, I would love it. That'd be great. But just like the way React felt so good compared to how you did things before, right? Like you felt like, oh, I could make Google Maps. Like you had that feeling when you tried it, like, okay, I get that why this is different. This is such a paranoid, this is even more of a shift than that was to get back to I can't believe how simple this can be. What have we been doing? I just hope that that opens up the doors to the next person that makes something even better than that. I'm looking forward to that. So, but yeah, I guess I do have one blocker. The blocker is I don't know how to reach people without sounding like I'm selling something. Like, sure, I don't want to do the conference talks. I already feel like I've put enough into the open source community. How do people like you not know already know about datastar? I'm gonna be actually talking to Richard Felman, who's the guy behind Rock, and he's done a bunch of things around Elm. And he was like, I just heard about Datastar from this other podcast I did. And I was like, how can you, of all people, like he's like one of the the Elm in Action is like a really great book? And like Datastar is like a condensed version of Elm, but without having any language behind it. Like, you don't even need the language because you have the concepts. And he didn't know about it. And if anyone should know about it, it would be him. How do you reach people without but also not care? I'm at the point where I don't care. I'm not doing it out of any kind of self-glory or anything. I just want to see the web be a better place. What do you do?

SPEAKER_03 1:06:43

Yeah, I got nothing for you. Sorry. That's no, that's a real blocker. That's a real blocker, right? That is a real one, yeah. I'm reeling from discovering it because someone else listened to a podcast episode of mine and was like, why not datastar? And I'm like, the fuck is datastar? Like, that's why not data star. I didn't even know it was a thing. And now I'm like, oh, I've really got to play with this thing.

SPEAKER_00 1:07:04

But the thing is funny is that I'm gonna play devil's advocate, but we have all these SDKs, we have full written guides, we have multiple talks. One of the talks is from David Nolan and his group or that team. To me, David Nolan's the guy who's partially to blame for React being popular because he made a version in ClojuScript that said, Hey, if you do shoot component update and you do things using the closure constructs, you can actually make React really fast. And then all of a sudden, everyone's like, Well, React's really fast. It's like, no, no, no, no, no, no. If you do these specific things, it can be pretty fast. The thing is that people just hop onto these weird Trained. So we have all the SKs, we have guides, we have a bunch of talks, we have success stories. What else can you do?

SPEAKER_03 1:07:45

Yeah, it's just discoverability at that point. You're just talking about not wanting to go and do conference talks, not wanting to be on a lot of podcasts, but like, how else do people find out about the new tech? How else do people find these things? Early in my career, I learned so much about thinking about code and thinking about how I'm building something from listening to podcasts with other people talking about that kind of stuff. And now that I run a podcast, I learn a lot from the people that come on and I ask them a ton of questions. And it's like, but I still struggle to find a guest. I'm like, I don't know who's doing something cool. Like, who wants to come on the show? I don't know. I know like six people.

SPEAKER_00 1:08:27

I'm happy to come on to this. I would like to see this as a journey into getting back to the web. I want to have more of the conversation of not just what I've been up to, but I want to see does this make an impact now that you know about it? Is it just a discoverability of the first step, or is it that it's different enough that people are like, eh, I'm good. We've had quite a few success stories of people taking our stuff and being orders of magnitude faster or less code, or I can send you a bunch of these of being faster, but we've never had anybody that says, I'm going back. So it would be interesting to see, like, for example, from your perspective, of you try the day star way, you come to the Discord, like talk through your ideas, and then say, No, Hotwir's right for me. That to me is more exciting because it's not about us being popular, it's more about what are we missing? Because it feels like we must be missing something because OpenClaw has 240 or 260,000 stars and it's complete garbage. Everyone knows it's garbage, and yet it's more popular than the Linux kernel.

SPEAKER_03 1:09:30

What are we doing as developers that this is you just need to get a bunch of bots to star your repo?

SPEAKER_00 1:09:36

Yeah, I'm just not gonna.

SPEAKER_03 1:09:38

There you go.

SPEAKER_00 1:09:38

I'm just too dumb. That's the problem, is like you know, there's different kinds of intelligence, and that's a kind of like marketing intelligence is I'm not good at so. But what we do need is people like you to say, no, really, we can be better than this, or not, or to say, no, it's good enough. So I'm in a weird spot where I like the size of our community. I can talk to everybody, I know everybody, but also there's so many people that are left to the wayside that don't know about it. It's a weird thing. I had a thing at work, like we have a bunch of projects that are now using Datastar, and it's so much faster, so much better for doing real-time stuff and do even doing normal crud stuff. Like, it's just better in every way. I work here, and it took me years of convincing people to like, hey, why don't we do this instead of React? Why don't we do that? Well, well, maybe for the next project, oh, maybe for this one. And now we have multiple things that are all in flight using it. The code is simpler, everything's simpler, it's faster, and we can work in the language of choice. So I've been actually looking forward to you either falling in love with it or completely denouncing it. Either of those sounds good to me. I'm good with either one. There's no ego there. It's like, please tell me I'm wrong here, and that hot wire and stimulus really is the way forward for Ruby. I would love to hear that because I like what Micah is on one of the people behind Hotwire. And he's done great work in there, but also I just think it's fundamentally flawed. Like the WebSocket thing sounds good, but when you get into the details, it's not good. There's all these things that are specifics that do matter that the average developer doesn't have to care about, but the person developing the framework does have to care about. So but yeah, I think it's just a death from a thousand cuts in the hot wire and stimulus. Can't wait to see what you can do when you take that away.

SPEAKER_03 1:11:15

Yeah. I'm very interested to get into the weeds of it and actually feel it either remove a pain point or add a pain point, or how it shifts my mental model when I'm thinking about I'm in the planning stages, I'm got this white board in front of me. I've got to go do the thing. Is datastar helping with that? Is it hurting with that? Do I need such a mental model shift that almost becomes not worth it? Sort of like learning Vim, where it's like, yeah, you'll eventually get faster, but it's gonna hurt.

Rocket Web Components And Stellar Tailwind Alternative

SPEAKER_00 1:11:49

It's actually kind of like the Vim Emacs world, it's kind of Emacs is its own operating system, right? It literally is. It has its like own stack, basically. But so much stuff is built in that you kind of don't have to care unless you really want to get into the weeds. Data star kind of feels like that, that it's such a weird, like it's not the norm. Everything's just built in and you just kind of get things done and you just go about your business. It doesn't have the learning curve that you're used to, other than if you've never done CQRS or any of that stuff. But again, you don't have to do that to do Datastar, but if you embrace it, you'll see how much simpler your life can be. So the Tau definitely explains it out, but please join. Go on that journey because I think that it would be really valuable. And you might even bring on people, other Rubyists that are using data star. We have the guy who does the SDK. There are Rubyists in the community, and it would be interesting to see why they came there as opposed to using like we already have people that came to Datastar from Ruby. Why did they do that? Like they'll probably have more deeper technical reasons than I do. My thing is like I just looked at Hotwire and looked at the details and went, this is doing too much and it's not doing enough at the same time. Which is what I felt with HTMX. HTMX is so much more complicated. Perfect example of this, because if people have done any kind of HTMX stuff, there's HXget. It goes, you give it a URL, it basically goes to that website, gives you back a thing. The problem is that that is easy. You just do HXget, you get your thing, and it updates that part of the page. Great. The problem is that's actually it's easy, but it's not simple. Because what it does is tying HXget to a click event. And it's like, but what if I don't want to be a click? What if I want to be a mouse? Oh, then you need this extra tag. Well, then you need this extra tag, and it becomes tag soup by you actually controlling it, whereas the data star way is much more composable, but you have to learn what those different pieces of those Legos are. So people are like, oh, it's not as simple. It's like, no, it's simpler, it's just not as easy. But the thing is, it's more extendable in a way. So the question to you is more do you like that? The thing is, even if you are have Legos, you can always write a monkey patch helper that like writes that Lego for you, right? Like if you find patterns that you're using, you build up the constructs that you need, not being only allowed to do things like HTMC. The other thing I will say that's very different from people that have tried HTMX or tried the hypermedia first approach in the past. I think one of the things that I completely disagree with on the HTMX side is that everything's basically request replier polling based, and you end up with a thousand routes. Like you end up with so many routes for every little bit of the page. In the data store way, you usually end up with one connected stream and that's it. And you just send commands and posts like you normally would, and that's it. So it's just simpler because you don't need all that stuff. If you do the CQRS style and you keep connected, all that stuff goes away. So it's just simpler in every way, but yeah, it is a different mental model. But I would say join the Discord before you get into trouble. Join it and talk to the people. They will guide you in a way that there's time to go through the pain, right? Like doing the homework by hand makes sense, but you're already a professional developer, you already know Ruby, you don't already know this stuff. So don't go through the pain of saying, How would you do it in Datastar? At least start there and then like then have the conversation, is what I would say.

SPEAKER_03 1:14:58

Okay. Noted. All right. So last question. What's something cool, new, or interesting that you want to share? And I feel like you've mentioned it a few times already. If you want to go that route, you're tailwind killer. But it doesn't have to be that. It can be, I've had people talk about endangered hobbies and cloud brightening and books that I'm now addicted to. Sky's the limit. You pick, but you can tell us whatever you're kind of pumped about.

SPEAKER_00 1:15:25

I think I will talk about the two projects that I think are really are the rest of the answer to self and the web. But I will say I have just got my hands on a 1937 Atlas lathe that I'm in the middle of rebuilding in my shop. And that's really cool. It's cool to work on older equipment. I'm basically updating it to use like modern servo mortars and stuff like that. In the thread making, they only used to have inches, right? Because it's an older model. But I redoing it so that it has an electric gearbox so that it actually can do metric and power feeding and all that. So it's always good as developers to also build things with your hands, I think. Like it does give you a different outlook. So I'll say in my personal life, that's one of the things I'm working on now. But the things to solve the web, I basically have data star, which is done. But in Pro, there is two projects that I think are really changing the game in an interesting way. One of the things that I think is really like that's built into the browsers that people don't know that much about, or it's just a freaking hassle to work with, is Web Components. Web Components are a great idea of encapsulating state for JavaScript, but the interface that you do in them in them is just not fun. And the thing is, ironically, it's a bunch of JavaScript. You'd think something that's built for the web to make it a declarative element would be declarative. That's not how it works. It's just a bunch of classes, and like you have to export classes that extend HTML. Like the way you do it is, I think, a bit of a nightmare. So I have this project called Rocket that's inside of Pro that basically turned web components into declarative syntax. So you write things using Datastar like things, and then it does all the local scoping, does all the right things, automatically imports modules, does all the right things. You can go look at the website. But I think that that's a really exciting project because it's basically, and what's interesting, it is a single plugin in Datastar. So in one plugin in Datastar, which ironically is about the size of Datastar, it's around nine, 10 kilobytes alone. It's completely making web components declarative. And for most web components, that makes it super nice, it's super convenient. And also what's interesting is your components now just become literally template elements. Template element with data dash, rocket dash, and then the name of it, stuff like that. And you set up your props, it has an entire concept of I don't know if you know Zod, like all the validation on schema validation. Like there's TypeScript stuff for doing validation. That does this property have the right value? Is it min max? That kind of JSON schema stuff. So that's built in. It does auto imports of async modules. It does all this stuff out of the box that makes it so nice to write declarative stuff. Like the thing that you're saying, well, I have this really complicated thing that's really hard. eCharts is this amazing JavaScript framework for doing charting, but it is really complicated setup. The Rocket component is like 200 lines, and normally it's like a thousand lines to get started. So like you have 200 lines, you get that done, and you just drop that on any page in any language, and it just works. So it simplifies the things that you have to interact with. It doesn't try to replace a 3js 3D model, but you can get a globe working in 3JS in like 20 lines. You can get a copy-paste button with zero lines of JavaScript. There's all these things that all of a sudden become you're using the knowledge that you learn on Datastar to then extend to doing web components. So I think that's a really neat project. And the other project I did is basically a thing called Stellar. What Stellar does is Tailwind was a great project for when it came out, in that it basically was saying SaaS and less have all these components and stuff, but really you end up making these utility classes, and over time you just add more and more. The way Tailwind was built makes sense at the time because CSS couldn't do very much, right? Like 10 years ago or even eight years ago when it came out. So uh the problem is that you end up with a class soup and it has to iterate through those homes. And then when you're actually sending data, half your data that you're sending down is actually classes. Like if you look at most projects, it's just class soup everywhere. So there's this interesting project for Adam Argyle from Google at the time was doing open props. And open props was like, I think the real value of Tailwind is the idea of the design system, but the interface you do with it is terrible. So what open props was doing is basically saying, here's a design system, all the things that Tailwind gives you, but it's using CSS variables. And the thing is, a lot of times, all the things it did with all the nesting and stuff, you can now do CSS nesting natively. You can do where clauses, you can do these mixes, like there's all these things that are built into the browser now. So the Adam Arngard was doing was saying, hey, you can just use CSS with this nice design system in your CSS and call it a day. The problem is it's his design system. So as soon as you want to do anything interactive or say, hey, I need he has width one through 10, but what if I need 11 or 12? Now I'm hand rolling it. Now I'm like, it's a good starting place, but now you're starting to do stuff by hand. I come from a parametric background where doing CAD and CAM where everything's constraint based. So if you change this one variable and it's a multiplication, like on the relationships, right? It's all about so Stellar CSS is taking the idea of open props times a thousand and basically making every single thing in the entire project parametric in its nature. So you say, This is my size when it's a min, this is my max, this is the way that the multipliers work, and you just play around with the editor and it's live updating the UI elements on the fly. So we have a video that came out that I can send you a link to, but the idea is that you're basically making it completely dynamic. As you make so it'd be the equivalent of like in Tailwind, if you're changing your config, imagine if it was real-time updating your website live as you were changing your editor. Like, so it's not only like you make a couple tweaks saying, hey, I want steps one through 20, and I want them to be on this kind of shift and this kind of hue colors thing, and it automatically updated your site live because again, it's all data star under the hood. So it can live update your page. Now all of a sudden, because it's collaborative first, means that you could share that site with someone else and actually be with a client playing with the CSS live, editing your updates, and now sharing and being on the same page across everything. So it's basically collaborative design elements on the fly.

SPEAKER_01 1:21:28

Nice.

SPEAKER_00 1:21:29

It's a really interesting project, and it's one of those things. I'll send you a link so you can look at the video and then we can have our discussion. I feel like it's one of those things it's almost better to come from you trying to explain it to an audience than me. I'm too deep in it. It's hard for me to explain. Yeah, yeah, yeah, yeah, yeah. I get that. I'm doing a bad job at explaining it, but it's really, really neat in that even if you did all of the like in its default position, I think it creates like 1200 variables for you. Like it does all kinds of crazy stuff. But the thing is it ends up being like 12k, and it's a one-time cost ever. And now those are available to your site and it's cached and it's easily available, and you can always trim it down from there. But there's something beautiful about like, here's my design system, and now I'm using CSS as CSS was intended with all the container queries and all, because a lot of things with the container queries in Tailwind, it gets so confusing, and it to me it's almost like a write-only thing where you write it out, you're like, cool, this works. And if you make a change, you almost start over and you start writing it again. Whereas this style, you're actually using CSS as intended with its nesting and its semantic styles and stuff. So there's almost nothing that gets sent on the page. You know how if you do Tailwind typography, you get nice styles out of the box. You're like, cool, I get my nice thing, and I just do semantic stuff like markdown or something in in there. Imagine if your entire website worked that way. So that's what I'm moving towards. We just did the first initial release. I'm about to do 0.02. It probably will come out today or tomorrow. But yeah, I'm I'm excited about that, and I'm excited for you to try it and see what you think.

SPEAKER_03 1:22:55

Yeah, I'm excited to give it a try too. And and especially Data Star. It is one of the things that we're like Well, it seems like it could be. In some ways, it feels very different, in some ways it's like, oh yeah, it's like going back and building your very simple website that can actually do shit.

SPEAKER_00 1:23:11

Imagine doing shit, but also being real-time collaborative out of the box. One of the things that was really like we had someone from the HTMX community come in and he does a lot of stuff with HTMX, and his hello world in Datastar was building Google Wave. That was his hello world. He just built it from screen. Like he's like, oh, I'm just gonna keep going with this because he's basically building a chat app is maybe 15-20 minutes. Wow. A hello world is a full reactive chat app. The hey equivalent stuff, like you could do something like that in minutes. So the question is like, if that's a hello world, what does like an actual product look like? I can't wait for you to join the community and like start. Someone needs to tell me I'm wrong because it's no way that I can be right for this long. That feels weird in tech, right? Like to be like someone proved me wrong, bro, and like no JavaScript framework author will wants to compete with it, kind of thing.

SPEAKER_03 1:24:06

It's a weird thing. Yeah, challenge accepted. I will definitely be putting it. What's your project?

SPEAKER_00 1:24:11

What are you gonna what are you what are you gonna what are you gonna build?

SPEAKER_03 1:24:13

To get my feet wet, I'm gonna do a to-do app because that's what everyone does. But there's a few painful parts of our app at work that lean on React because they are very reactive. It's extremely the client does stuff and they need to see immediate feedback and that round trip that you need for doing it the hot wire way, isn't the level of fidelity isn't quite there, but React solves that for us with the way that we have it, but no one likes working on it because it's fucking React. And I just kind of have this feeling that Datastar will be an excellent replacement for it. So I might take that.

SPEAKER_00 1:24:55

Do you already have an event bus kind of for your system? Like, is that already built in? Sort of, sort of, okay, sort of, yeah. The thing is, we have literally a to-do MVC as part of our built-in stuff. I'm happy to send you that code or work through it with you of like explaining because it's in Go, but the ideas of like the actual update and like how it works is very different than most to-do apps. Like when you have time, let's go through it and I can show you the Go code and show you how it works on the site. And like let's have a conversation about it because I think you might go, oh, because it's in Go, which is not the most terse language, it's like a hundred lines of code.

SPEAKER_01 1:25:31

Okay.

SPEAKER_00 1:25:31

So the entire to-do, like the to-do MVC is a hundred lines-ish. It's called in Go. It's just simpler because once you look at it, because basically, for a to-do app, you basically have in that version, you get the main page, you get kind of the skeleton of the page that also has the rendered contents of the to-do app. And then in there it's a data init and then an at get, which basically says to a slash update. So it goes to that same endpoint and gets the slash updates. So now you have a direct connection. So everything else is just a command to like do this, do that, do this. That one connection is the only thing that stays open, and then as it updates the changes, it then sent back directly. So it doesn't matter if you change it from there or from the event bus or from disk. If you make a change to the disk automatically, like all this stuff happens natively. So I might need to show you that because I think it might you might be able to be a Rosetta Stone of Delaney's crazy pointing, like for people that are listening.

SPEAKER_03 1:26:25

I'm just pointing into the sky. It's that always sunny in Philadelphia meme where the one character Charlie's like pointing at the board and like he looks completely crazy.

What Drew Will Build Next

SPEAKER_00 1:26:36

But he's making sense, yeah. And then what's funny is like who is this person? Like, they've all been looking for their mail the whole time. Like, there is no conspiracy, everyone's been waiting on their mail. So that's what it's gonna kind of feel like is that I'm gonna do all this pointing, and you're gonna go like, okay, so I just have to set up an event stream and subscribe to one thing in one place. That's it, yeah. Yeah, yeah. There's no conspiracy here, there's no grand conspiracy. Mac was right, that's a hundred percent the thing. Okay, yeah. So, yeah, we'll probably should do that offline, but I think you're gonna be shocked. I know actually, what would be really interesting is I would love to take the to-do one that we have on the website, because it's go, is a verbose language, and say, can we get this under X amount of lines in the Ruby style or the Rails style? Like, how small is a to-do NBC in Datastar? Because I think you could play some code golf there and be kind of shocked at how small it can be.

SPEAKER_03 1:27:34

Okay. Yeah, I like code golf, especially in Ruby. Awesome. Yeah, well, I mean, hey, thanks for coming on the show and talking about Datastar and like going through everything. It's pretty exciting project. I'm really pumped to check it out and actually play with it because I think that will be the big difference between like, wow, conceptually this sounds awesome, but what does it actually feel like? That's the part I'm very much looking forward to now.

SPEAKER_00 1:27:59

Well, and I'm looking forward to seeing where there's no reason why we aren't bigger in the Ruby community. There's literally like no technical reason why we aren't. So I can't wait for you to show us what we're missing, or like you become a cultist and now you're spreading the good word. Or we'll get you your white shirt and the black tie and a book of data stuff.

SPEAKER_03 1:28:19

I've listened I already am a cultist for Dungeon Crawler Carl. I don't know if I can take on a couple of things.

SPEAKER_00 1:28:23

You too? Okay, dude. The thing I haven't read the new one's coming out pretty soon. It's kind of going off the rails a little bit, but I have to say it's so good. Have you done The Wandering Inn?

SPEAKER_01 1:28:34

No.

SPEAKER_00 1:28:35

You are a Dungeon Crawler fan, but you don't know about The Wandering Inn. No. The Wandering Inn is the longest book series ever written, and it's by some young gal, and it has more words, I think, than Stephen King and the Oh, Terry Pratchett? Uh, Flatlighter? Yeah, yeah. She's written more than Terry Pratchett and Stephen King, and she's like now in her 30s. It's amazing. Oh shit. It's like the audiobooks are way behind, and it's on book like 17, and each book is like 60 hours. The first book, so I will say, you know how for Dungeon Carl Carl, the first one, it's good, but it's a slow burn, and then it gets it starts going. Sure. Read the first book of Wandering In, and then tell me you don't love it. You gotta do the full whole book. At first, you're like, they drop the girl in like an RPG world kind of thing. Sure, it loves me.

SPEAKER_01 1:29:22

Yeah.

SPEAKER_00 1:29:22

Yeah. But the thing is, by the end of the book, if you're not like, oh, okay, this is not the book I thought it was. Let me know because yeah. If you like Carl, you you should like that.

Book Talk And Closing Goodbye

SPEAKER_03 1:29:32

I love me, Dungeon Crawler Carl. Everyone at work is sick of me talking about Dungeon Crawler Carl.

unknown 1:29:37

Yeah.

SPEAKER_03 1:29:38

My wife. Is sick of me talking about Dungeon Crawler Carl.

SPEAKER_00 1:29:42

See, that's where we just I just don't tell anybody about it. Um Team Donuts, so donut holes or Princess Posse? Depends on which talk show I'm on. Okay, fair, fair.

SPEAKER_03 1:29:56

Very nice.

SPEAKER_00 1:29:57

Try to play the audience, so okay.

SPEAKER_03 1:29:59

Alright, good.

SPEAKER_00 1:30:00

I do like the fish people. I forget what they called.

SPEAKER_03 1:30:02

The quietine.

SPEAKER_00 1:30:03

Yeah, cuitine. That's it. Yeah. I thought the whole thing was kind of interesting. So I don't know where it's gonna go from here, though. It's every one of them. It gets more and more chaotic, and I love it.

SPEAKER_03 1:30:13

Yeah, I feel like they need like a respite of some kind because it's gotten a little kooky. I mean, it's it's ramping up because I mean Matt Dinneman, the author, has said he wants to do 10 books. Eight is about to happen. Yeah.

SPEAKER_00 1:30:26

So he's running out of space to finish which have you read his the one he did before he did Dungeon Curl Card? The kaiju uh Battlefield Surgeon, yeah.

SPEAKER_03 1:30:37

Yeah, that was it. It's not finished. I'm wrapping up Operation Bounce House's newest book.

SPEAKER_00 1:30:43

So yeah, that book is a rough read. It's better by the end. So it's another one of those kind of like wandering in. Like if you don't get to the end and go, Battlefield Surgeon is a tough read, but at the same time, like you get to the end and go, okay, that was a well-written book. I feel like that's the way Wandering Inn is. By the time you get to the first book, if you're not like, okay, this has a voice. Nice. Um, so yeah, highly recommend. It's funny. We'll talk more about this for the next two hours or two.

SPEAKER_03 1:31:07

Yeah, just don't get me started on what I just did. Yeah, oh boy. Okay, we're gonna cut it off here then, because otherwise, this will become my longest episode ever. Again, seriously, thank you for coming on and talking about it. Excited for giving it a try. And once I do play with it, can totally have you back on and have a completely different context for the conversation. And if anybody listening is interested in trying, I'll have links to the Discord and links to the guides. So you've got a good ingress into exploring this brave new world of Data Star. And Delaney, thanks for coming on.

SPEAKER_00 1:31:45

Hey, thank you. This is a blast. I can't wait to see either that I'm right or wrong. Either way is gonna be great. So I'm gonna be great. Either way, I want to come on and tell me how bad it is. That would be almost more fun.

SPEAKER_03 1:31:56

So almost. We'll find out. All right, everyone. Yeah, I'll see you all in the next episode. All right, bye.