go podcast()

Dominic: 00:00

Hey there. I'm Dominic Saint Pierre, and you're listening to Go Podcast. Today, we have an interview with Delaney Gilliland from the Data Star project, so we revisit that. And, yeah, we have a great interview again with Delaney. Also, if you want to join the Go podcast channel, we are there on the Gopher's Slack.

Dominic: 00:24

If you are not invited yet, there's a link on the gopodcast.dev if you want to join. And, also, if you want to contribute, plea you know, please share the the podcast with anyone that you know if you if you think that they might enjoy the content that I'm doing here, interviews. And and, yeah, for for newcomers to go, I released a course about four weeks ago. It's called Zero to Gopher, and it goes on the you know, all the Go fundamentals that a new a new Go software engineer needs to to get started. So if you if you want to contribute or support the show, that's the, you know, that's the best way for now.

Dominic: 01:12

And on that oh, yeah. Yeah. Before before I forget, my, you know, the cadence of releasing episode might be affected a little bit in the following months or months, one or two months, something like that. I don't I don't know yet. I will need to find a new a new schedule and things like that because I have I have new commitments at the moment.

Dominic: 01:34

But but, yeah, I might I might turn I might turn the cadence on a two week basis or yeah. Let's see. Alright. I leave you with the interview. Hey there.

Dominic: 01:49

I'm super excited to receive the Leeny Gilliland again from DataStar, so thank you so much for accepting the invitation.

Delaney: 01:55

Yeah. Absolutely. Happy to be here again.

Dominic: 01:58

Yeah. So if you want to listen to the intro and and the first part of this, it's episode 54. And we will not be covering, you know, the fundamentals of of Data I encourage you to listen to that. I contacted Delaney because I started to to use DataStar, actually. And you know what?

Dominic: 02:21

I I listened to our episode yesterday at at two x. It was still it was still very slow for me because I I'm I'm very used to to listen to very fast speaking with my screen reader now. But a couple of things that jumped into into my minds, and I I want to to let you know that it it it was very hard for me even even though I was an HTMX and an Alpine user, it was very hard for me to really appreciate what DataStar was from even even after our conversation and the documentation that I I've read back then until I I tested it. And to be completely frank for me, it was all about sending a patch of signals from the back end, if that makes any sense. Mhmm.

Dominic: 03:13

So that to me was like, oh, okay. Wait a minute. Now I have some superpower that that frankly, I was not having from using HTMX and Alpine because the locality of the states in in Alpine does not really allow you to well, not as easily if I I I will put that that way. Not easily as as DataStar. So to me, it was it was it was very interesting to send, you know, a signal.

Delaney: 03:45

Yeah. Absolutely. So the the kind of the key to what DataStar makes, there's there's a couple things that make us different. And I would even say, for most developers, if you're coming from a lot of people will go from, for example, React to HTMX. But our approach is almost as big of a jump from HTMX to the Datastar way of doing things.

Delaney: 04:08

And part of that is that everything is a reactive expression, so there's a lot less code that you have to do to make things happen. But, also, we do have SDKs for people, but they're literally three functions. Like, all you have to learn to be able to do back end work in any language is implement these three functions, and you're done. So it's kind of a weird place to be in that we are a agnostic back end framework that happens to have a 10 k shim that makes it so you can work in any language. So it's kind of a different take than most people think it is.

Dominic: 04:42

Absolutely. Absolutely. And and that that is that is very interesting. But again, even though and and we will we we will start I maybe I should have started by asking you, you know, what what what I what I've what I've happened in the last eight months because I I we talked last time it was March 2025. Data Star was almost about to release to v one.

Dominic: 05:08

Mhmm. So I'm seeing a pro version now and I'm seeing a full rewrite, I think, that that happened. So why is it there?

Delaney: 05:15

So basically, what happened was we were getting ready for the release, and people had been using it for quite a while. And we're like, oh, this is this is going really well. We really like the declarative nature of it, how people have been using it. It solved a lot of problems. But then we got into the weeds of, like, oh, we can actually do some dynamic stuff.

Delaney: 05:35

We technically had the fastest signal engine out there. We were doing these static dependencies, but we found some things out from the you know, we're not really JS developers. It just happens to what we need to do to build, you know, tools for the back end. And there's some really interesting stuff that happens if you do dynamic signals. And without getting too much into the weeds on JavaScript funness, the point is is that we basically swapped everything around, rewrote everything to do this dynamic style, and we actually are using a modified version of alien signals, which is the fastest approach that's known right now.

Delaney: 06:06

So we have the fastest signals library. We have the fastest morphing strategy. And I can talk that we're actually possibly getting even faster. So even though on the outside, it looks like HTMX and Datastar both commute to ideomorph, if you actually do run the numbers, we're about 10 times faster than what they do. So it's one of those things where we did a full rewrite.

Delaney: 06:27

And then in the middle of that, we found that there's a lot of things that people were doing as anti patterns. Like, they're making their lives harder. So we were going to drop all of those plug ins that we didn't think were really necessary, but we ended up rewriting them and saying that these are actually support burdens for us. So we're gonna start from scratch, rewrite everything. And the things that we think are anti patterns, we actually put it under pro in that, like, if you're gonna make choices that we disagree with, at least help support the nonprofit and all that.

Delaney: 06:56

So we I think we already had it in place last time, but we did start a nonprofit. We have a five zero one c three for DataStar. And the pro stuff has things like, for example, an inspector that does things better than DevTools around being able to listen to signals, being able to highlight what signals are on the page, being able to automatically see when events are coming in, all that kind of stuff. There's an inspector built in that you can just drop on your page and get full idea of what your signals are happening. We also have a project Rocket, which should be coming out in the next few days, actually, that is a web component library, kinda like Lit or Stencil, but it actually allows you to do things completely declaratively and still use all the things you've learned in DataStar, but write declarative web components.

Delaney: 07:40

So that's coming down the pipe. And then the other thing is I have a tailwind killer that's now feature complete, but but I'm working on making it work as a SaaS scalable thing, which is a straight up tailwind killer in that you're doing open prop styled CSS, but you're doing it with dynamic content, which means that if you change things in the editor, it automatically changes on your page and everywhere else at the same time. So imagine if you had a tailwind documentation, but it literally, as you made changes and edits to it, it automatically updated your page as well without using utility classes and stuff like that. So there's we have quite a few things that are coming in Pro. But, yeah, otherwise, the the core semantics and how Datastar works has stayed exactly the same.

Delaney: 08:24

We just added features that anyone else can add as well.

Dominic: 08:28

Okay. So that that's interesting. I think there's a a lot to unpack there Yeah. For sure.

Delaney: 08:32

For sure. That would move pretty quickly.

Dominic: 08:34

Yeah. Yeah. Yeah. Totally. I'm I'm I'm still a little bit it's still a little vague in my head how signals are implemented, you know, in a sense in in DataStore.

Dominic: 08:48

And and and and in our last episode, you mentioned something that that is really cutting my attention now. You you mentioned that at some point, maybe signals might be, you know, directly into the into end all by the browser. It might might be a a standard that that could evolve. So

Delaney: 09:07

Yes. So there's already a process in place called t c 39 that is literally trying to get signals into the into the browser. And that would be the ideal thing. There's a lot of things that Datastar does that if we're in the browser, would make everyone's lives better because it'd be faster and more efficient and all those things. Because we have to recreate a bunch of state.

Delaney: 09:26

