You love building web apps with Python, and HTMX got you excited about the hypermedia approach. Let the server drive the HTML, skip the JavaScript build step, keep things simple, right? But then you hit that last 10%. You need AlpineJS for interactivity, or your state gets out of sync, and suddenly you're juggling two unrelated libraries that weren't really designed to work
together. What if there was a single 11-kilobyte framework that gave you everything HTMX and AlpineJS did, and more with real-time updates, multiplayer collaboration out of the box, and performance so fast, you're actually bottlenecked by your monitor's refresh rate.
That's Datastar. On this episode, I sit down with its creator, Delany Galan, core maintainer, Ben Crocker, and Datastar convert, Chris May, to help explore how this backend-driven, service-sent event-first framework is changing the way full-stack developers think about the modern web. This is Talk Python To Me, episode 537, recorded January 15th, 2026. Welcome to Talk Python To Me, the number one Python podcast for developers and data scientists. This is your host, Michael Kennedy.
I'm a PSF fellow who's been coding for over 25 years. Let's connect on social media. You'll find me and Talk Python on Mastodon, BlueSky, and X. The social links are all in your show notes. You can find over 10 years of past episodes at talkpython.fm. And if you want to be part of the show, you can join our recording live streams. That's right. We live stream the raw uncut version of each episode on YouTube. Just visit talkpython.fm/youtube to see the schedule of upcoming events.
Be sure to subscribe there and press the bell so you'll get notified anytime we're recording. This episode is brought to you by Sentry. Don't let those errors go unnoticed. Use Sentry like we do here at Talk Python. Sign up at talkpython.fm/sentry. And it's brought to you by CommandBook, a native macOS app that I built that gives long-running terminal commands a permanent home. No more juggling six terminal tabs every morning.
Carefully craft a command once, run it forever with auto restart, URL detection, and a full CLI. Download it for free at talkpython.fm/command book app. Ben, Delaney, Chris, welcome to you all. Thanks for being here on Talk Python To Me. Thanks for having us. Hey, how are you doing? Doing well, doing well. Very excited to talk about Datastar and some cool web frameworks for Python people and beyond, of course. But, you know, most people listening doing Python web frameworks.
So talk about how that all integrates. And if you like the HTMX vibe, which we've talked a lot about on the show, I think there's going to be a lot to like here as well. And maybe more. We'll see. A case to be made. But, you know, before we get into all of that, though, let's just talk about a quick introduction for everyone here and like go around the squares of Ben, I'll let you go first. Who are you, Ben?
Based in Costa Rica at the moment. I'm based in Europe most of the year, but half of the year my wife and I spend here. In terms of background, I've been primarily working with PHP for well over 20 years and got involved with Delaney and Datastar, been a core maintainer on that project ever since. And I looked at my commit history for last year, and it turns out now I write more Go code than PHP, so I don't want to call myself a PHP developer anymore.
I'm just a web developer, a backend web developer, primarily that also writes TypeScript and maintains a front end.
framework. There's a lot of stuff going on and ways in which you can write code for the web these days. Well, thanks. Awesome to have you here. Delaney, hello.
Hi, how you doing? Yeah, I have kind of a weird checkered background into web development. I was originally in the circus, then I became a 3D artist, then I became an engineer. I've worked in games, video games, slot machines, military applications, all kinds of crazy things. I tend to work on really highly optimized, fast things. I love the ideas of the web, but I got really tired of how you actually implement things in that.
And I was doing very large applications with millions of updates a second. And the tools that were out there just weren't good enough. So I ended up going down many, many rabbit holes and finally found something to make it better for everybody else.
So yeah, that's really cool. And wow, what a really interesting issue. I know you got some crazy stories.
Yes, I do. I always have a funny, weird outcome of something. Ironically, people talk about things being a circus, but like circuses are very well run logistic machines compared to most developer situations. So it's kind of funny.
Yeah, it's an insult to circuses. Yes, it is.
It really is.
Amazing. Okay. And what we're going to talk about, Datastar has this amazing ability to update many things really quickly in real time, which we'll get into, but yeah, sort of foreshadowing there. And Chris May, welcome to the show. I've known you for a long time and I'm really happy to have you here. Great to be here. Thank you so much.
Yeah. Yeah. So about me, I started writing websites back in 1995 and then picked up Python about 10 or so years later and just have really enjoyed the ride since then. Picked along the way, became technical coach and just loved making single page applications. I loved, I just love the web. You know, I love that we can publish something from our computer and anybody around the world can see it. And then what, maybe a little over a year ago, I, oh no, it was more than that.
I remember I was on a trip and I was listening to a podcast of HXPod, the HTMX podcast, and heard about this crazy, cool tool, Datastar. And I was like, I even put in my DjangoCon presentation, like you should, everybody else should try it out. And finally I did and I'm converted. I love it. So I'm excited that the three of us get to talk about it.
The reason that we're having this podcast is because I read your article about switching to Datastar. And I'm like, okay, this is interesting. You made the case very well. Of course, I'll link to the article. And so I thought, hey, I need to have Chris here as my Tony Romo to my Al Michaels or Nico Rosberg to my Crofty or whatever, right? So I'm happy to have you here.
Exactly. Awesome to have you here. So let's just start with what is Datastar, right? I mean, we've hinted that it has some similarities to htmx but also not so ben and delaney give us the overview what is datastar so i can give a little bit of history and then ben's probably better at
saying what it is now i have a background in like low-level stuff um even though i was a 3d artist first i'm much more comfortable in like shader development and that kind of thing like so glsl web thing like i'm a c guy that knows some other things but the thing is that i was working on some military applications where I needed really fast updates of a browser. And the reason why you in this military situation is that getting things approved is really hard, like executables to go
into deployment. But having a browser means that you have this nice little sandbox that things can go in. So it's actually more of a deployment platform in my background than, you know, just the regular web. But I was doing things that were pushing the browser really, really far. I was using Vue and Spa. And I basically was like, well, these are the smartest people out here, but it's not fast enough. So I was using crazy WebSocket stuff, all this binary stuff. And then I tried doing,
you had someone on last week talking about LiveView and like they have a Python version of that. I went hard in making a binary version of that, like going down to the protocol level, changing, optimizing that 10 different ways. I had an entire framework for doing this. And basically, in my opinion, that's a complete dead end. It is untenable. We can go into the reasons why, but the thing is, long story short, I ended up seeing what was happening in HTMLX in the hyper
media space. And I completely discounted all of that because I said, like, I'm doing low level binary stuff. There's no way this other approach can be faster. And then my thing is always check the metrics, always don't take your assumptions and do the work. And the thing is, there's things that are wrong in the implementation, but there's things that are 100% right in the overall ideas of
how to use that. So I went and I took a year and a half work and just threw it in the trash and said, okay, I'm starting over and like ended up doing some basic things would probably get into and ended up with this thing that is a backend diagnostic backend framework that has a 10 kilobyte shim that is the fastest, smallest thing out there by orders of magnitude. So it's not just a slightly different thing. It is literally a different paradigm shift. It's a crazy shift.
So the difference between reacts to something like HTMX is different from HTMX to the data start way. So I'll let Ben actually explain what that is. But the thing is from a low level C guys point of view, it is one of the fastest things in your stack now, which is crazy to think Yeah, like a 10K shim can do that.
That's incredible. And also, it sounds like your advice comes from somebody who's done a lot of profiling.
Very much so. Like, that's the only thing.
You got to measure, not guess.
Yeah. In fact, there's funny things that we've had things on Twitter fighting with people and they're like, oh, this one situation was really slow. We actually looked at their flangraphs and it was a bug in the Safari GPU stuff. Because we were actually at the level where the JavaScript doesn't even show up. It's actually a GPU issue of it rendering fast stuff. in the browser, nothing to do with the JavaScript. Because the fastest JavaScript you can write is no JavaScript.
So we really lean into what the browser can already do. And we're just making it so that that's easy to do so that the average person with the average website doesn't have to write any JavaScript at all. And they get to be a full stack developer in whatever language they choose. And I'll let everyone else talk from there.
Awesome. Ben? Yeah, my version is going to be quite different to Delaney's because we care about different things. Fortunately, we do care about some of the same things. We work well together because I think we complement each other. But coming from a PHP background, I want the backend to be driving the front end. And it naturally does, right? Because even your HTML is being produced by your backend. And that's what's being served to the front end. I describe Datastar as a hypermedia framework.
And some people get tripped up on what hypermedia is, but it's essentially hypertext with other media like images and CSS and that kind of thing. And everybody should know what hypertext is because it's the H in HTTP and HTML. There is an expectation for people coming into Datastar that you have a basic understanding of the web and web browsers and the web browser API because we lean as heavily as possible on the browser API.
We get a lot of people coming into the Discord asking us, you know, how should I do this the Datastar way? And it got to the point where I'd heard that question so often I decided, OK, I'm going to write a page in the Datastar docs. We call it the tau of datastar. So it's kind of like the way of datastar. And if there's one thing to take from that, it's use as little datastar as possible. Like leverage the browser, because the browser is an incredible thing, right?
Like it's basically an operating system, our operating system as web developers. So, and everything happens at the C level, super optimized. We're not going to be able to build something faster. So leverage the browser as much as possible on the browser APIs. And where HTML kind of lacks or where there are some gaps, that's essentially what Datastar is trying to fill. So I did a lot of work. So just to relate this, I guess, to something that other people might be familiar with, which is HTMLX.
I was an early contributor to HTMLX, actually, and I was sold on the idea of hypermedia from the very beginning. So HTML is the language of the web. Why are we trying to replace it with JavaScript? And the problem that I ran into after several years of thinking HTMX is all I need is that last 10%, right? Because it'll get you 90% of what you're trying to do. But that last 10%, which we all know is the hardest piece that takes the most work, just isn't covered.
So with HTMX, for example, you will very often reach for another library like AlpineJS, or you'll start writing vanilla JS perhaps to fill in those gaps to interactivity to the page, because HTMX is really just going to the back end, replacing the DOM. But now you have two dependencies. Now you have HTMX and Alpine, for example, and you're trying to make those play well together.
And because I think that might be a little bit of the missing sauce from HTMX. I've had Carson Gross on and I really admire HTMX. But as I've worked with it over a couple of years, I feel like it's really good as salt or seasoning, something you sprinkle on to really make a website better. But if you try to make a meal out of salt, you're not going to want to eat it.
And what I mean is, you have three different disjointed parts of the page, and you're like, this is so amazing to update this with HTML and partials, and so is that. But then you start talking about AlpineJS and connecting different things, and then the JavaScript gets out of sync with this server response. And it just, you start to feel constrained by it. And I think you all have a really nice solution.
It's something a little bit like how you, we're going to talk about it, but sort of how you specify the HTML to be updated by the server, but then also connecting different parts of the pages. Chris put it in his article that like the problem is AlpineJS and HTMX are just two unrelated different things that happen to go together a lot. And so they're not cohesive in a sense, right?
Well, and that's one thing that's definitely an issue. Like, for example, this was my thing because I actually tried to fix HTMX back in the day. And like the things that I wanted to fix were the problem that I see at least is that you have HTMX, you can add, it has extensions, so you can add stuff to it. But it fundamentally was built to be like, here's our way of doing it. And then you can do your own stuff on top of it. The problem is, is that I thought that's broken.
I've done enough game development to know that you need to be agile. I need to be able to like be able to move quickly. So I wanted it so that nothing was basically like the core of data star is like 300 lines long. And it is basically setting up data dash star elements, hooking up plugins, and then everything else is a plugin. So if you don't agree with us, or if someone's better than I am, great, that's wonderful. We will be able to just pop that part out, put the new part in.
But plugins can now depend on each other. They can understand. It's an ecosystem. Ironically, that's what happens under the hood. But the ideas of that make it so much more powerful. And the irony is that if you build it in that kind of plugin style way, in the more game developer style way, we are smaller than HTMLX and Alpine alone, let alone combined, let alone Hyperscript and all these other things. So it's just a different way of thinking about the problem.
When I first encountered Datastar and looked at the source code, it looked very foreign to me because Delaney coming from game development, he built Datastar like a game engine. So you have this very thin core and then everything else pretty much is a plugin. And all Datastar core is a way for registering plugins and having Datastar attributes. And that's pretty much it. Everything else is an add-on that you, is a plugin that you can take away.
So we even have a bundler on the site that allows you to just, well, you can just download Datastar core or you can just select what plugins you want. Now, that in and of itself is not that interesting because we're, at the end of the day, we're talking about a 10 kilobyte JavaScript file with all of the plugins. But it is open source, which we didn't mention. And so anybody can go just kind of look at it if you're interested.
But that approach means that everything is modular and everything is there for a reason. And we'll get into this later, I guess. But like deciding what plugins go in and what stay out is one of the challenges. And we just try to keep it as lean as possible. My way of thinking about it is that Datastar gives you everything you need and nothing you don't. And that's how we try to kind of keep it lean and fast.
This portion of Talk Python Maze brought to you by Sentry. I've been using Sentry personally on almost every application and API that I've built for Talk Python and beyond over the last few years. They're a core building block for keeping my infrastructure solid. They should be for yours as well. Here's why. Sentry doesn't just catch errors. It catches all the stuff that makes your app feel broken.
The random slowdown, the freeze you can't reproduce, that bug that only shows up once real users hit it. And when something goes wrong, Sentry gives you the whole chain of events in one place. errors, traces, replays, logs, dots connected. You can see what's led to the issue without digging through five different dashboards.
Seer, Sentry's AI debugging agent, builds on this data, taking the full context, explaining why the issue happened, pointing to the code responsible, drafts a fix, and even flags if your PR is about to introduce a new problem. The workflow stays simple. Something breaks, Sentry alerts you, the dashboard shows you the full context. Seer helps you fix it and catch new issues before they ship. It's totally reasonable to go from an error occurred to fixed in production in
just 10 minutes. I truly appreciate the support that Sentry has given me to help solve my bugs and issues in my apps, especially those tricky ones that only appear in production. I know you will too if you try them out. So get started today with Sentry. Just visit talkpython.fm/sentry and get $100 in Sentry credits. Please use that link. It's in your podcast player show notes. If our code talkpython26, all one word talkpython26 to get $100 in credits. Thank you to Sentry for supporting the show.
Cool. That's a super interesting philosophy to say you should be able to take, even take stuff out of what we're giving you by default, right? Now, before we move on from sort of introducing Datastar, I do want to point out at data-star.dev, which of course I'll link this notes, there's some cool examples on here. You've got a really nice space 2001 sort of theme with Hal and all that, which is great. I like the aesthetic here, which is very fun.
It's got a little bit of a retro gaming feel, which is nice. But what I want to point out is I want to encourage people to go watch your little video. Your video is fun.
It's really fun. This video is all about how Datastar fits in the world of SPAs. And one thing we didn't really mention is that Datastar is a full-fledged SPA replacement. So again, like that last 10%, often people will think, oh, well, I need to go to React or Vue.js or some single page application framework. Whereas we're saying that, no, no, no, Datastar will not only, it's not like a subset or like SPAs are not a superset.
it's on the contrary. I think Datastark, we think Datastark can do more than SBAs because we are driven by the backend and we are focused on hypermedia, which is the language of the web. So this, yeah, so this video is kind of throwing, yeah, anyway, everybody should watch it.
I'd also like to, if you can scroll back up to the top of the page, the Starfield animation was one of the things like when Delaney and when everybody who worked on this published it, Like I didn't realize how amazing this was because if you like right click and inspect that thing, it's a web component. And so all the JavaScript that's required for making all the stars go faster and slower and tracking your mouse where, you know, wherever you do it, it's all within that web component.
And data star is essentially subscribing to like, where's the mouse pointer and passing it into the web component.
Yeah, in fact, if you go to more examples, you will see that there's, and then go scroll down to, or use the hamburger thing. Yeah, go down to the rocket. There's the actual star field. So you can see the entire, the star field, the entire component is there. So if you scroll down from there, you'll see how it actually gets hooked up and the entire component, that's the whole thing, it's right there.
- That's incredible.
- And the thing is if you start moving around, like if you scroll up just a little bit more, so you can see the sliders, you'll see that they're live, everything's, if you move it around, like you move your mouse around the canvas, you'll see everything's live editing, everything's thing. It's the irony of Datastar. And this is the part that I don't think people quite get. And it's not that you're trying to like, we love what Carson has done with HCMS.
We love that all the things they've done, but it does not do everything. It doesn't do enough. It is a library, not a framework. And the thing is, the irony is that Datastar actually has the fastest reactive signal, like reactive signals. We are the fastest thing out there. So it's not just like we did something that's kind of like VDOM, or we are like, we can compete with React. We demolish them with actual numbers.
So we have the fastest morphing strategy and we also have the fastest signals, which means doing these kinds of things. It's just a non-issue. Like this star field thing is 1K. Like it's just these are the kinds of things that are just a non-issue in this if you do things our way.
And you're leaning into the web ecosystem by leveraging web components instead of having to like build, have a build time pipeline to, you know, do all the custom JavaScript. Like once I realized like you can do these things, it just made, it just clicked. And I just make it's I feel like it's so much more fun now to work on the web now that I understand these things.
Let's talk through some of the core examples. I feel like there's some similarities to the example section of the HTMX place. But, you know, HTMX doesn't have a star field, certainly. Best place to start is on the homepage.
Before we get into those examples, just just to kind of take a step back and say, OK, we've mentioned HTMX a few times and we don't we don't even like to compare ourselves to HTMX. but it is a good maybe starting point for some people. We have a hello world example there, if you could find that. Yeah, let's scroll down just a little bit more. Yeah, you got it.
One of the maybe differences between HTMX and Datastar is that Datastar can receive HTML responses, but it also by default, or the recommendation is to use server sent events. So if you hit start there, you're going to see kind of the network response tab, and those are server sent events. And SSE server sent events are an old technology that work just over HTTP. And essentially what happens is that the server holds a connection open to the browser and it's unidirectional.
So you send a request to the server and then the server can stream events back down, which is what you're seeing here. Now, this is obviously a trivial example, right? We're sending one, or we're updating the message one character at a time. But when you see how simple this is, then you can perhaps see potential for this, right? And SSE or service end events have had kind of a renaissance in recent years with all of the LLMs, right? All the chatbots are streaming the responses back to you.
So this type of technology, while it's not old, sorry, it's not new, it's actually been around a long time, has kind of been underused. And Delaney kind of tapped into that and said, well, because I also always thought, well, if I want pure reactivity or true reactivity, I need two-way communication. So I need web sockets.
You need web sockets.
You need binary and all that kind of stuff. Yeah. Yeah. There's problems with those, which we can get into. SSE is much simpler. It works over HTTP 1, 2, and 3. And as you can see, it's just plain text. There is no complicated handshake. If you change the interval to zero and hit start, you're going to see a different type of response, which is, and I don't know if you saw the content type change, but content type now is text HTML.
Oh, intro. Oh, interesting.
Yeah. So this is what HTMLX would do by default. You send back HTML responses, whereas here the content type is text event stream. And this allows you to hold that connection open for as long as you want. It can be open and closed, or it can stay open until the words hello world have been spelled out. Or you can keep it open indefinitely. So we're going to see some more advanced examples where the SSE connection is held open for longer.
So I think wrapping your head around this example taps you into the potential of Datastar.
MARK MANDEL: Yeah. And one of the things that-- well, when I looked at Datastar, I'm like, OK, there's some interesting aspects here. And we'll get into them, how you can set up-- when I click the Start button, it might replace a piece of the page-- hey, that sounds familiar-- with HTML, not through JavaScript, right? but it didn't specify anywhere what part of the page to replace or not. Like, how does it know?
And so with Datastar, you lean more on the server for many things, including deciding what part of the page that the server created in the first place to update. I really like that. I think that that's super neat. It lets you not just have sort of closer to one source of truth, but also just you can pass down multiple things. is like, we need to update this pane on the right, this text, and this element all in one response. There's a lot of interesting aspects to what you're talking about here.
JOHN MCWHORTER: Anyone who's familiar with out-of-band swaps in HTMX, well, guess what? Datastar is out-of-band by default. So it's matching currently based on the ID. So you see h3 id equals message. And every event that's coming back has an ID of message. But guess what? you can use any ID you want, right? So you can use actually any CSS selector you want. But yes, we put the onus more on the backend because that is where we believe state should live or that's the source of truth for state.
And you send and you work with state on the front end only when and where it makes sense to, which is more the web component aspect.
And I'll caveat what Ben said there in that like state mostly lives in the backend. And that's the problem is that like state lives where it lives. Like if the user is actively able to move their mouse cursor, they own that state of the mouse cursor. You don't own that, but most of the state from your database should be in the backend. The one thing that's interesting about the SSE compared to how most people think this stuff, I will say I fell into this trap too, right?
Cause I did the live view crazy stuff is that your job as a web developer is to get strings to the browser as efficiently, as fast as possible.
Cause like the browser is going to deal with that, that into html and all that there's nothing faster than giving it html right so the thing that i i know i lost for a long time is that sse i thought oh it's this big string thing how is that better than binary but the irony is that because it's so regular because there's already things like compression built into the browser there's streaming things there's things that are so
much easier to do here in an efficient way that the irony is if you if you you don't have to care about all these things but if you just follow our way of doing it your python app will be faster than most people's like compiled, you know, like low level language thing because you're getting orders of magnitude in the algorithms and how we're doing stuff from the hood. So I don't know if you're interested in like the deep down stuff or just like how you use it as a Python developer.
But the irony is that you now have tapped into this. It seems so simple. You're like, oh, this is just a different text response. How can this be orders of magnitude faster? Like, again, I don't know how much you want to get into the weeds of that compared to just it's fun to use, right?
Yeah, I really like the philosophy of having so much of it controlled by the server. It just felt disheartening. It's like, okay, so what you're going to do is you're just going to create some JSON responses on your server, and then everything is some crazy build series of steps to end up with, I don't know, Vue or React or something on the front end. And there's just so much power and flexibility to write really cool server code.
But, you know, like a lot of the trends have been, yeah, that's kind of just there to support the rest of it, you know, and so I don't know, this really appeals to me.
question that comes up often is like, OK, well, how do I format this? Because it has its own syntax. Very simple to read, obviously, right? An event name and then these data lines. And you can just have as many data lines as you want. And that's your HTML. If you scroll up, though, we do have... So you do need to format this, but we essentially have all of these SDKs, including Python, you'll see there. And the Python SDK is actually, I would say, one of the most intricate ones we have.
Spatuel King, he's a member of the community, or Chase, I believe is his first name, his real first name, and many other contributors did an amazing job on that. So lots and lots of Python frameworks
are supported. You can maybe speak more to this, Chris. And really, the SDKs are very simple, because all they do is they take a function, a patch elements or patch signals function, and you just dump in the HTML that you want swapped into the DOM or the signals you want output on the page and it just does the formatting for you so so it's really just there's three
functions i think in total that every sdk has to implement and it's such a time saver you know um i doved into service and events a lot with htmx and when you get the syntax wrong it is so painful to debug because pretty much can't it just doesn't work you know or whatever it's harder to debug and so to have the helper syntax it's just a dream well and also just so people are aware i like
because I was originally going to try, the irony is I was trying to get server sent events like their plugin up to snuff like years ago. Like I would highly recommend not using SSE with HTMLX because the problem is that the entire model of how you build things is very poll based and it's built out of band. It's like a weird concept, like the idea of updating, like it is not built with that in mind.
So I know that they're trying to move towards that in the future, but the whole way that you interact with it is based on polling. And the thing about our way is that not only are you doing push events, But the thing is that really does change the semantics of the language. So first of all, you get like 40X compression by doing our way. But also you only send data when you need to instead of polling. So now you're using less resources. You're using less network.
It changes the whole dynamic in a deeper way that you can literally save 5,000X in your network bandwidth. It sounds crazy, but it's just a reality.
Right. Another thing, Delaney, that's really nice about that is the latency. That's something that drives me crazy about polling. general is just like okay well we don't want to hammer the server too hard so let's make this you know one second two second but then it's like well i click this button and then it updates and you're like ah if if something happens on the server it's sent right if it wants to one of the things that
ironically because i do a lot of like go or low level language stuff is that i tend to put a debounce in my server to like five milliseconds so that i get i'm not updating more than you know 200 times a second even on a monitor because the browser actually break after 500 fps so like the interesting thing is not that it's basically data starts no longer the issue in your thing if you are on a low low powered battery device like a mobile on a 3g this is it will just work like it's
stuff that you just don't have to worry about so it does change the semantics of how you build things just so that you're aware because even things like for example built into the htmx they don't do automatic exponential back off. It doesn't have all the verbs. There's caveats there that I would recommend not doing it, honestly, if you're going to do it.
It's crazy that you're talking about going below the monitor refresh rate. You're not going to see it. This is only 120 hertz. 120 times a second. So why would you pull faster than that? That's wild. This portion of Talk Python To Me is brought to you by us. I'm thrilled to announce a brand new app built for developers created by yours truly. It's called Command Book. You know that thing you do every morning?
Open up six terminal tabs, CD into this directory, activate that virtual environment, run the server with --reload. Now, CD somewhere else, start the background worker, another tab for Docker, another one to tail production logs. Every tab just says Python, Python, Python, Docker tail. And you're clicking through them going, which Python was that again? Where my app is running?
Then sometime later, your dev server silently dies because it tried to reload while you're in the middle of a code edit, unmatched brace, a half-written import, or something. Now you're hunting through tabs to figure out which process crashed and how to restart it. My app, CommandBook, gives all of these long-running commands a permanent home. You save a command once, the working directory, the environment, free commands like git pull, and from then on, you just click run.
You can even group commands together to start and stop everything for a project with a single click. It also has what I call Honey Badger Mode, auto restart on crash. So when your dev server goes down mid-reload, Command Book just brings it right back up and does so over and over until the code is fixed. It also detects URLs from your output, so you're never scrolling through thousands of lines of logs just to figure out how to reopen your web app.
And it shows you uptime, memory usage, and all sorts of cool things about your process. The whole thing is a native macOS app. No electron, no Chromium, just 21 megs. And it comes with a full CLI. So anything you've configured in the UI, you can fire off from your terminal with just a single command. Right now it's macOS only, but if there's enough interest, I'll build a Windows version too. So let me know.
Please check it out at talkpython.fm/command book app, download it for free, level up your developer workflow. The link is in your podcast player show notes. That's talkpython.fm/command book. I really hope you enjoy this new app that I built.
Yeah, on the topic of latency and all that, if you go to the examples, there's some we could look at that I think really demonstrate this. Well, maybe start with bad Apple just because we're talking about refresh rates. OK. What's happening is that the back end is streaming down just a bunch of symbols, but it creates this animation. And if you were to open the network tab, you would see it actually would be interesting to see. You probably have to refresh the page just to.
Yeah. And you're going to see updates. That one there. Yeah, if you click that-- This one? Yeah, that's the one. You click Event Stream. There's an Event Stream tab for Event Stream responses. You're going to see these streaming. I don't know what frames per second we have this set to, but you see it streaming past, right? Right. The first time many people see this, this is a surprise that the browser is capable of this. But the browser can stream video, so why can't it stream a bunch of text?
I mean, it's not that big of a leap of faith. But you can see, it looks like it's about every 10, 20 milliseconds.
I think we're doing like 30 frames a second, but again, we can do like, we're doing this on a, basically a free tier server. So like, this is just a non-issue and it's doing all the compression stuff. So if you notice that your update, even though we're doing like full ASCII development at, you know, thousands of characters, your updates are actually not updating that. Like you see how it's transferring, but it's not transferring that much compared to how much it's actually coming out.
I can see we got 1.9 megs for the whole page. Yeah. But do you see next to it? What, what was
actually like the resources so you see the compression well yeah we're probably not seeing it there but in the bottom you'll see two two megabytes have been transferred but 10 megabytes of resources and so that's oh yeah yeah so it's a 5x compression yeah it's going to be much more on the stream i think because it's streaming uh normally you can hover over the size and you'll see the uncompressed but i guess it's changing too fast that's pretty wild and you know
in practical usage, like I have a status screen that I have from my production app at work. And it's just amazing to just constantly be seeing these things update. And I'm doing that by having the database tell my Python code, hey, refresh. I actually ask it to get all the entries from the database and send it down the pipe. And so it's not like I'm doing the optimized thing. I'm doing
the simple thing and I get all these cool things just updating all the time. And it's just such a useful thing, especially for status screens, dashboards, stuff like that.
Speaking of that, go to the DB Mon example. This is one of my favorites because when React first had their first conference, they said, look at what we're doing. We're able to update at a rate that no one else can compete with us in how fast they could update the browser, right? If we actually, yeah, you're still there. So the thing is, if you actually set the FPS to something like
80, whatever. So that is how fast it's coming from the backend to you. So go ahead. Yeah, because we just don't want people blasting the server.
Yeah, you don't want to walk away.
Yeah, but the point is that this is coming. See, we're doing stuff in microseconds on a potato.
Yeah, let me just describe this a little bit for people listening. So it's like a database monitoring table that shows you how many transactions are the database overloads. So it's updating a grid of maybe 10 or 12 databases with five or six elements, and it's doing that in microseconds, 80 times a second.
A lot of people see these examples and they think, well, I'm not building this kind of stuff. And me included. I build crud apps most of the time. And there are plenty of examples here that are just cruddy things. They're kind of the more boring examples. But one example that might be worth looking at is the to-do MVC. And if you can figure out how to open that in split screen.
Okay. What part do you want me to open up in split? Oh, just this, the example. Yeah, so I can do these two and then I can tile them.
How's that? So this is a CRUD app, but what Datastar gives you is the ability to do multiplayer out of the box. And that is like real-time collaborative apps are not easy to do and not easy to scale as well. But as you'll see here, when you have like two sessions open, it's going to be near instant. You're going to basically be observing the latency on your network connection, which is going to be 50 milliseconds to 100, but barely perceivable.
So just to describe to people, we've got this 2D MVC, which allows you to, well, it's like a to-do example, which is required to be a legitimate JavaScript framework. But I've opened it in two tabs and I've used Vivaldi's tile. So these are legitimately two browsers. They just appear to be kind of in the same window. And when I enter stuff into it, it literally looks like they update in
parallel, which is crazy. If you check a few of them, you'll see, You can barely tell which one's updating which. It happens almost instantly.
Yeah, if I look at the other one and I click on one, it feels like that's responding to my click.
I need to correct myself that it is happening instantly because when you click, when you check one of those, it's not, and this is an interesting thing we can get into. We're not doing optimistic updates. It's actually sending a request to the server and the server is simultaneously updating both of your tabs at the same time.
Even if I had just one open, it's still going round trip to the server. That's why it looks like it's simultaneous because it's effectively.
This is a thing that you can, we can talk for like three hours and I will yell at most spa developers because there's this weird thing that because it's easy, people will actively lie to users in the spa world and they'll do optimistic updates, which means I'm going to make it so that I'm making this change. And then if there's a problem, then fix it. Whereas we say you should do indicator saying, I'm trying to make a change to this and then fix it.
Because you don't want, like when you're playing a video game, you can do what's called dead reckoning and you can do some stuff to net rollback code. You can do some clever things to hide latency, but you don't want to hide latency when it comes to like a bank transfer or did I buy that thing or did I get that theater ticket or any of that stuff. Like people just have the wrong mental model of how the web should work.
I'm actually going to send you another thing that this might blow your mind even more because the three of us basically can play. This is an example where all of us could be playing live with each other right now in an active shared state that's been at the top of the Hacker News and again, runs on a potato. I don't know if you just put that in your...
Yeah, let me drop it over. Hold on. I'm going to put it in the other tab.
So right now, don't touch anything. I'm going to actively start. I am purple. I am literally starting to click right now.
All right. So we're looking at a multiplayer game of life here.
I'm seeing that live here. And if you open up that in the other tab, you would actively see the exact same state. So everyone in the world, like if you open that up in the other tab, you cannot get out of sync. It's not faking it in the front end. This is literally sending in. What's even crazier about this, here's the crazy part. It's actually a rendering demo. The guy who wrote it is writing in a scripting language, Clojure, and he's sending down 2,500 divs per frame styled, inline styled.
Now go to your network tab now and look at what's actually, like look at your network tab and you'll see how little data we're actually sending over. even though he's updating 2,500 divs per frame, like if you go to wherever it's updated, yeah, whichever one's the one that's updated, there you go, yeah. So if you look here and look at how much is being sent versus how many is actually, like try to, like, this is just a different paradigm for how you build.
And the thing is, again, not everybody has to care about these low level things, but the thing is, is that once you do this, the idea of CRUD kind of goes away because in our opinion, you go to a multi, you make a multi-page app like you would normally do in HTMX or anything else, but you keep an open stream and you just update whatever's happening in your backend as it's happening. And it simplifies the world.
And what's also interesting is because of how we do compression and all that, you just send your entire page. You don't need like out of band. It doesn't even really make sense because we're so fast that you can just, you as a Python developer, you just give us your entire page and let us deal with it. And we will come up with the fast stuff. So Chris should probably talk a lot more to that because the fat morpher stuff, it's a fundamental change in how you build web apps, I think.
Yeah, yeah. especially the kind of the mental shift of like, because I kept thinking, okay, I need to like send one row at a time. And I actually have one status screen that does that because we use a Firestore, Google's Firestore as our backend for this app. But for some reason, sometimes it just doesn't send every update. And so on another status screen, I actually, you know, query the whole database table or collection and send it down to Pipe.
And because sometimes it doesn't send from Firestore, I get the entire latest state of all the things that are in flight and updated on my screen.
And it just makes things easier. Yeah, it's amazing. Sounds like a good opportunity to subscribe to database query changes. I know some databases you can say, if this query updates, you know, trigger this event and then keep it flowing, like straight from events on the database, straight to your front end. Pretty cool. I do want to go back and just put a little bit of commentary, Delaney. Well, you said optimistic updates.
So one of the things that's really common in JavaScript is I click this thing, it changes. I want to mark it as changed. And then I'm going to tell the server, hey, we made this change. It's very possible the server died, that you're not allowed to make that change or whatever. And then you've got to come back and go actually undo that. That really, you know, there's like a weird. So what you're saying is you don't have to worry about that kind of stuff.
We're a framework, not just a library. The idea is that you have these indicators that not only basically your indicators drive a signal. Like, again, the details don't really matter. But the idea is that you have instantaneous, like within the same frame updates of, hey, I'm going off to do something. Like usually you make a spinner or you say, I'm going to do this to gray out the field or I'm going to do, like there's all kinds of things you can drive.
Because again, the state of what the local stuff is while the change is there, that lives in the client. Like that is part of Datastar. It has all the right tools to make it so that you can disable it or gray it out or say, I'm going to put a spinner next to it. Like you can do all those things. But the thing is you're not lying to your user. That's my whole thing. And people say, well, that's not really a lie. It's like, yes, it is. You're literally lying to people. Like, please stop.
It's a DX issue. The reason why people do it is because it's convenient, not because it's correct.
And again, like you can do optimistic updates. You can do SBA-like things using Datastar. We don't recommend it because Datastar is more than just this tech. It's also like a way of doing things. What I wanted to point out here is that you might imagine that, you know, this is something that when you click edit, it turns it into a form. So you might like load the form into the page, hide the form, and then just do a show hide approach.
But the hypermedia approach is kind of like the REST approach where you can only take the next action at any given time. So if you open the network tab, I just want to kind of walk you through this briefly. If you cancel that, when you hit edit, you will see a network request to the server. And what comes back is that form. So it's real time as in like what you're seeing now is the actual state reflected on the backend. And when you save, you're also going to see the same thing.
You're going to see a network request to the server and it gets the true current state as it has been saved is now all comes back down. So it's like you don't even need optimistic updates most of the time. And when you do use it, it's because you're trying to cover up poor performance. You're favoring perceived performance over true performance.
One of the things I hear a lot is people saying, but it's so much slower. But I think people are used to or think it's much slower than it is because the web, the spa life that we see around us feels so slow. But anytime I've seen people try to lean into just using the network, it's so much faster than you expect.
Well, and also you have so much less our way. Your usage of network can be easily 100x less, which means you have less contention, which means when you do send something, it's there immediately. And also because you're not doing polling with polling, you have to send to the server and the server sends back. If you just send from server when something updates, now you've just halved your RTT, right? Your round trip has just halved.
So you half it and you're doing like a thousand less of something. All of a sudden, things opened up for you in weird ways, right? It's a fundamentally different way of thinking about the problem. Another example that we like to bring up a lot is there was a while back, someone did a million checkbox demo and they had a whole write-up on it, right? And they basically had to take it down because it was just too expensive to run. We have a version that's not just checkboxes, but color checkboxes.
So you can actually make ASCII art and stuff like that. And it's a billion. And it runs on the same server that was running that Game of Life demo. It's on the same server. It's actively, and it's been on top of Hacker News.
It's a $5 VPS as far as I know.
Yeah, it's a $5 one. It runs all these demos all the time, active, top of Hacker News, and it's never gone down.
What's really interesting about that demo is that it becomes a backend optimization challenge, right? You're no longer trying to optimize the front end. You rely on the browser and the browser API to take care of that for you. And now you're doing, I don't know, you're optimizing your database. You're optimizing your queries. I actually threw the link to that in there. Because it's a nice demo to look at when you realize there are a billion of these being stored in a SQLite database somewhere.
So you can scroll anywhere on the board. And it's like a 30,000 by 30,000 something grid because the square root of a billion is some weird number, as it turns out. And obviously this is, or not obviously, but this is multiplayer. So if I was to view this or you were to open a different browser tab, then you would see the exact same thing. The board is the same everywhere. That is crazy.
The one thing that I will say that's hard, I don't know, Chris can really probably speak to this more and it sounds like a weird thing, Like, Datastar ends up in reality being like five or six things on your page, and it just gets out of the way. All of a sudden, like, most Datastar, you're going to get to a point where you try it, and you're like, that's it? Like, you will feel weird about every other approach once you really try it.
Like, just try it, and you will see every other approach is wrong. Like, it's not because I made it. Like, I wish someone would have made this because it just, it's so simple. It feels like cheating in a weird way. That's hard to explain.
it really it's a weird like i don't know what we all were doing i was part of the problem like right like i was like oh well google and everyone facebook and all the other guys have this figured out like this has to be the best approach so that's the weird thing is it's so simple i don't know what like crystal probably it sounds like i'm selling it but it's just i don't know it's weird it's so
exciting it's so amazing and yet it's it's using all these boring technologies and like yeah like i remember i showed my wife this my status board and she's like oh yeah that looks really cool and I'm like, oh yeah, because you don't understand what everything is going on behind it, you know?
Yeah, exactly. It's like, it used to be so complicated. So let's do, we got a little bit of time left. Let's do this. I think it might be fun to talk through kind of some of the attributes and what it looks like, kind of program with this a little bit and then what it looks like on the server. How's that sound?
Would it make sense? Like there's a good example of a kind of a meta framework for Python called Stario, which they just got their V2.
Okay.
Just launched. I don't know if that is a more Python-esque way of doing it. It depends on how you want to.
Let's start with some of the Datastar attributes, and then we could talk about that. How's that sound? Like, just, you know, what does it look like to say to, you know, I want to connect a button to Datastar actions on the back end or wired up and so on? We've talked about a lot about, you know,
the back end driving the front end through patching elements, which is kind of the lower half of what you're looking at. To access that, you need to have a click listener or some sort of event listener to trigger that. And datastar, as the name suggests, uses data-star or asterisk attributes. So these are part of the HTML spec data set. And we just leverage that. And we have a small grammar that you'd find on the reference page with all of the data-attributes.
And data on is just registering an event listener on the current element. So data on colon click is just obviously registering a click event handler on the button. And what's happening is that then Datasar also gives you actions. So that at get is an action to send a get request to the server. You pass in the path, which is slash endpoint there. And then the server takes care of the rest. So what you're seeing is a div underneath with an ID. IDs are obviously unique in HTML, so they're ideal.
And Datastar just uses that fact. And what Datastar is going to do from the backend is it's going to, yeah, just send back down that div with some text content inside of it. And then what Datastar does is it mutates the incoming DOM into the existing DOM. I'm sorry, it morphs. So it uses a morphing strategy. So rather than doing a straight swap, which is what HTMLX does, it will actually morph the incoming HTML into what's currently on the page.
That's kind of what opens up the door to these kind of broad, like where you send the entire document down, but only what changes get swapped in. But in this case, it's more of a fine grained thing. So only that div is going to get swapped out.
And the reason why that morph matters is because you, since you aren't replacing it, things like focus and like where your input is and all that stays the same. So when you, even though you update the whole page, you're actually not actually changing the state and that's really important. So you do declarative development. You just say, I want it to look this way and it just does the right things to do it. It's from a mental ball. It's almost like having the BDOM in the backend.
You just say, here's what I want this page to look like. And it does all the work, but we don't do
BDOM. We don't do any of that stuff. We do the fast thing. So in terms of what your backend would send, if you can just scroll back up, it's that text that you were looking at. Let's look at the raw version because, yeah, so that's the HTML. If you scroll down to the next text, it's a code
field. Yeah. There's a section that has like event, data star, patch elements, and then what the elements are and so on, right? This is like the SSE stream. Yeah. And that would be the raw events
that you would send down. But if you look at the next one where we have a Python example, you would see like, well, how do you do that in Python without actually writing, you know, the raw format out? And that's how you would do it there using the Python SDK. Let's dive in a little bit
to the SDK itself. So I got so many things open. Hold on. We got another link for you. No, I'm kidding. You know what? I'm just going to go. I'm going from the homepage. There we go. There you go. Chris, maybe you could talk us through this. I think before I throw it to you, though, yeah, there's a lot of framework support here. So if you're a Django person, a FastAPI person, even fast HTML, it's interesting, LightSar, Quartz, SanEck, or Starlet.
There's a bunch of different ones here, but maybe just talk us through this, if you'll, Chris.
I'm trying to remember. I'm not as familiar with the example, but as you can see, this one method is, I think, where the magic happens. I'm trying to remember which tool. This is a Quartz. Yeah, the Quartz is the examples in Quartz. So, you know, they first define a route, a home route slash, and it returns HTML and it's just in the string there. Right. And then that. This could be a Ginget or Chameleon or whatever template. Like it's just whatever. It doesn't matter.
But somehow they get it. Yeah. Makes the example easier to see in one go. And obviously you see that it's pulling Datastar from the CDN and then it on the load, it gets it sends a request to the slash updates endpoint. See what comes from that. And so down below that, you have the slash updates endpoint, which has a decorator called data, data star underscore response. And that just does a couple of nice things like sets the HTTP headers and whatnot to be the service and event protocol.
And then what I like to the first line says signals equals await read signals. And so that's another helper that essentially says when I have a request coming in, data star has a specific way of sending the state of the front end to the back end. So the back end can do whatever it needs.
Right. We haven't even talked about signals yet. They're like kind of a data binding set of JavaScript data that loads, you know, reactive data loads on the front end, right?
In some ways, the Alpine JS kind of, I don't want to say equivalent, but it covers similar functionality. And so if you have data on the front end that the backend would like to know, that's an easy way to get it. And then essentially what happens is we get into this loop, this while true loop, and Datastar will just start sending down server sent events in text by using the sse.patchElements function, or I guess it's a method technically.
And all it's doing is sending a string that has the current date time dot now in ISO format down. And then we wait, we sleep for a second, or is it a second? I guess it's a microsecond. I keep forgetting which one. Yeah, that's a millisecond.
No, no, it's second. And sleep is seconds. Sleep is seconds. It takes a float.
So once it sleeps, it sends another server sign event. With this time, it's instead of sending the HTML down, we're sending a signal. So essentially changing, say, you can say, like the JavaScript value or script data onto the front of the page.
Right, right. So it's showing that you can send the HTML and let Datastar patch it, or you can basically from the server set one of these signal things that will be reactive on the front end, right?
Yeah. You said it much better than I did. Thanks. It's a long way of saying it's a clock, right? Yeah.
Also the thing, just for people that aren't used to thinking about this way, especially if you're doing Python, like all a signal is, is instead of saying that here's, I'm setting a variable, you're saying I'm setting a relationship that says like, kind of like in an Excel document when you set a formula for a cell, it's the same idea. You're setting up a relationship saying, when this thing and this thing changes, update this. And it does smart things to do that efficiently.
But the idea is it's a relationship. It's declarative. So kind of like with SQL, you think of SQL as a declarative language, right? You don't care how it creates an index. You just say, create index. Same thing happens here. You just say, hey, I want when this thing changes, this other thing to change. And the problem is that declarativeness is not built into JavaScript. It's not built into the browser, but we just made the web a little bit more declarative. That's all we did, basically.
Right. Declarative is generally pretty good. It's a good way to work. It keeps things simple and lets the underlying system have at it. So a couple of things, well, we still got a little bit of time, but to wrap things up a little bit. Editors. I think having good editor support is really important for adoption. You know, drives me crazy when I go and try to work with JavaScript, CSS, attributes or whatever, and I'm like, they're not here. No help.
So you all have nice extensions and plugins for common editors Python people might use, right?
Yeah, we have VS Code, which you're seeing here, and PHP Storm. Or sorry, I use PHP Storm, but all JetBrains editors. PHP Storm, PyCharm, WebStorm, all of them things. So it's in the JetBrains marketplace, so it'll work for, I believe, all JetBrains IDEs. I believe so.
You also have the AI editors covered. Do we? In the OpenVSX registry, all the ones that have been kicked out from VS Code, this is where they all have to go to get their installs, right? That explains why people requested this from me. Yeah, if you're doing cursor, anti-gravity, windsurf, like all those things, they were all kicked out of the VS Code registry. That's not a complaint. I mean, it's a Microsoft product. They built it. They don't have to build all the other ones.
But that's why they're here, right?
We keep those up to date. We do those ourselves, the SDKs. I mean, Delaney wrote the Go one, I wrote the PHP one, and the rest are just community contributions. We've had contributions to these too, to the IDE extensions. We maintain these primarily. Yeah, and these are great. These just, you know, save on typing, but more importantly, save on making typos. You know, they show you all of the available data attributes.
Maybe Chris can speak more to is that the irony is, though, you won't need that many tags to actually do your work. So it's not like a tailwind thing where you're like, oh, I rely on it to autocomplete. It's just...
Yeah, absolutely. In fact, it's one of those things where I discover more things I can do with Datastar because as I'm typing data dash and I'm like, oh, I didn't actually remember that there's a attribute to do whatever it is. I don't remember. Like, I can't remember at this point. And then I went to the documentation like, oh, check this out. This is so much more I can do. But yeah, I find I love the plugin, but I find I don't use it too much just because I'm not writing as much HTML with it.
While I'm sitting here on this open VSX registry, do you all have advice for making Datastar work well with agentic AI and Claude Code, Cursor, et cetera?
There's some active research going on like in Oslo at a college that's doing, ironically, using Datastar to do some stuff around like how LLMs work with code bases. And the reason why is because the entire code base fits in basically every context, even the nano ones, like the entire code base fits there. And what they found, we've gone back and forth a bit, is that almost all of them are completely overfitted. So if you just want to make a website with agentic stuff, go do React,
because that's what it's built for. And it's overfitted to such a degree that if you try to use the spec correctly and to say, here's all the sorts of data star, go use it to build websites, it will fall over almost in every regard. So it's one of those things where you don't need that much, but it will ironically show you how bad things like Clawed and Codex and stuff are at just using the current context to solve things.
Hopefully that gets better, but we have something around, like we have a slash docs page that you can feed into your LLM, but I'll say that we do not focus on that at all because you're basically fighting against what the training already happened. So you're better off, like if you want to use, if you want to make better size, you want to be fast and efficient and all that stuff, we're 100% the right thing to do. If you just want to like one shot something, go use React and stay in that world.
You want to vibe code it? Hey, I've got something. I feel like this might resonate with you, Delaney, especially the way you just described it. Have you all seen the Kai Lintit Senior Engineer Tries Vibe Coding? This is an amazing video. And like half of the video is like, no, no, no, not in being installed. What are you doing? It reminds me very much of like, it's just like, nope, that's not what I told you to do. I know that's what you think the most common thing is, please stop.
Yeah. And the thing is that it's not that I actually like a lot of the stuff, but I treat it as an autocomplete or like it can write code faster than I can when it comes to like, hey, change this in 27 different places. And I forget which files I did it like. There's value to it, but people are trying to use it to learn. It's a complete, it actively is working against you. Ben has done an amazing job with the guide.
Like, please, like, it's fine to use the LLMs to help, like, guide your process and to, like, knock stuff out quickly once you have a baseline. But you have to know when to say no. And he has done it. The guide takes half an hour, less than a half, like, probably 15, 20 minutes to read and then, like, an hour to actually work through. Please try it first before you try to throw it at the LLMs. It's not because I hate them.
It's more that they are just overfit to the, like, the sea of badly written SPA code. That's, unfortunately, that's the situation we're in.
Yeah, especially with JavaScript, the agentic AI is very trained. It wants what it wants. All right. Let's talk, speaking of being near the guy, if I go over here to more, there's a pro section. I'll let you all give a shout out to pro. I know you have a really strong sales pitch here. You were talking about earlier. Now, what is this data, Datastar Pro?
It's been about a year since we released the beta one of Datastar. We are taking our sweet ass time for a very good reason, which is that we want version one to be the last version or like the last major version. We don't really want to force people through breaking changes and major updates because that's really just a pain. And I think like Python has done a great job with that and Go as well. And like there are some ecosystems where you just don't make breaking changes.
That's the norm. And that's what we want to be. And the JavaScript ecosystem is, you know, the antithesis to that.
They're like, here, hold my beer. I'll show you breaking changes. Yeah. Have you heard of LeftPad?
To give you an idea of how far we take that, we don't have npm. Like we don't actually even submit to npm. We have no package.json in our JavaScript framework. We actually, like, there's none of that stuff. It does not exist in our ecosystem. So we take it very seriously when we say it's funny to have a JavaScript framework that actively hates the JavaScript ecosystem.
And you guys, I think also it's worth pointing out that you don't have a strong build step, tree shaking, web packing story, right? You just dropped-
No, we do. The thing is that, like for example, beat is kind of the well-known way to do this stuff. But guess what? Under the hood, it uses ES build. And ES build is a go thing. We build a lot of our stuff in go. So it's literally embedded in our, like we just use the ES build directly. We don't need 20,000 things from npm. We just use the go tools inside of our binary because that's the fast thing to do. So we don't need all of that.
So we have no dependencies, nothing, and we don't even use npm or any of that at all.
Yeah, so the reason I mentioned the beta is during the beta phase, which lasted about six months, we, Datastar gained a lot of traction, a lot of interest, and people had a lot of requests. And we were like, yeah, we see, and because it's plugin-based, you can always just add another plugin. You can add it yourself, or we can build a plugin and add it to Datastar. But we were very adamant about keeping the open source Datastar framework as tight as possible.
Like I said, it should do everything you need, but nothing you don't. So how do we do that while adding plugins? So during that beta phase, we started thinking about, well, do we have multiple versions of Datastar? Do we have a marketplace of plugins? Or how do we manage that? And at the same time, we were also asking ourselves, because Delaney and I both, we have full-time things that we're doing.
And this is a side project, but we're almost doing it full time alongside our other full time things. So how do we make this project sustainable? Because it doesn't stop at Datastar. You probably see Rocket and Stellar CSS on that page in the navigation sidebar. Those are like projects that build on top of Datastar. So Datastar is just the foundation. And Rocket kind of takes it to web components and Stellar CSS is a CSS framework that builds on top of these concepts.
So we're trying to fix not only JavaScript web components, but also CSS. So we have a long-term vision. How do we make that sustainable when we're both busy people anyway, and this just takes so much of our time and the project appears to be growing? So at that point, we decided, well, how do we want to even run this? So we decided we don't want to found some company and do VC like we're, if anything, anti-VC funding.
So we founded a nonprofit organization in the U.S. called Star Federation, and that's what backs this project, including Rocket and Stellar CSS. To help fund that organization, we decided let's have Datastar be the open source framework, but then something called Datastar Pro, which is like all those plugins that we think are good ideas, but that most people don't need. We'll put those into Datastar Pro, and that can kind of grow over time.
It's a collection of plugins that you might want if you're using Datastar in a professional setting. But, you know, if you're just using Datastar, you don't actually need it. And so that's what we tell people. Most people don't need it. It's a collection of plugins and it's a Datastar inspector, which sits on your page. You get access to the bundler and now you get access to Rocket and StadrCSS, which is a work in progress. Yeah, that was, I think, a good decision.
Like there was definitely some uproar initially that, you know, some plugins were taken away, but those plugins were never taken away. They still exist in the repo if anybody needs them. What the result is, is that we have like some money coming into a bank account, which is not even used to pay maintainers. We use that for running costs and like for, you know, podcasting software. And if we need to travel to conferences, which we've yet to do.
But essentially, it's like a way of having some money into the bank so that we can justify all of the work that we do in maintaining Datastar and pushing that forward.
But the V1 thing. 100% free sounds great until that means it becomes abandoned where, you know, and like people can't work on it anymore. And I think it's fair.
There's one thing that's kind of interesting about the model, because especially with the tailwind stuff that's been going on lately. One of the things that we talked about, and people get very angry about this, but for example, Rocket is a web component layer that you basically just write Datastar in a declarative way, and it dynamically generates web components for you on the fly. And it's a great way to build web components. It'll save you tons of hours. And people won't pay for features.
They pay for convenience. So the thing is, people said, well, I want you to generate out the content and make that open and available. And we said no, because basically the way we look at it is that almost like Pico 8, or any kind of game engine, you pay for the game and then all the mods are free. So all the rocket components and all this stuff is gonna be free, but the core engine is not free. It's a paid thing.
And the reason why is if it becomes successful, if we do our job and we make it so it's easy for everybody, the Star Federation will do better over time. Whereas Tailwind's model of they're competing against every other person in that space, whereas it just does not work. So our thing is if we do get successful and we do get more people, then it's self-sustaining as in you paid for this little engine and now you get all the ecosystem around it of open source.
So you can do open source in a way, but you have to find a core engine that is not open source. Otherwise it will fail in the modern world.
Let's close this thing out with two super quick things because I know we're over time. Roadmap. Ben, you talked about taking your sweet time to 1.0. Is there a forward-looking roadmap? Are you guys done or what are things?
The release counted RC1, I think it was about six months ago. and like the release has just been slowing down, slowing down. So that stagnation in like just releases with fixes is a good sign to me that we're very, very close. At this point, like the switch from release candidate to stable is just literally like just, you know, dropping the RC. There's no like features that are going into it. There's no big changes.
We're taking our time because like I said, it's easy to put something up slightly prematurely and get some defaults wrong. I mean, that's what happened with HMX 2 was just like fixing some defaults that they decided they got wrong in version one. So we're trying to avoid a situation like that. And the only way to do that is to just let it simmer, let people use it, let people dog food it.
And us, too, we're actively using for many projects using data ourselves and discovering every now and then, oh, this default is probably we're trying to avoid foot guns. So we're trying to make it so that the defaults give you the best possible experience that you need zero configuration, ideally, but you can configure as needed. But getting those defaults right is really the only thing stopping us from, not right, but locked down is the only thing stopping us from a V1 stable.
I don't like to give timelines. In fact, it's one of our things that I tell Delaney, never promise a timeline. But I could see us in the first half of this year, just flipping the switch.
But it sounds like you might be able to use the RC and you might more or less be safe, yeah.
In fact, we recommend people rename the RC and they change the name to React-Foo so that they just drop it in their React projects because the entire framework is smaller than most components. Just start hiding it places. Yeah, don't even name it Datastar.
A stealth takeover of the spa world. Awesome. I love it. All right, let's wrap up the show with a final call to action for people who want to use Datastar, learn more, get started. Chris, I'll let you go first so Ben and Delaney can have the final word.
The first thing I was thinking of is because I get asked so much about how long it takes to connect to the server and things like that, there is a portion in the DjangoCon talk I gave in, I think it was 2023, where I showed a video of five phones, five Android phones, trying to do the same thing, shopping for eggs, I believe it was. And essentially one of them is an HTML driven multi-page app and it smokes the single page applications, the native apps and everything.
And so I put a link in our chat. Maybe you'll be a part of the show notes. It's a deep link to go straight to that portion of the talk because it is like that video reminded me like, this is what I want to build. I want to build websites that are fun for people to use. And, you know, Datastar enables me to use real-time interactions with way less complexity than I ever thought possible. So I guess the two things I would say is, one, check out the deep link if you're at all
interested. And number two, definitely try out something, you know, just even clone the Python repo and just try some of the examples and see what it's like. Yeah, I'll definitely link to that. Cool. Thanks, Ben.
I also gave a conference talk last year. There's a recording, so I'll send you the link to that, which really walks through my journey of Datastar and how Datastar has truly opened my eyes to what's possible. I feel like I talk a lot about how Datastar is a journey of unlearning old and bad patterns, deeply rooted ones in what I think web development is.
And these days, as I mentioned, I never would have thought that I'd be developing in Go, but I see like all like the, like I think even Python is getting better concurrency support, right? So I think you talked about that recently, Michael, here. So now I'm seeing with Datastar, I can do so much more on the backend. I can be so much more creative on the backend and that's what interests me. So it's just fun. What can I say? It's fun.
I'm still really jealous of that presentation too. Well done with it.
Yeah, certainly send me the link. I'll put it in the show notes and well done. Delaney.
The irony is that like, I don't consider myself a web dev at all. It just happens to be something I do a little bit of. The thing that is the, when I first started making this public, I was like, Hey, I think I'm onto something like someone proved me wrong. I was, I'm a little bit more like kind of, I always say like in the jujitsu world type stuff, like you want someone to roll with you, not because you're trying to up them.
It's that like, they're trying to help you find weaknesses in your game. Right. So I want there to be an active, like someone proved me wrong. And I'm at the point now where I feel so confident. I will put money on it. I've tried going out to people out in the dev Twitter and all that. I guarantee you, and I'm happy to put money up on this, if you could do it the Datastar way, whether you're using React or HTMLX or any other approach, it will be less code. It'll be faster. It'll be cheaper.
And it'll be simpler to understand. I will take up anybody anywhere on that thing. Basically, it's not a boast. It's just the facts on the table. And it's a paradigm shift that I want the world to know about just so that people understand, hey, there's going to be someone that comes up with something better than I did, right? Like I'm standing, the reason why we have the fastest signal library in the world is because we listen to the people that are really good at that. We use alien signals.
The reason why we have the fastest morphing library is that we listen to people and said, hey, there's people that care about this stuff and are working towards it. It's not that there's anything special here. It's that it's trying to build an ecosystem of like people that care about performance and people care about the details. And if you do that, then everything gets better. So it's not just where are we at now, but if anyone thinks they can do better, please join us. We want to hear it.
But like, I'm done having the vibe code, or not the vibe code, but like the vibes around like, well, this doesn't feel like a spa or like a spa has its place. A couple of episodes ago, there was a Cody from the Litestar stuff said, there's a time and place for HTMX or Datastar. And he's just, that's just not true. It's just like hypermedia is the way to build things for a hypermedia client, which is the browser. So I will, anyone that can show that it's wrong, please let us know.
Like we're here to help.
I would love to see this paired with some Electron JS apps to make your desktop apps a little better too. So anyway.
Seriously, oh my God.
That's a different episode. So I just want to say thank you, Delaney, Ben and Chris. Thank you all for being here. And congrats on Datastar. It looks like a super project. I'm looking at some projects or an app running right over there on my left that I kind of wish I'd built Datastar.
Well, and the thing is to make sure to not think that it's just used, like, yes, we talk about the real-time stuff, but it's better for even just normal crud stuff. And that's kind of hard to, like, it's not as sexy to talk about, but it's better at that too.
Well, it's also 80% of what gets built. So it's important to like point it out, right? Yeah. All right. Bye everyone. Thanks for being here. Thank you. This has been another episode of Talk Python To Me. Thank you to our sponsors. Be sure to check out what they're offering. It really helps support the show. Take some stress out of your life. Get notified immediately about errors and performance issues in your web or mobile applications with Sentry.
Just visit talkpython.fm/sentry and get started for free. Be sure to use our code talkpython26. That's Talk Python, the numbers two, six, all one word. This episode is brought to you by CommandBook, a native macOS app that I built that gives long-running terminal commands a permanent home. No more juggling six terminal tabs every morning. Carefully craft a command once, run it forever with auto restart, URL detection, and a full CLI. Download it for free at talkpython.fm/command book app.
If you or your team needs to learn Python, we have over 270 hours of beginner and advanced courses on topics ranging from complete beginners to async code, Flask, Django, HTMX, and even LLMs. Best of all, there's no subscription in sight. Browse the catalog at talkpython.fm. And if you're not already subscribed to the show on your favorite podcast player, what are you waiting for? Just search for Python in your podcast player. We should be right at the top.
If you enjoyed that geeky rap song, you can download the full track. The link is actually in your podcast blur show notes. This is your host, Michael Kennedy. Thank you so much for listening. I really appreciate it. I'll see you next time.
I'm out.