But the signal stuff is actively happening in the working group right now. So the irony is, as soon as that happens, data storage gets smaller. Like so the over time, more and more of the core engine will be implemented by the browser, and then data storage just gets small. It's already it's already the core is only four k. But if that went away, it would be probably three k.

Delaney: 09:49

And if there was a morph to instead of a move before, for example, in the browser, we would go from 10 k to probably six. So, I mean, there's a lot of things. The irony is that Datastar is tiny, and this is kind of the reason why.

Dominic: 10:04

And when you say more so, are we talking about the logic when when some some HTML is sent from the server, how how it is integrated in into the page. Is is that what

Delaney: 10:14

you are talking about? Correct. Things like, for example, Vue or React, what they do is they actually create a virtual DOM where they try to match in JavaScript space which DOM elements have changed and all that. The way that we do it is with direct DOM manipulation using fine grain reactivity. So we can do things that are really fast and efficient and completely remove the the the VDOM completely.

Delaney: 10:40

So, yeah, our approach is really fast. But if they made a couple changes to the actual browser standards, we could get even smaller. So that's kind of the the benefit of that kind of

Dominic: 10:50

stuff.

Delaney: 10:50

And some people think we are a little crazy about how much we care about the size, but people forget that that first connection with TCP is around 12 to 14 kilobytes. So if your page is four kilobytes and you send down data star with it, like, you're basically have it all in the first packet that gets sent down. So this stuff does matter, especially on mobile networks and things that are more erratic with their network connectivity. So it does matter.

Dominic: 11:17

Oh, yeah. Totally. It's kind it's kind of crazy at the yeah. To to be it's so would you would you say that this might be one aspect of that a let let's let's double quote, you know, a standard React web developer, for example. Is is the signals the part that they might have some difficulties at first going into DataStar that that you are seeing?

Delaney: 11:44

No. In fact, the the people that are just front end people tend to understand it because signals have now become kind of a standard thing. If you ever seen the set, like, the effects and stuff that are built or hooks or runes from Svelte, all these things are takes on fine grained reactivity. The idea has been around for quite a while. It's just that the fastest approach to this is already built into into Datastar.

Delaney: 12:08

So people that come from that world will not have a hard time. It's people that have only done back end stuff. Because the idea of signals is more that you're not creating variables and setting events and all that. What you're doing is you're creating relationships, kinda like when you're doing, for example, an Excel spreadsheet. You won't you say, hey.

Delaney: 12:27

When a one plus b six is in this formula, basically, it's it's a relationship saying when that stuff changes, this field should automatically change. That's all you're doing, really, is you're setting up relationships so that when things change, all that updates automatically for you. So setting up a page is really setting up those relationships and the signals, and then everything else happens for you automatically.

Dominic: 12:50

And is is those signals local? So let's let's say let's say we have a a very, simple signal on on a div, for example, that let let's let's use a a normal example of incrementing something in into a with with two buttons, you know, plus and minus and the the very simple. So where is this thing scoped at the moment and can can I shoot myself in the foot declaring another signal with the same name elsewhere in my in my HTML and that now I'm I will start to have some problems?

Delaney: 13:25

Yeah. So the the thing is there's a couple things about that. Most of the time, people go to signals too early. A lot of times, the state it depends on where the state lives. Like, if it's a value that comes from the back end, then it should come and get rendered into the front end.

Delaney: 13:41

Like, the person shouldn't have direct access to it. So for example, you might do an on click that says, hey. I want to update this, and you're sending command to the server to say, hey. I'd like to change this. That's one thing.

Delaney: 13:50

But if you if it is truly local state, let's say you're making a calculator or a D and D dice roll or something, something that truly belongs in your local state, then, yeah, you can basically have in DataStar, there's a global signal store that's nested. So you can do 16 layers deep if you want of basically organizing your signals to what's on the page. So you have a lot of flexibility in how you set up your page, but most of the time, most of the state for most applications actually should live in the back end. So there's very few signals that you need on a page compared to if you're doing a SPA, all your state basically lives in the front end, and you're constantly having to pull JSON or something to try to update your state. In a data store application, almost no state lives in the front end.

Dominic: 14:34

Yeah. Yeah. Totally. And then it's the same for HMX and Alpine. The the state I'm I'm more talking about is, you know, opening a drop down, for example.

Dominic: 14:42

And all all those small action that that a user is doing that has, you know, nothing to do with the back end at the end of the day.

Delaney: 14:49

Yeah. So some of the stuff that's built into Datastar is we kinda have a convention that if you do underscore in front of any of your signal names, we the default is that those won't get sent to the back end. Of course, you can change all this stuff. But the other thing is is that the stuff that's coming in Rocket, it is has the idea of scope signals. So Rocket is just another plugin.

Delaney: 15:10

It's an attribute plugin in Pro, and what happens is it actually generates a unique ID that all the nested content is gonna go under. And then when that component that web component goes away, it automatically deletes that from the from the signal tree. So it actually does scope signals, and it allows you to do these kinds of things. But, again, that Rocket plug in and that web component architecture is something anybody else can do. So there's nothing special or nothing, you know, out of the ordinary.

Delaney: 15:38

It's just if you wanna do a scope signal type thing, 100% can, or you could just use Rocket and keep going with your day, if that makes sense.

Dominic: 15:45

Yeah. Yeah. Okay. That's that's that's interesting. And we we touched a little bit last time, and I I want to return a little bit on the back end.

Dominic: 15:54

So I I know that I I don't know if you are still there, but I I know that you were working for a company that that is behind Nats base basically, if I'm not Yep.

Delaney: 16:02

Still at Snedia. Yep.

Dominic: 16:03

Oh, nice. Nice. Cool. So I I didn't really saw the the potential at the moment. It's it's very hard, you know, in in a podcast when you are explaining things like that.

Dominic: 16:13

So that that that's a little bit why I wanted to to do a a part two of this. This this is exactly where I myself, I had some, you know, crazy ideas about what I can do now with Datastar. Now that when I finally understood a little bit how a GoHandler, for example, could could stay open because we are using server side event, and now I could have some some select that that waits in in a, you know, for a channel and things like that and receive some messages and and whatnot. You know, this this to me, I I I'd like to hear you a little bit on that, you know. Are you was that mainly why you built DataStore at first?

Dominic: 17:00

Because you wanted some kind of, I don't know, you know, web back end way to to to drive your your UI at at the end of the day?

Delaney: 17:11

Yeah. Absolutely. In fact, that's exactly what it's built for. It's built for real time collaborative collaborative systems. And what I mean by that is people look at Datastar and some of the examples, and they go, oh, sure.

Delaney: 17:22

It's real it's good for, like, real time chat, but it can't do a CRUD app or something. And I think people kinda miss the the idea that a crud app and a real time collaborative app is just about how often you send and what you send, in my opinion. So the idea is that, in general, for most pages, what I'll do is I'll basically send down a skeleton of just like the bare bones of the page. And one of the things that it does, it says, hey, go send a updates keeping updates request open. Now that could be to the same URL, but it'll basically get a data star header so that you know it came from data star.

Delaney: 17:59

And then what happens is you basically open up a channel that just listens for changes that affect the page. And then if you're using NATs or any kind of other event bus, then that's going to be open and be ready for changes. And the nice part is, it doesn't matter if that came from a CLI, from a different service, from a user sending a command. You basically have a live up to date version of that resource. It's taking hypermedia to its final conclusion in that when you go to a URL, you're seeing what the live version of that page is for literally everyone in the world that has access to that content.

Delaney: 18:33

A perfect example of this is there's one of the members of the community did this billion checkbox or he did firstly, he did this Game of Life demo. And it's a collaborative game where everyone in the world is basically getting sent down 2,500 divs of the Game of Life styled and everything. Not done in a super efficient way, but the irony is that he just sends down 2,500 dibs to every single person that's watching it in the world. And it's handled, I think, 20 or 30,000 unique people. It's been a top of hacker news multiple times, and it runs on a $5 server using Datastar.

Delaney: 19:09

And some of that comes down to how you build things. It is so simple. But also, because we have a one open connection, we can use things like Brotli or z standard for compression over a window, which means you can send down all 2,500 dibs or 10,000 dibs on your page. And what happens is that on the wire, it only updates the things that have actually changed. So instead of doing some kind of weird diffing thing like live view or trying to do a bunch of state checks, you use the compression as your diffing algorithm, and it means you send very little data to the front end.

Delaney: 19:43

And what that means in practice, and we've seen this multiple, multiple times, is when people talk about encoding something or making something compressed, they look at, at best, a four to one ratio. Right? Our compression ratios are between 400 to one and six thousand to one ratios.

Dominic: 20:00

Damn. Yeah. Yeah. That's impressive for sure. But Yeah.

Delaney: 20:04

And the irony is that you're really sending down these big page chain so that you don't have to do a bunch of checks to see what's changed on the page. You can send down big, huge, what we call fat morphs of what the current page is. And the irony is most of time, it's faster because it's not doing a lot of branching. It's not doing a lot tracking of state. It's just sending down the latest version.

Delaney: 20:22

That's it.

Dominic: 20:22

But but Live View is also doing that, if I'm not mistaken.

Delaney: 20:25

You They are not doing that. What they're doing is they're doing constant diffs of the state. I don't know if people know this, but I actually built an entire Go version of Live View. It's called GoGo Racer before I did Datastar. Because I thought that was the approach to go down.

Delaney: 20:39

And what's happening with that is it's trying to do the equivalent of CRDTs or conflict resolution things on the client and on the front end, and they're doing a bunch of tracking of change. In fact, today or tomorrow at the Closure Conj for Closure developers, they're doing a whole talk about literally Datastar versus the Live View approach. Because there are people that have done both ways. And let's just say the numbers are on our side. It'll be interesting to see what that talk looks like.

Dominic: 21:08

Nice. Okay. That's that's that's interesting. But but but also, I've I've seen I've seen some Python usage and and things like that in PHP as well. So would you say that, you know you know, if we if we are going to build some some back end and go in Elixir and whatnot, I mean, are a little bit more proppiest to to have server side even server side even because, you know, compared to Python, which is like, I say, it has difficulties handling multiple requests at the same time even though if you have a unicorn and what what whatever how many threads you are going to use with your server, you you it might hurt at some point to to have a keep alive connection.

Dominic: 21:53

So what's going on there?

Delaney: 21:55

Yeah. A 100%. So there's a lot to be said there. The thing is is that this is not a data star problem. It's more of a

Dominic: 22:01

Oh, yeah. Yeah.

Delaney: 22:01

Yeah. You know, I know. It's it's more of a it's a collaboration issue. In fact, one of our core maintainers, Ben, is a heavy PHP guy, And he's running into the like, Oh, there is limits to PHP, even with Swool and Frank and PHP and all these options. So the irony is that doing DataStar tends to make people think, Oh, I can do real time.

Delaney: 22:24

Maybe I need to look at NAT. Oh, I can do real time. Maybe I need to look at Go. Or some other things. Like, I think of Go as a very high level language.

Delaney: 22:31

Like, I'm a I like C and Odin and stuff. But Go is on that really interesting cusp of it's faster than your network. And it uses very little memory, and you can be smart about garbage collection. Like, can do be smart with Go and get a lot done. So the irony is that our community is a ton of people.

Delaney: 22:47

I think we have 14 or 15 SDKs at this point, and we have a lot of people using Enclosure and Python and all that, but we have a lot of people that are using it in Zig, for example, and Rust. So it's one of those things where most of the time spent on the Discord server is talking about your actual architecture of your back end. Very little of it has to do with Datastar. I'm sure when you played with Datastar, you realized that, like, it takes very little of it on a page to actually be rocking and rolling.

Dominic: 23:14

Oh, yeah. Oh, yeah. Totally. And and and not much as well. Not much not much keywords I needed to, you know, to have in my my mind and whatnot.

Dominic: 23:23

I mean, I am able to very, very quickly do what I was doing with HMX and Alpine with without without a lot of cognitive load, if I can say that.

Delaney: 23:34

Yeah. No. Well, that's kind of the point. My whole thing with the like, we're at the point now where we're not really like HTMX in a lot of ways. We're more of a framework.

Delaney: 23:43

It's definitely

Dominic: 23:43

a

Delaney: 23:44

library, and we are a unified solution. And the irony is that by being a unified solution, we're actually smaller than either HMX or Alpine, and yet we're a full framework.

Dominic: 23:57

One thing, though, I'm I'm I'm I will point point out to you is that what what I'm what I'm seeing at the moment is that my handler tends to get big because now it seems like I'm handling a lot of error correctly, which I would I might not have done as carefully if I can say that with without having especially if if it's a server side server sent event. If I'm on the an handler that just, you know, just return some HTML and there there's nothing that that's that's normal. That's but as soon as I'm starting to now okay. You know what? Let's let's just take a real example.

Dominic: 24:35

Creating, you know, sign sign up in for a software service for a a product, whatever. There's a lot of steps, and I don't know why, but it changed a little bit how I'm I'm thinking of of how to go ahead with my handlers and now I have a lot of separate tasks that that just, you know, notify the user or you know what? We are at that step. We are at that step where so it's really nice from a user point of view. When I look at my code, I like I'm like, oh jeez.

Dominic: 25:06

This this is a lot of this is a lot of because this is, you know, of of Go error handling and whatnot. But it also makes me handle the error correctly, if I can say, for the user.

Delaney: 25:17

Absolutely. No. That you're you're getting exactly like, there's something to be said about the quick Datastar prides itself on being simple, not always easy. And what I mean by that is there's a lot of things that feel simple, but are actually not simple in the long run-in, for example, HTML or other options in this space. A perfect example of that.

Delaney: 25:39

Let's say you have HX Git. Right? H x git is actually tying a click handler into a request to the back end. Right? So it's actually tying together two different ideas into one event.

Delaney: 25:54

And that may seem easy at first, and it is easy, but it's not simple. Because then if you're like, well, what if I want to be up only on pointer down, or if I want to change to a different event hook, like, you now have to rip those things apart, now you have to add extra tags. And your the thing is is that data start kinda forces you to think about things at a at a deeper level. If, like, for example, someone's like, oh, I'm sending too many signals to my front or to my back end. Well, why do you have so many signals on the page?

Delaney: 26:19

Like, it forces you to actually simplify your stack. And what's happening in the back end is you're handling things correctly. Just like when people don't like the if error in Go, they just don't like actually having to deal with the unhappy case. A lot of developers just want the happy path. But that's not being an actual developer.

Delaney: 26:38

Data store is kinda the same thing is that once you realize that I can have it update any part of the page at any moment, and I can give the user exactly what they need to know, the reactivity goes up, but your responsibility, you get to that sooner, if that makes sense. Like you're not doing a lot of magistration around getting something on the page. So you instantly go to a harder problem. A perfect example of this is it almost seems like a instead of a hello world of just like, hey, I got a response from a back end. Almost everyone's hello world is a full chat app or Google Wave duplicate.

Delaney: 27:11

Like, that's their hello world in Datastar because it just opens up the door so much that the idea of what's basic really does change your brain, for sure.

Dominic: 27:19

Oh, yeah. Absolutely. Absolutely. And and, yeah, once you realize that you you have some power just just an another example. Just opening a model, for example.

Dominic: 27:29

So now if, you know, if you were submitting a form in in a model, then you have option to just return an error or or, you know, send send the signals that close the model and update the page be behind that. That that to me was was very, very, very nice when I when I, you know, discovered that that power, if you will, I said, oh, wow. Okay. Did that that was not fun before to do that.

Delaney: 27:56

Yeah. And the the thing that's really important to me as a developer is there's almost always a limit in that how you develop things with React, with HTML. There's always a thing of, yeah, it's good in these situations, but not in these other ones. And I really strived with Datastart to not have to redesign things if all of sudden I'm like, oh, this is cool, but I wanna add a a chat feature. Hey.

Delaney: 28:18

This is cool, but I wanna update the person at this time. Or it's I'm saying, hey. I'm just doing a CRUD app. I don't want all these features, but the thing is is that it's actually less code. Every single time we do a head to head with any of the other JS frameworks, let alone the hypermedial stuff, we're always smaller.

Delaney: 28:36

In fact, there was a Kanban thing that just came up a little while ago. And our Go version of it was half as the size of the Next. Js version. So even in a more verbose language like Go with error checking and being 10 times faster, it it still was less code.

Dominic: 28:57

Yeah. Yeah. That's interesting. Yeah. And the the error yeah.

Dominic: 29:02

The error is is also is also very useful for the user. And the the way the way that I'm handling error now in my web handler is way, way much friendly friendlier for the user. This is crazy.

Delaney: 29:16

There's actually an essay that I did a while ago that said I'm a teapot, is the name of the essay, if people wanna look for it on the Datastar website. And part of my point with errors is that if you're doing hypermedia, again, hypermedia is different than RPC or doing a SDK, that kind thing. But when it comes to hypermedia, users should never see a four or 500 error.

Dominic: 29:37

Yeah.

Delaney: 29:38

Yeah. If they should be seeing two hundreds, which is just I'm updating the content to allow you to see things. So for example, if you're on a banking app and someone's not allowed to change their CD rate because of this thing, they're just getting an update on their page, but it's not actually like a anything other than a 200 success from an HTTP standpoint, that you should be updating the content with what they're allowed to do at that moment, not sending four and five hundred errors. That's silly.

Dominic: 30:04

Yeah. Yeah. Totally. But but yeah. Again, the the some people I I was doing that as well.

Dominic: 30:11

Sometimes you build the API first and now you return HTTP error because, you know, that that's the way to go in an API. You don't really know yet what what will be the the front end, you know, will it be will it be a a a spa? Will it be something else? So yeah. So so far, I I like I like that a lot.

Dominic: 30:28

I like that, you know, I'm I'm a grown up and and and all the they work correctly for the user at the end of the day.

Delaney: 30:34

Yeah. I will also tell people that one of the things that I'm very, like, I very much like gRPC. I like Connect, Torp, all these things, especially in Go. They're really good at doing APIs. But I do want to make sure that people realize that hypermedia is for humans.

Delaney: 30:49

Yeah. It's for, basically having a choose your own adventure of what you're allowed to do next, and it's tying the view to what the next view is. That's what links and all that are all about. So I I really want people to think before they try to just try to make a an API, which is meant for computers to talk to each other, it's a very different thing than building a hypermedia application.

Dominic: 31:13

Oh, yeah. Yeah. Totally. And and and Go is extremely good at at doing that, to be 100%. Honest, you know.

Dominic: 31:19

Yeah. Especially, Le, you you seems to you seems to use Temple. I'm I'm I've I've returned myself to good old HTML. I created my my own, you know, small library that helped me, you know, accept the fact that HTML template sometimes is isn't isn't the best way to do things.

Delaney: 31:39

Yeah. Well, yeah. And I've you've had Marcus on the show. We've actually been talking back and forth. He's actually in the Discord for Datastar nowadays too.

Delaney: 31:47

And because I also have that other project that's similar to to to it called GoStar Yeah. That allows you to do type safe version of components. So there's there's always a lot of options in this space. And that's the neat part is that, at least with Datastar now, you truly just decide on what templating makes sense to you in what language you want, and you just go about, and you can have a a sane conversation with someone who's in a completely different language, which is a a kind of a neat change from dealing in other things. Because a lot times, there's lost knowledge.

Delaney: 32:18

Right? Like, if you have someone that does Flask for Python and you're a closure developer or a Go person, you guys can't have an active conversation. Whereas in the data star community, that's a 100% just a normal thing.

Dominic: 32:30

Yeah. Yeah. Totally. I get that. Did you did you add some hard pushback when you released the pro version?

Dominic: 32:39

What what, you know, what happened there? You did was that fine? Or

Delaney: 32:43

No. People actual actively hated us beyond belief. In fact, if you go look at Hacker News and all that stuff, we got called rug pullers and like terrible people. And what's interesting is so here's the fun part about that. Like, you know, open source is one of those things.

Delaney: 33:00

I I work in at Sanadia on that and stuff, but doing your own project it is funny what people expect out of open source. And what I mean by that is we took our own project, basically forked it, did our a whole new rewrite from scratch, and did our own thing. And it's not like the other source went away. It was just like, look, we don't think these things are good ideas, and we have the support burden of it. So we want people to at least have some skin in the game if they want to go down these routes that we disagree with.

Delaney: 33:29

Right? And people said we were almost stealing from them that we were taking away, but old code's a 100% there, and we went with a different approach. So, yeah, it's been kinda interesting that way. But I will say, one of the ironies of that situation, this is a little bit of inside baseball, but everyone that actually bought a pro license, we have gotten zero support tickets on those those things. Because most people that do pay for pro already believe in the project and actually do it the way we tell them to do.

Delaney: 34:01

And then they don't use those plugins anyway. So the put actually taking them out of the the open source one and rewriting how we do it has actually been a a big win for us because it actually makes the focus on people focus on the right things. The other thing that's interesting is that we've actually done a public API. We've made it so that it's much easier to write plug ins yourself. And we build the same plug ins as anyone else.

Delaney: 34:26

And we are starting to get people on the outside that like, you don't have to agree with us on what those features are to still be able to make your own plug ins and all that. But we also see that most of these are experiments to people just wanting to play with plug ins, not really using them in production apps, if that makes sense.

Dominic: 34:41

Yeah. Yeah. Yeah. Yeah. Yeah.

Dominic: 34:43

I I I I read the the essay, actually. And I I was browsing the feature of the pro version, and I I something that caught my attention was the data the the replace URL one. So does that mean that this this isn't part of the of the, yeah, the core version?

Delaney: 34:59

No. I because I actively think that is a bad code smell, and here's why. Most in most things, like, example, in a SPA thing, you're changing the URL and changing parameters and all that all the time, like, you're in a data table or something. Right? Mhmm.

Delaney: 35:17

That actively goes against the ideas of hypermedia. If you actually read the original dissertations and stuff on this. And the idea is that a URL is tied directly to a resource. Mhmm. So that resource is the content you are looking at now, and whatever content that is pointing to in the future.

Delaney: 35:34

So those things should be almost static. And what happens is with URL parameters and all this stuff, you're actively changing it, which means you're also updating your history. And if you're doing things in real time, now all of a sudden, if you're doing a thousand updates a minute, guess what? You've just destroyed that person's history forever. That's not the same thing as doing, for example, a deep link or using cookies or all these other ideas.

Delaney: 35:55

So most of the time when people do that, they're doing it because they got used to doing it in another framework, not because they're thinking about it at a resource like, a real time resource in a collaborative sense. So, yeah, we took it out because it literally was people doing the wrong thing constantly, and you don't need that at all Yeah. If you do it our way.

Dominic: 36:16

That's yeah. That's interesting. Yeah. Yeah. I I was just browsing.

Dominic: 36:19

That one do you know, cut my attention very quickly so that that I was curious about that. So so yeah. That's that's open source. Yeah.

Delaney: 36:28

What Well, the thing is what's interesting is, like, in the examples, I made another essay called Greedy Developer, where it's like people are saying, we're taking away these things from them. And it's like, okay. Well, here's an example of how to do it in, two lines if you want to do Yeah. A simple version. But it's more complicated than that.

Delaney: 36:43

And if you get into the weeds of history push date and all that, like, there's more of a support brand than people realize. And you're actively working against the ideas of rest and hypermedia if you do these things. So that's it it it's one of those things that people think they want, but, like, we've been working on this for three years in the open. We have a pretty good idea of what is possible and what the how capable the framework is at the size it is too.

Dominic: 37:10

Sure. So are you are you soon to go to the desert? You you you mentioned that last time, something like that.

Delaney: 37:17

Well, mean, I'm I'm I'm getting pretty darn close. And what I mean by that is the rocket stuff, it's out of my hands. It's in the rest of the core team's hands right now. Like, that's coming out this week, hopefully, if they sign off on my my craziness. Because it is pretty big.

Delaney: 37:31

It it is a it is one plug in that's around 3,000 lines long. So Rocket is no joke, a big thing. And then the seller stuff, I am feature complete, and I'm working working on making that a service, which is great. And then yeah. That's basically, like, those are the things DataStar is done in my opinion.

Delaney: 37:49

There's a little, like, tweaks to the plug ins here and there, but nothing, like, nothing that couldn't have been bug fixes. And the like, yeah. I'm I'm getting to the place place where I can go off into the desert. In fact, we are talking about having a a data comp possibly, like, in the mid to end of summer in Europe next year. And the nice part is, I won't have much to say at that other than thanks for coming, guys, because I will be able to go off into the desert.

Delaney: 38:17

Because the things that I wanted to fix is JavaScript in the front end, and then I wanted to make it so web components were declarative, which is crazy that they're not. And I wanted to make it so that you don't have to write Tailwind to make a beautiful website. And I think I'll by the time that conference comes around in, like, the the next six months, I won't like, there won't be anything else left to do. Like, DataStar is a complete idea, and then I can get back to what I was doing in the first place.

Dominic: 38:45

Can can you can you explain me a little bit what you may what you mean by, you know, a tailwind killer and and how how I I'm I'm not sure I got what you said about the the property and whatnot.

Delaney: 38:59

Sure. Yeah. So there's a there's a project that I'm working on right now called Stellar. And Stellar is a have you ever heard of OpenProps? Do you know what have you heard about that before?

Dominic: 39:08

I don't know.

Delaney: 39:08

So all open OpenProps was built by, again, Adam at that was at Google. And what it basically is, is just a set of instead of doing the tailwind thing with a bunch of utility classes where you do, you know, p w two h three, that kind

Dominic: 39:21

of thing. Yeah.

Delaney: 39:21

You are using regular CSS because the idea is Tailwind was built for a time before we had nesting and we're starting to get mix ins and functions and all these like Modern CSS is much different than the world when Tailwind was brought into the world. Right? It's it's just CSS is so much more capable now than it was back then. So all the open prop stuff is is you get, like, size six and a font size 10, and you use that as your variables. So they're just CSS variables that you use in regular CSS.

Delaney: 39:52

So the nice part about doing that, in fact, the new data star website is done with Stellar. You'll see that if you look at our page, there's almost no classes or utility classes on the page at all. You're just using h one, h two, you know, paragraph tags, and we can semantically make changes to the CSS and not update and not have that mix up the page. There's a couple things that are really good about that. A, you're dealing with stuff in nested CSS, which is a it's really nice.

Delaney: 40:20

It's easy. The other thing is that you're actually sending a lot less data per update when you're updating collab because a lot of that's the size of web pages now is mostly in the class attribute, which is kinda crazy. Right? Like, it's the same every time, and you're sitting down these giant classes when that's not needed. So the idea of open props was this.

Delaney: 40:40

Let's make the tailwinds the best part about tailwind was its design system. It was a solid design system, and it was convenient. The problem is it's hard to maintain. So open props takes this idea of like, let's make a design system, but using CSS variables. To me, that was a great step forward.

Delaney: 40:57

But the problem is, if you don't agree with those things or if you say, oh, I need one extra step or something like that, it's not built to be parametric. And what that means is I basically built a system that's very similar to Open props in practice of what the CSS that it renders out is, but it's completely configurable. So imagine if you had a tailwind you've seen the tailwind docs. Right? Yeah.

Delaney: 41:21

Imagine if on the side there was a property panel that's allowed you to change every aspect of, like instead of just doing w two, you could actually say, here's I wanna start from this size, and I wanna grow at this rate, and I wanna change this thing. Basically, you have all these configurable options, and there was no TailwindConfig. Js. You literally were just editing live. And then as you made these changes, if you had a page that used Stellar, it again, built because it's built on Datastar, I can actually hook into the the configuration that you're generating, which means as you're editing live in your thing on your page, it's actually pulling in those variables and redoing everything in, like, directly.

Delaney: 42:01

Like, basically injecting and updating your CSS. So you get a full editor, and you're able to play with it and make it exactly what you want, and you're also getting stuff on your page. There's also things that no one else does. So for example, I automatically let you search fonts directly in the editor. We have a I do a bunch of stuff with color theory that no one seems to do in 16 bit space, and then creating basically a thousand different iterations of color theme for you with each image that you upload.

Delaney: 42:31

So if you upload an image that says, hey, I like this color theme, we basically generate out a thousand different themes for you and guide you in, like, which one has the best contrast and all these other things going on. So also handles things like color blindness, which is most people don't handle. There's just a ton of features that are going into it that basically all the things that I ever wanted in a CSS editor and config, and it's in one place. It generates a few CSS variables at the end of the day.

Dominic: 42:58

Where are we? You know, so so so it's a bra it's a browser thing. So I'm I'm in I'm in a browser. I'm I'm in a page, and I'm able to use this this property panel and play with with with with the property live, but it gets saved to a CSS file?

Delaney: 43:13

Yeah. So what happens is, basically, you have this property editor and you have, like, stellarcss.com. Right? You're sitting there on the editor playing with these different options, font sizes. It also does everything with fluid effects, and there's there's a bunch of nice things going on.

Delaney: 43:27

But the point is, you're playing with it on your page. Then you in your application, you add a web component that says it's gonna be stellar dash live, and then you give it an ID and a token for the the CSS that it's tied like, the configuration is tied to. And then as you make changes in on your page, it automatically updates from the editor. So because if we have data star, can do a live connection to the server, and whenever that changes, we automatically update, reinject your CSS, and fix it all for you on the fly. So you don't have you can basically instead of trying to guesstimate what a config change would be, it would be happening live because of Datastar.

Dominic: 44:07

And your server is going to process that, and I can download that file at some point?

Delaney: 44:11

A 100%. It'll just be it'll just look just like look like regular CSS variables at the end of the day to you. And you can also just do a standard curl command and just grab that thing yourself. The pro the pro thing is gonna make it editable, but anybody will be able to look at and view your CSS and all the variables and stuff live with documentation, everything on the fly. Yep.

Dominic: 44:30

So we have we have variable now with CSS, like like what what SAS was a a long time ago. Right?

Delaney: 44:36

Yep. So you get full CSS variables, you get nesting, you get all these things, and what happens so is for example, if you look at, for example, a material design Mhmm. They'll give you a primary, secondary, tertiary, that kind of thing. Right?

Dominic: 44:50

Yeah. Yeah.

Delaney: 44:51

Create all those kinds of themes. We also do it with using a bunch of color math so that you actually get these really nice gradients. We also generate the the on color and a dim color as well for everything. We automatically generate chart styles or themes as well for you. Because everyone forgets that as soon as you add chart JS or some other thing, now all of a sudden your colors don't match.

Delaney: 45:16

So we make all the colors for charts. We also make code highlighting theme for you as well, dynamically. All this happens so that you have all this built in, which makes it really nice that it's just CSS variables. And the nice part is the stellar part, it's only, like, five k that gets added to your page once ever. And then you can use that in your CSS however you want.

Delaney: 45:38

But the point is, yeah, it just ends up being CSS variables. But the point is that it's a, like, a beautiful design system that you have total control over, and your site doesn't look like anybody else's site, and yet you can make instant changes in an editor and get it live on your site instantly. Wow.

Dominic: 45:56

Yeah. That sounds pretty interesting. I I was I was I was not aware of that, to be frank. That's that that sounds to be that sounds very great. I'm I'm not a fan of Tailwind myself due to the, you know, the just just the amount of classes, if you if you can imagine.

Dominic: 46:11

So when I when I go to another line in my editor, my screen reader is reading the lines. So now Oh, man. Can bump yeah. This this is crazy for me. But, yeah, that that's just me.

Dominic: 46:21

But I know

Delaney: 46:22

that that that it goes away completely. Like, you don't use classes anymore.

Dominic: 46:25

Yeah. That's that that is interesting. And and what about what about this editor? Is is it like I I don't know if you if you saw, you know, old time is it like a a key value that that we have on on the left that you mentioned? So so basically, you have all all the CSS possibilities there?

Delaney: 46:45

So there's things that we do. We do a lot of I come from a background of being a three d artist before I was a developer. And a lot of that stuff is built around this idea of parametric design. So if you've ever heard of Houdini or DaVinci Resolve or Node or these things. And the idea of that is instead of trying to set something up, like, for example, in After Effects, you would set up and make an edit to a page.

Delaney: 47:08

What you would do with this is you would create a set of functions that basically the data flows through. So when you make a small change, it automatically updates. So for example, if you're doing a font size, we you basically have a minimum size, so for a mobile and on a large size screen, and you set the the base font size for those two things. So if you say, hey, I'm gonna be at one rim for this, and on the big one, I'm gonna be at 1.2 rim. And then you say, I want to grow by this function for each update update step.

Delaney: 47:41

Right? So if you have something that's one point at one font size, and the next one's at 1.2, and the next one's at 1.4, and next one's at 1.65. So you can have these curves and stuff. The point is is that you set up those two things, and then you can check with the viewport change to see how it smoothly scales. So you don't have to do any breakpoints.

Delaney: 47:59

That completely goes away. Like, in our system, you don't have to do any breakpoints. Everything's fluid all the time. And the thing is you just set up a couple of these little parametric values, and then we generate out the thousands of lines of math to make it so that that's nice and smooth for you. So it's literally a a you get to play in this editor that gives you all these tools, but you don't have to basically write any CSS to see it

Dominic: 48:21

live. Nice. And this is built with the DataStar, of course. And on on the back end, is it is it like a a Go back end?

Delaney: 48:28

Yeah. It's just like a single Go binary that has all the stuff with a built in one of the pure Go versions of SQLite. So I that's what I use for a lot of this stuff. And it's all cached and built in the back end. It's full data star.

Delaney: 48:42

And it's one of those things where as soon as you see the kinds of stuff it's doing, especially around color, which is very hard to get right. It's doing stuff that Adobe doesn't do, and it's doing stuff that Google doesn't do. So it'll be interesting to see anyone try to recreate what we've done in other approaches. Like, I can't wait to see someone try to do this in React or something.

Dominic: 49:05

And do you think that having a this thing all stood somewhere in the Internet will will be a problem for some people, or or it's not?

Delaney: 49:15

No. The thing is is that it's very like, if we needed to, we can CDN, and we can have separate versions running in different locales. Like, that's not the hard part. The nice part about using an event bus like NATS or any of these other kinds of systems is that this can be hosted in a ton of areas. And also, all the content that we generate is very easy to be CDN able, if that makes sense.

Dominic: 49:36

So Yeah.

Delaney: 49:36

You're live editing. So it means and because the way we do caching and because we're using Go, there's a lot of ways where we're talking about microseconds for updates that normally would take, you know, seconds in other systems.

Dominic: 49:49

That's that's pretty interesting to be frank. You you you seems to be doing a lot of things in in the in the front end. So are are you are you, you know, working at all on on that on on your day to day?

Delaney: 50:01

Yeah. No. That's the thing that it's kinda crazy to me that someone with a full time job and kids and all that stuff is making these strides. It's not because, like, I'm not even a very good developer. I think it's weird that people are just seeming to be solving the wrong problem.

Delaney: 50:17

And all I'm doing is just dogfooding the things that I wish were Yeah. There. And it feels like sometimes it's easier to start with a fresh perspective. Like having someone that's a back end dev that doesn't really have any ties to JavaScript, that's the kind of person that you want writing JavaScript, if that makes sense.

Dominic: 50:35

Yeah. Yeah. I I I understand that. Yeah. For sure.

Delaney: 50:38

So it's the same thing with CSS. Like, I'm not the best CSS. Like, there's people that are way better than me. But if you give a designer like, if you say, hey, I know how to write parametric things. I know how to make the tools that I wanna see.

Delaney: 50:50

And you handed this to a designer or to a team. Now all a sudden, you guys are off like a rocket, literally. So, like, the idea is to make it so that if I'm running into these issues all the time, someone else is too. Like, the this goes back to the whole data star thing. The reason why I didn't do data star for a long time, like, it's three years old now, but I've been thinking about it for, you know, four or five years total, like, couple years before that.

Delaney: 51:14

And I was like, someone's had to have figured this out. Like, it can't be, like, it can't be this easy kind of thing. And the reality is people tend to solve the wrong problem. So I highly recommend to people to, like, scratch your own itch, and you'll probably find a community for whatever you're doing.

Dominic: 51:30

Interesting. Yeah. For sure. For sure. I yeah.

Dominic: 51:34

I'm very eager to see what what it will become and to be frank because I have I've heard that a lot, and I'm in a I'm in a community myself of solopreneur that Adam Waddon was part of. I I you know, I'm there since 2009, so it was way before Tailwind, but he he's the he's the creator of Tailwind, basically. So I I I keep hearing so the it's it's mixed feelings. So the the the having utility classes is is great, but again, the verbosity is it's not just me that find it very verbal. So I'm eager to see what what you will comes out with, to be frank.

Delaney: 52:13

Well, and the thing is what Watham did, especially at the time, was the right answer. Like, it's nothing against Tailwind. It's more that it it's solving a problem that doesn't exist anymore. It's kinda like the way I feel about the stuff that's HTMX is trying to get us back to the two thousands and how we did web dev then. And I'm like, why can't I just use all the modern stuff that's available in the browser, just do it in a faster, simpler way?

Delaney: 52:35

So, like, the same ideas, but it's more of what is the underlying like, I want to go fast, and I still wanna use proper tooling, if that makes sense.

Dominic: 52:45

Yeah. Yeah. Totally. Totally. That sounds good.

Dominic: 52:48

I mean, yeah, I think I think there there will be a lot a lot to see, to be to be honest. Any any closing thought on on DataStore before we wrap up?

Delaney: 53:01

I guess my question to you is, like, what's, like, what what's the thing that you feel like you were missing or something that it hasn't clicked yet or you're like kinda like the query string. You're like, why did you guys take that out? And it's literally, like, I have a reason before behind all the code or any of the choices we've made, and I'm happy to stand by and defend any of those things. Well, not defend, but like, if you have a question of like, hey, why did you guys do this? I would love to hear, like, as you use it more, what are the thought processes with things?

Dominic: 53:31

The the date the replace your URL for was really let's let's say let's say that there's a tab component in a in a page. So what I what I'm doing at the moment is that when when I click on the on the tab, I'm I'm, you know, I'm loading the the HTML from the back end, and I was I was thinking that it could be in a good a good idea to also replace the URL. So that was the use case.

Delaney: 53:58

Right. And in that case, I would absolutely disagree with you. Because and here's why, is that the resource of that page did not change. Your current view of it changed. And to me, that sounds like a user level thing, means that that sounds like a cookie.

Delaney: 54:14

That's already built into the browser. You can have an ID for someone in a cookie, in a well established thing that doesn't change the the resource itself. It doesn't change the like, your address doesn't change whether you're in the house or not, does it?

Dominic: 54:27

When you say can we just define resource first?

Delaney: 54:30

Sure. So when you talk about REST and URLs, you're really talking about representative representative state transfer. And the idea of a resource is a URL that points to, like, an ideal concept. So for example, a house. Right?

Delaney: 54:47

So your page that that tab lives in, like, does the house change if you put a different picture on the wall?

Dominic: 54:55

Well, that's the thing. It it it changed. So I'm I'm in I'm in let's say let's say we have a there's a course. So we we are in a course. So the resource would be the course.

Dominic: 55:08

The there's a tab for settings. There's a tab for, let's say, I don't know, student in in that courses, for example. So those are, in my opinion, two resources.

Delaney: 55:19

I see. Then you you and I completely agree. So what you do is you have a link to settings slash settings, and you have one to slash student. Like, those are different URLs. They're not changes to the parameter.

Delaney: 55:31

You're literally linking to a different page.

Dominic: 55:33

Yeah. But I don't want to refresh the entire page. It's

Delaney: 55:35

just Why?

Dominic: 55:35

It's just

Delaney: 55:36

It's a different page. It's a different resource. If you have something like view transitions, you are literally able to make that smooth transition without any extra effort. Like, with view transitions, you can literally, like, do cross fades between those things if you wanted to, or change content, or move things around. But they are separate resources.

Dominic: 55:57

Yeah. I'm I'm I'm not sure. So what what do you mean by view transition? So is it is it the data start thing?

Delaney: 56:02

No. Oh, so okay. No. This is just built in see, that's the one thing about data start is it forces you to learn what the browser can do.

Dominic: 56:08

Okay. Yeah.

Delaney: 56:08

Okay. So if you don't know about view transitions, prepare to have your mind blown. Okay. So you can add one navigation auto thing to your CSS, and then whenever you change web pages, it automatically does cross phase and transition between those things. Just natively.

Delaney: 56:23

Like, you just get that for free. The next thing you can do is you can basically set view transition names on certain parts of your page. So like, let's say the settings thing has a main container, and then your other page also has container. If you do a view transition between those two things, it'll actually like, do a morph of those two elements on the page. So it actually will look like it's the exact same element moving around even though it didn't.

Delaney: 56:47

It actually does a GPU level accelerated screenshot of each of the things and morphs between them for you automatically. And this is built into the browser.

Dominic: 56:55

This is a CSS property or or Yes.

Delaney: 56:58

Yeah. There's a transition name and there's a transition. I highly recommend you look at these things because the thing is, DataStar is built for the modern browser, not for, you know, like, browser of the 2,000. So these things are built in natively. So there's a thing called data dash view dash transition in Pro, but you can also do it by hand.

Delaney: 57:14

It just takes a little bit more work. The the ideas of your transition means that you can have completely independent resources. And if you name and give IDs to things with proper names, you can transition between them better than you can with a single page app.

Dominic: 57:28

That's interesting. So where where would I find all these things? Let's say let's say I've I've missed a lot in the in the last ten years, potentially.

Delaney: 57:38

So the Mozilla Developer Network MDN or go to Google's blog posts or any of these things. Like, these are just things that are in the browser. Like, the whole point of Datastar is not to hide or to try to obfuscate what the browser's capable of. Just use browser things. And if it isn't capable of something, then DataStar is there to help you or make it more declarative.

Delaney: 57:58

That's it. So the thing is there's things that are just you just if that's your problem, that's not a DataStar problem. That is a like, you haven't kept up on what the browser's doing.

Dominic: 58:07

Oh, yeah. I'm not I think that's

Delaney: 58:09

We're happily here to help you do that. And that's where a lot of times people will ask for new plugins or features and be like, you don't want that and you don't need it. So that's why data stars are small, because a lot of the time, the browser already has things native for these kinds of things. And in your case, it would be so much simpler to use view transitions and actually have separate resources, and it would also make your handlers so much simpler. Guaranteed.

Dominic: 58:33

Yeah. Well, I was already planning to have different handlers, so that that's not really the point. But, yeah, I I was I was going to do and not not even use server sent even for that as well. Just, you know, just just return the like you said, the main content. So in my head, it was way simpler to just return what changed other than refreshing the entire page.

Dominic: 58:56

Just

Delaney: 58:56

No. See, it's actually easier to send just the whole page and let DataStar deal with That's interesting. Because you just don't have to have those checks and ifs and do, like, out of bound things. Like, we can do that, and we're very fast. But because of the way we do compression and the way that if you just use the DataStar SDK that I made and you do with compression, now all of sudden, you can just render the whole page contents exactly how you want it to be and just let us deal with it, and it will be as small, if not smaller, over the wire.

Dominic: 59:26

Very interesting. Yeah. Okay. So I will need to be careful with my old the that that you know, I'm I should not be alone in in that in that Ben Wagon, to be frank. You know, if when back when back end people start to do, you know, more hypermedia things and we in in my case, you know, I I started doing HTML, you know, way way way back in in early two thousand.

Dominic: 59:49

But yeah, I will I will admit that I haven't really updated myself.

Delaney: 59:55

Well, and that's the like, we're here we have a Discord. We're here to help. Like, we want people to be up to date. But also the thing is, if you do it our way, it's very simple. You create a you basically have someone go to a link of a resource, you keep a stream open of the current content of that resource, and then you send commands to try to make changes.

Delaney: 01:00:16

That's it. You're done. Like, that's literally all there is to doing Datastar stuff. And you just send the content of the page and let data star and the network figure it out. And we end up being the smallest and the fastest to do this.

Delaney: 01:00:28

So the the the thing is it's not just a thing of it's simpler for the developer. It's also if you actually look at the metrics and flame graphs and what we do, we are just orders of magnitude faster than other things, which is not saying that we're great. It's saying that everyone else needs to get caught up.

Dominic: 01:00:44

Yeah. Oh, yeah. Yeah. That's pretty interesting. Yeah.

Dominic: 01:00:48

It it really really fits well with with the speed of Go, to be to be honest. Yeah. It seems to be a

Delaney: 01:00:53

Yeah. 100%. Go is definitely I mean, I obviously love Go for this kind of stuff. And it is kind of a weird thing of I've also been flirting a lot with Odin and some of the like, doing stuff in C. But the irony is that Go is faster than your network in almost all situations.

Delaney: 01:01:08

It's very hard to saturate a network with a Go application. So that's kind of where it's it is super convenient to build these kinds of things with it.

Dominic: 01:01:16

Yeah. That's crazy. What what are you doing with with Odin? I'm I'm just curious now.

Delaney: 01:01:21

I've been flirting with making a database for years, and Wow. Like, part of it's done in in Go right now, and was looking at, like, does it make sense to do in Odin as well? So the the thing is that, like, I actually think Odin is amazing because it's like Go minus minus. Like, it's it's really feels really nice for people that are Go developers, but you don't have the see Go issues that you normally have. Yeah.

Delaney: 01:01:44

But you also don't get closures and all the niceties of Go. So, like, that's an interesting world to, like, I'm very interested in. But for most web devs and most people doing most things, man, Go is just To me, it's like a Toyota Tacoma or a Hilux where you just can't kill it. Like, it just it's it's just a work truck that gets the job done. Yeah.

Delaney: 01:02:05

It's not pretty, but who cares? It gets you to where you need to go, and it never falls over. So, like, yeah, I I'm still very much a a GoDev at at at my heart.

Dominic: 01:02:14

Yeah. Yeah. Same. I I I started the dabble a little bit in in Gleam lately, which I really, really enjoy. Mhmm.

Dominic: 01:02:20

But again I know.

Delaney: 01:02:21

It it's funny. You go and you go play with these other toy, and then you're

Dominic: 01:02:25

like Yeah.

Delaney: 01:02:25

Yeah, but Go just works.

Dominic: 01:02:26

Yeah. Exactly.

Delaney: 01:02:29

I also the one of the things that's always kind of amazing, because I've been using Go since like the very early dot one or .1.1 time. The the thing is is that, man, the ecosystem has gotten so good that you can find someone that has done some kind of project built around what you're trying to do. And since everyone's code looks the same because of GoFund Yeah. Stuff. Like, it is so nice from an act like, able to get up and running and to be able to understand an idea.

Delaney: 01:02:54

It's so nice to be able to share so much code. Whereas, yeah, when you go to a lower level language or something, like, the community just the ecosystem's not there to the same degree. So it is kind of a it's a harder slog for sure.

Dominic: 01:03:06

Interesting. Yeah. I can I can imagine that? Yeah. I'm I'm I'm still unable to to get started with Rust, to be frank.

Dominic: 01:03:12

I I think Go ruin me ruin me a little bit and make me less patient with myself to to start a a more complex language, to be frank.

Delaney: 01:03:23

Well, my thing with Rust is more that it saves you from problems that you don't really have. And what I mean by that

Dominic: 01:03:29

is Well, it it depends what you do.

Delaney: 01:03:31

Yeah. I'm just saying that people think that it's, like memory safe, and there are certain things that are memory safe. But if you look, for example, if you come from game development at all, you'll know that in Rust, there's this really popular thing called Bevy. And Bevy is a very good game engine. It's built around ECS.

Delaney: 01:03:44

It has all these things, but it does generational index handlers, which is literally built around the idea of completely bypassing the the borrow checker. So most interesting things that happen in Rust have nothing to do with the thing. It's trying to save you from problems that you don't have in most cases. And that's the thing is that you can have safe languages in the same thing of like having proper ranges and slices and stuff. Well, Zig and Odin have those things.

Delaney: 01:04:10

Like, the thing is that what they're saving you from isn't what I think most problems are. It just depends on how you do things. So, yeah, I I'm not a huge fan of Rust, but, you know, we have a huge Rust community within Datastar and it's people are doing crazy fast things with it. So, you know, to each their own. That's kind of the value of going with this approach of having an agnostic back end framework, which I've never seen before.

Dominic: 01:04:35

Right. Yeah. Yeah. I agree. This is this is pretty nice.

Dominic: 01:04:40

Alright. Thank you. Thank you, Delaney. That's what that was that was extremely I I I really enjoy hard talks, to be to be frank. I I hope I hope you will you will come back in maybe six or eight months, something like that.

Delaney: 01:04:52

Yeah. Hopefully, I'll be in the desert by then. Yeah. That's that's that's the hope. Well, I live in the desert now.

Delaney: 01:04:57

But, like, it'll be interesting to see once you play with it some more, especially not when Rocket comes out. And then we'll be doing Stellar, and then Stellar UI will be a bunch of library of UI elements and stuff. So we'll have that in the pro stuff as well, which means that you might be able to just drop in and have really nice looking stuff and then also still be able to edit and change it to your heart's delight. Yeah.

Dominic: 01:05:21

Yeah. Because I'm a Yeah. I'm a tell when UI can pull a client myself, customer. Yep. But, yeah, again, that that's that's hard with me.

Delaney: 01:05:30

But No. I can imagine well, imagine if you could have all those conveniences but not have any of the class craziness.

Dominic: 01:05:37

Yeah. Music to my ears, man. Let's yeah. Let's let's talk later when I when I when I try your your things. But so far, the the only thing before we we we close, when I do when I do s s e dot patch and I do EL, and it's always patch elements go or patch go elements.

Delaney: 01:06:00

Yes.

Dominic: 01:06:00

Yeah. That that's the only thing because I I do tab.

Delaney: 01:06:04

But Would you rather be

Dominic: 01:06:07

No. It's just that I I tab too quickly and I yeah. My screen reader is not quick enough for me, so now I I I don't use the the right function, but that's funny.

Delaney: 01:06:16

Oh, well, if if that's the worst part of your day Yeah. With Datastar, I guess that we're doing some things right. So Yeah. All good. Yeah, if have suggestions, or if you have a better way to do that, or we can make a special version just for you that is PE for patch elements.

Delaney: 01:06:33

That's for a screen reader I'm on board with making a fork that literally solves those problems. Because there is something to be said about how much a disability can actually really affect your ability to think through things. Have severe tinnitus, and trying to have a conversation with someone can be really challenging sometimes if I don't have headphones on and can, you know, isolate it. And I'm I can only imagine the the the kinds of things you have to like, it's a cognitive load just to be able to hit tab. So I 100%, if there's something we can do to help you there, like, let us know because we we are here to help.

Delaney: 01:07:10

Like, this is a pay it forward kinda thing. Yeah. So please let us know if we can help.

Dominic: 01:07:14

Very cool. Thanks.

Delaney: 01:07:16

Yeah. Absolutely.

Dominic: 01:07:17

Alright. Alright. Thank you so much for for this this talk.

Delaney: 01:07:20

Yeah. Thank you. Alright. Bye. Bye.