Subscribe
Share
Share
Embed
Join me while I learn HTMX and talk at you about it
Twitter: @htmxlabs
Alright. So thank you for joining me today, Delaney. Absolutely.
Speaker 2:Happy to
Speaker 1:And you're coming off, doing a talk, Right? At in at Utah JS, was it?
Speaker 2:Yeah. So a little while back, they were looking for, speakers and they asked Carson to come speak. And he's they said, hey. Is there anybody else that, in here? And she's like, yeah.
Speaker 2:You should talk to Delaney. Completely disagrees with me on the details. So,
Speaker 1:that's
Speaker 2:that's very magnanimous of person to say, yeah. Like, bring on other voices that disagree. So
Speaker 1:Yeah. So so let's talk about that disagreement. So but you're you're in the hypermedia world, you would say. Right?
Speaker 2:Yeah. A 100%. So a little bit of background. I do a bunch of real time dashboard stuff, from, very large systems, military applications, all that kind of stuff. And, I've been kind of bit by, doing it the SPA way for a long time, and I really dove into the hypermedia as a concept.
Speaker 2:And I think, Carson's an amazing thing in that space to really bring it to the forefront, and I wanted to push it farther than than he cares to. So that's yeah. A 100%.
Speaker 1:Gotcha. Okay. So so when you say farther so, you know, I'll just I'll give my, like, basic understanding of what you're talking about, first of all. So so, you know, Carson, Gross and and HTMX in general, the way I've heard it described is kind of, adding sort of the fundamental building blocks of hypermedia as it should have been with HTML. And it's it's more of a low level system of controls that sort of gives people the access that they've sort of only been able to before with JavaScript.
Speaker 1:Whether it's vanilla JavaScript, or a framework, or, you know, jQuery. All these kind of ways of doing AJAX calls. So there's these sort of basic HTTP protocol, hypertext protocol, systems that in the HTML opinion, or maybe in Carson's opinion, or you know, that are incomplete in HTML. So I think my understanding of the goal has been to provide some of those and and make hypertext and hypermedia kind of a more viable and more complete solution for just HTML. Does that sound kinda Yeah.
Speaker 1:That's perfectly accurate.
Speaker 2:In fact, I would go a step further in that, HMX is really trying to solve the problems with hypermedia in 1999. Like, if you could go back in time, it's solving that problem, and it's solving it in a pretty, robust way. And the the difference comes into the details and into, implementation and also, like a style of coding that's that's just a different style. Like, it's not to say that that's wrong. It's it's for example, I think forms are a HTML got a lot of things right, but forms are wrong.
Speaker 2:And in that, they basically, you have a bunch of stuff that's done at a very, flat level. And if you're doing nested forms or just kinda more complicated things, the idea of, like, adjacent object and tying that to a form is a nightmare. And there's literally no reason for that to happen. It's one of those there's certain things that we can't go back and fix. And I think HMX is a trying to fix what was already there as opposed to like, hey, we can do this in a better way.
Speaker 1:Gotcha. I mean, yeah, I'll just, you know, forms as a long time developer, just on the basic level, not being able to put a form within a form, or the kind of confusion that happens along with that. And, you know, everybody knows kind of the way forms work nowadays. They need to be dynamic. You're not just creating a set of inputs and clicking submit and waiting for the response.
Speaker 1:You know, you're doing lookups, you're doing validations, you're doing checks. So do you so you see htmx as kind of, you know, working at that level. The goal there has been to kind of fix problems like that?
Speaker 2:Well, and I in fact, I I think, part of the talk that I gave was basically saying, hey. I may disagree with the, way that things are done in HTMX, but I think the best thing that can possibly come out of it is the trip check, proposals, which are basically, let's fix buttons and links and other things to be, like, at least useful in the way that they should be. I think if nothing else, HDMX slowly fading away because things like the proposal are in place is a good thing for everyone. I think Carson would agree with that. Is that, like, over time, HDMX should be able to get smaller and smaller because it's very much the same things that happen with copy script, a while ago where all the good ideas of copy script basically went to ESX.
Speaker 2:So, the hope is is that things like copy script don't exist because, like, you don't need it because it's built into the standard. I feel like a lot of the things that HTMLX provides should already be there. So it's not, I'm more focused on the further reaching things of, like, what hypermedia can do as opposed to what hypermedia has done, if that makes
Speaker 1:sense. No. Okay. So I'm, you know, you have peaked my curiosity here. So I don't know.
Speaker 1:Was your talk focused on things that hypermedia can do or was it, you know, what was it focused on?
Speaker 2:Yeah. So, kind of the gist of the talk is I actually been, doing I'm now officially
Speaker 1:a gray beard. So, Hey. Welcome to the collab here. It's great.
Speaker 2:So I've been doing this stuff, for probably about a little over 25 years. And so I've never seen myself as a JavaScript or a front end guy. I originally started as a 3 d artist and then started writing more and more tools, for my own stuff because I couldn't get programmer to help me. So I started writing plugins and started getting it looked. So I actually came from it from, like, a c and c plus plus then Python because that helped interact with tools a little quicker.
Speaker 2:So I kinda came from the game dev side of the world. And then slowly over time, I found that a lot of people aren't doing full stack. They really don't understand the UX and design stuff and not just front end and back end, but, like, really understanding the whole product. So that's kinda how I've always come to, solve problems. And so I drink the spa kool aid heavy because that's the way I got things done.
Speaker 2:And I've done some pretty crazy projects in that space, with real time things handling millions of updates a second, like crazy things. And I basically the whole talk was me saying, I think we've all got it wrong, especially me. Like, by ignoring what hypermedia is and what it could do, we've missed the train on what's possible in hypermedia. But at the same time, another part of the talk, it's basically media stealing old man yelling clouds, is saying, I think h t max is wrong too. Because it's not so much the library, but it's the way that people are using it and the way that it's being explained.
Speaker 2:Because it's seen as a diametric opposition, like, react versus h t max. And the problem is I think both of them are wrong for different reason. That's basically what the talk was about.
Speaker 1:Interesting. Okay. So so actually let me just ask about the the, you know, game dev and and three d stuff for a second. So I've always, you know, I've done some some 3 d work as well, a little bit of game stuff. And I've always thought it was just strange how the game development world has these problems that they've solved.
Speaker 1:That's like thousands of people concurrently, you know, playing with millisecond response times at the same time over this. And I'm here in the web development world, and I'm solving, you know, 5 people working on a team seeing the same thing within a couple seconds. Like, it's just like the scale of the expectations and, you know, I don't even know what that is because I felt like I was pretty decent at both, but somehow it just feels like the game development world is on another level in terms of how they're accessing data and storing thing. I don't even know what the difference is even though I've done both.
Speaker 2:And this is kind of one thing that was interesting at at the talk. I was talking, you know, in the, side room and stuff with someone else. I was going, yeah. You know, I like this stack. I've kinda it's kind of a higher level stack.
Speaker 2:It's go and data star and that's working. And they're like like the idea that I think go is a very high level, like easy, almost a scripting level thing. People were laughing. They're like, that's so much faster than what I'm using. It's like, it's orders of magnitude faster and it's 30 times less memory than a node app, for example.
Speaker 2:They just don't I don't think people are aware of what, computers are capable of. And the thing is I think they blame like, they think that hypermedia is the part that's the problem. But, the thing that's kind of insightful, I think, for most people is there's nothing faster you can do in a browser than send the c plus plus what's called turbofan, the part that actually takes your code and turns it into, like, c plus plus classes and does all that kind of stuff. You there's nothing faster than heading it a big string of HTML. Like it is built for that idea.
Speaker 2:And so the more you just send it strings, the irony is the faster your code's gonna be. And I think that's lost on a lot of people when they get into the into the weeds. And really understanding the what it's capable of. Like when I'm doing stuff in, Hypermedia, I did it. There was a example that was on Reddit a little while ago where someone made a snake game in HTMX and they were like showing, wow, look at this.
Speaker 2:This is like 10 frames a second. And I said, you know, I think I could do it a little bit better than that. And I was in the microseconds for updates. In fact, you can go I found out that you cannot send to a browser faster so faster than this micro task, updates, because it basically falls over. So you can break the browser, with trying to update 2 paths.
Speaker 2:So you can do this stuff in microseconds, not just milliseconds. And there's a lot of capability we're leaving on the floor.
Speaker 1:So how are so I guess, what do you what do you mean by that? I mean, are you talking like are you is this sockets specifically or like, you know, I guess I'm just like big picture, you know, I'm thinking of sending an AJAX request is kind of my baseline for what what I'm thinking of. And I don't do a lot with sockets just because I found them unreliable, I guess. And and maybe that's just my understanding of it. No.
Speaker 2:A 100%. The one of the things with sockets that is really hard, because I've done some pretty big, military applications using sockets, is that you are completely risk it's basically you're you're paying that handshake for every so you can't just open them up willy nilly. You have to, like, open them up. There's a handshake that happens. You make that connection.
Speaker 2:And if it goes away for any reason, you're you're on your own. If you have any kind of state, you're on your own. If you all of a sudden have a complex set of, connection points, you have to do multiplexing on your own. You have to do routing on your own. You have to do all these things yourself, and then they don't interact with cookies or any of the other things.
Speaker 2:So it's a completely different paradigm, and it's basically do a bunch of setup, get a raw socket, good luck. And there's value to that, but the problem is with the way that modern connections are, especially with firewalls and all that kind of stuff. It the web is not built with that in mind. So you're playing against the grain. Whereas the what I'm the basically so data start itself, I know we haven't really talked about data server specifically, but data start just a library that's 300 lines long.
Speaker 2:And all it's doing is taking, things that making it so you can do your own declarative plugins and turning that into little snippets of, JavaScript. And you you sprinkle these in place. In fact, it originally started as an HTMX port to be more modular. That's literally all it was. It's me trying to make HTMX modular so you could pick and choose things.
Speaker 2:And so with the way that I did my stuff, because I work in real time dashboard and real time event stuff where things can be coming from 1,000,000 different places. Literally, millions. And, the thing that I did there is I made every single thing a SSE event. And service and events, the thing is people think that they're like us website, but they're not. They're just regular HTTP get, in my version, there's post, patch, put, delete.
Speaker 2:So you have all the verbs. And Yep. And and all you're doing is you're setting a header at the beginning saying, hey. This is an event stream, and I may send down 1 or 1 or a 1000000 updates. So when you do the equivalent of h x get, I can do an entire UI with millions of things going on and have one single get open.
Speaker 2:And then I can change any part of the page at any point. So it's kinda like an out of bound, but it's it literally is doing it at any point in time. So you can have these things being changing at any point of the screen, and it's dead easy. Same thing happens with a a post. So, for example, when you do a an HEC post, you're getting back a response.
Speaker 2:Right? And it's gonna update some fragments. What if, for example, you're filling out a a form and you're saying, hey, this form now affects 10 different agencies or 20 different micro servers in the back end. And I wanna know the current state of all those things in a flow. Well, I can get that information instantly and know exactly which server is hitting and all that stuff.
Speaker 2:So I can be updating the page while that response is still being coming in flight. So I can start updating the page immediately as as opposed to waiting for a response. So my big thing is that I think HMX's style of polling made sense in 1999. It makes zero sense today because we have things built into the browser, like SCC that automatically does reconnect, automatically can do event tracking, can do all these smart things. Why aren't you guys using this?
Speaker 1:Alright. So so you gotta you gotta educate me a little bit on this.
Speaker 2:Sure. Absolutely. Because now
Speaker 1:I'm starting to just feel kind of ignorant about it. Okay. So SSE. Yeah.
Speaker 2:So servers and events. So, you know how when you send down a, a bit of content, like, you send an HTML fragment. Your server, wherever whatever language you're in, you're sending down an application or, a content h text dash HTML. Right? Is the content type.
Speaker 1:Yep.
Speaker 2:And then you start sending down the content, and then you close that connection. Right? Like, that's what's happening at the server level.
Speaker 1:Yep.
Speaker 2:So what an SSE event is, you're saying I'm setting the content type to text dash event stream. K? That's the the type. And then what happens is there's a set of new there's a little protocol that's just like you send it the events, colon, and then the event type, and then you send, like, an ID, and then you send the data, and then you send a double new line. You now know the entire SSC spec.
Speaker 2:So you just keep doing that until you close the connection. So you can send so instead of wait and then basic have you ever done something with a console where you basically want to update the console and then you have to write flush? I don't know if you've ever done yeah. So it's the same kind of thing. You're just saying to the network driver that say, hey.
Speaker 2:The content isn't completely ready yet, but I wanna start sending events immediately. I only wanna send this chunk to the person immediately. But that chunk is a complete message. So you're just giving it chunks of the response as you have them. So that's the that's the entire spec.
Speaker 2:It's just a text based spec using some new lines, and you just send down things. So in the case of data star, you can send down fragments like you can in HTML, but you can also send down direct signal, effects. So you can actually affect DataStar has the concept of reactive signals as a as a kind of a default thing. So you can do everything you can do in Alpine, everything you do in HTML. It's less code, it's smaller, and it's faster.
Speaker 1:So this is a fascinating use of hypermedia to me because one of the big problems that I have and that I see is like one of the reasons I'm kind of bullish long term on hypermedia is that once you have this virtual DOM in place, which is every single one, even the ones that I like of these sort of front end frameworks, you have to have you have to maintain a separate virtual DOM. And then you're usually updating that, you know, with JSON. It doesn't really make sense to just take text and HTML and pop them up there. And so the effect of this is a few things. You have to have the full data really before you start messing with adding stuff to the DOM, and that just adds up over time in memory.
Speaker 1:It adds up in slow thing, you know, it just it slows things down and it stops you from doing what you've been able to do from the nineties, which is go to a gigantic page of data and immediately see the first lines because that's what HTML can give you. And I think, you know, they've moved so much into the virtual DOM that it's basically impossible. And this, what you're talking about, the SSC, I mean this sounds like maybe it's already sort of doing that, and I haven't really been paying attention when you go to a page and you, you know, it starts streaming the data, you know, it shows you the HTML, and it's still coming in. So maybe this has sort of already been happening. I just haven't really been thinking about it like that.
Speaker 1:But I mean, this gives you the option for just a whole another it sounds you know, what you're describing is kind of a whole another level of speed also.
Speaker 2:Yeah. From a framework perspective, I think it's I have an essay on the DSR side of, like, hey. I'm going SSC all the way. Because before it was not in HMX is an extension fact. Originally, Carson and I talked about, like, fixing the extension.
Speaker 2:But the thing is I have like, there's a bunch of invariants and stuff in the way that extensions were built, at least back then, that I I'm not smart enough to figure out. I don't think my myself is a JavaScript developer. That's why you'll like, in fact, one of the big arguments that you saw in the HMX community, there's an entire channel devoted to me saying, Hey guys, like I'm running into issues. I don't understand what's going on. And I wrote, we wrote the entire thing in TypeScript just to get some idea of this, the invariance and the types and stuff.
Speaker 2:And yeah, that was not accepted as a as even an alternative, like an option. But I found a bunch of errors and things, and I actually started porting it into, the data center where I'm doing things. And I found that, you know, a lot of this is you get into tag explosion with the way HTMX works. Like, for example, like, it used to be just HX post, HX get, and it like, HX valves maybe. Like, there wasn't that many or HX on kind of thing.
Speaker 2:But as it's been around because it's been around for quite a few years now, and it's you're just getting more and more tags whereas I think it's you'd starting to have to learn more and more, which is good for your podcast. Right? Like, there's more stuff to learn. But in the case of data star, there's only there's a total of 11 tags possible so far, and I've only used 2 or 3 for entire real time applications. It's just not necessary because once you have reactive signals and you think of it at a, like, more of a first principles thing of, like, what do I have to do on the page and how can I make that declarative?
Speaker 2:It changes the game quite a bit.
Speaker 1:Okay. So so let's let me just try to think how this how this is working. So this is a data dash star dot dev. Right? Yeah.
Speaker 2:That's the website. It's yeah. It's literally just taking the the data dash attributes. Like, it's literally called data dash star in the spec. And you're just taking things that you would have to write by hand and making it so that it's easy to write plug ins to do the same thing as Alpine's doing or do the same kind of thing that h t m max doing or build a plop in web it's basically a way to make everything declarative.
Speaker 2:That's really all it's doing.
Speaker 1:So so let me get specific here because you're talking about sort of using replacing different tags because they're no longer needed. So I mean just kind of a regular thing that I might do is have an HX get with a target, and a swap. Like a type of swap. So I want to replace the whole target for instance. Yep.
Speaker 1:Okay now let's get more so I'll go a little so like the swap is, you know, now I'm forgetting the names of them but after We
Speaker 2:can go directly off of that. There's enough to go off of there to tell you the difference between HMX and DataStar. At least from again, these are plugins that are kind of the default right now, and you could mix and match any plugins you want. But the the ones that I ran into are the ones that are the default right now. So okay.
Speaker 2:So for example, if you did a what what's triggering that? Is it an on click? Is it getting online? Is it like what what what do you want you want to be in HX? Like click
Speaker 1:Let's just let's make it, when it shows up on the screen or or when the page loads, whichever one kinda makes sense for you.
Speaker 2:So, we have there's there's a data dash on plugin. Right? So it does all the things that are built into the browser. So if you have, like, online and offline and sync, there's a there's a bunch of stuff that's built into the browser. So basically, all of those are data dash on click, data dash on key down, all that kind of stuff.
Speaker 2:So there is a couple of special ones. There's one called data dash on store change. So if your signals like, if something in your signal changes, you can trigger off that. And there's also a data on load. So you do the same thing of data on load, and you put in there and you say, basically, in this case, it'd be dollar dollar get, and then you do the input.
Speaker 2:And the dollar dollar just means that it's a, sandbox action. So it's not running eval on these commands. It's actually, a sandbox function and charter. Same thing that Alpine does, in fact. I I looked at their code.
Speaker 2:It's brilliant. I just wanted to expose it so anybody could have their own actions easily. So you just do go do an action. You don't put the target. You don't do any of that because I think that that's wrong.
Speaker 2:And the reason why I think it's wrong is because the server is gonna know exactly what to do with that page. And depending on what's going on, you might be updating multiple parts of the page. So when you do an SSE event, part of the the response back is, here's the fragment, and here's where I want it to change on the page. And here the morphing and all that stuff happens from the server side. Because I think that putting it into the thing is fine if you're doing pulling.
Speaker 2:But as soon as you get rid of pulling, and you say, the server's in charge of what's gonna get updated on the page. That's the thing. That those are the kind of differences where I think I just disagree with the h t m x is that that should come from the server side. It has nothing to do with your template at all.
Speaker 1:Okay. So well well, just like logistically, how do you how does how do you say on your server where it's going? Are you matching IDs?
Speaker 2:So yeah. In general, you tend to do IDs, but you can have basically, part of that, because when you get a SSC event, you have an event type, and then you have data. Well, on the data lines, you can have I have a thing called selector, and you can say what your you know, what's what area of the page you wanna update. So it can be any kind of query selector that you want. And if you leave that off, it uses the ID of the fragment.
Speaker 2:So most of the time you just leave that off and you get the idea of the fragment. And you can say how you want to morph is another data line. And you can say, I want it to, use app append after replace all that kind of stuff. But also, my stuff comes with idiomork as the default, which I know you did a ton of Carson on too long ago where he's like, I really wanted to add it in, but it's like too big and it's too crazy. Yeah.
Speaker 2:I added it in because it's the right answer. So it uses any more. So if you don't if you just send a fragment down and it has an ID, it already knows on where on the page to update. It already is gonna use more and do all the right things. So your your actual snippets are smaller and more elegant, and you don't have to almost unless you're do a pending to a list or deleting an item, that's it.
Speaker 2:You you basically almost never need any of the other tags. They're completely useless in my mind. Because if you build yourself correctly, you don't need to do any of that work. You have the mental model of I'm updating this ID, and it automatically is gonna morph and do all the right things.
Speaker 1:So it almost sounds like and we actually did yeah. We mentioned this a little bit, talking about with Carson, like Ideomorph but also you know HX Swap OOB, which really I mean this does sound like the mental model of you're basically doing HX Swap OOB as your primary, you know, form of communication and and updating. Does that sound
Speaker 2:that's accurate. And that's what you should be doing. Because the thing is, as you get into more complicated apps, especially, one of the places where that that data starts getting used right now, there's a a military project. And what's interesting about that is they actually interacting with an old school Amber app. And that is a really hard thing to do to add something new in and try to fix that.
Speaker 2:So what they're doing is they're it's incredibly good as a brand in brownfield. As long as I can get an ID to anything on the page, it doesn't matter if it's an ember app or not. They can directly affect that thing because all their templating and all this stuff was done in ember. But great. So I can do my updates and hook right into their stuff.
Speaker 2:So I think the what's considered out of bounds is the wrong like, because that's treated as a special flower in HMX, and I think that's completely wrong. And the part of that is it makes total sense if you're doing polling and you're sitting down whole big fragments at a time as opposed to updating any part of the page at any time. So, I'm glad to see that the the talks are there, but it's already been solved, and it's already done, and it's smaller than the HTML.
Speaker 1:Right. So okay. So what what is like a I'm just trying to like get like a full picture here. Like you so let's maybe we can find an example of like we could just use a dashboard, because that sounds like you know you're working with real time dashboards. This is kind of a really good use case of this where you have different data on the page.
Speaker 1:So you would have and what's your what's your primary like back end language? Go, you said?
Speaker 2:Yeah. So, a a friend who's very cheeky at at work and has made a website called gonads.net. So it's go, NATS, and DataStar. I think that combination is absolutely a powerhouse because all of them are built with reactivity in mind and performance. And I think it's a good blend of performance to ease of use.
Speaker 2:I I I love c, but it is harder to get right. So I think that's a good combination that's really event driven and push based as opposed to poll based, which is what most people think of when they think of hypermedia. They think of polling constantly, and I think that that's just a missed understanding of what it's capable of.
Speaker 1:Okay. So so you would, you know, build templates with your sort of, you know, primary, well, first of all, do you build a shell and just push that up and then sort of open the connection and then start pushing stuff from the server?
Speaker 2:Most of the time what I'll do is basically, yeah, do that initial page load, which is just a regular, you know, HTTP thing. And the first thing on it is data on load. Go get all the like, set me up with updates. And then I'll literally update the entire page, including adding and removing, non model UIs on the fly.
Speaker 1:So yeah. And you are you sort of opening one single connection that's like, this is the connection that's basically gonna stay open, or is it kind of like you you keep it open until you push that update and then you may be like, is there some sort of opening of new connections or how does that work?
Speaker 2:You can use data store exactly like you use HMX, but I tend to believe really heavily in the CQRS style. And I don't know if that's a term that you're familiar with. It's command query responsibility segregation. And all it's saying is that, look, your writes are completely different than your reads. Because you might have a write that goes and does 20 different things, and it may affect this view.
Speaker 2:So if I'm doing a 3 d engine, I will it'll affect the 3 d view, but it also could have an entirely different view that is just an SVG that's, you know, the current mini map or something like that. So the idea is you're separating your writes from your reads. And in the case of dashboards, I tend to have one open connection that basically is sending the updates that hooks into the event bus of the back end. So I can get stuff from literally a 1000000 different places, and then I can queue that up and then decide to send down a fragment or send down things at piece mail. But the whole idea is when I send commands, it doesn't matter if that command came from the browser, from a button clip, or from a new event in the event bus, or from the command line doing a bunch of testing.
Speaker 2:It doesn't matter. All the events, it's gonna update the page independently. And that talk was doing doing a lot of that kind of stuff where I was literally, updating, hypermedia at a 144 frames per second, and sending down every single element of an entire 3 d scene with thousands of things going on in real time. And it was taking 2% of the CPU. So, like, there's capabilities here that I just don't think people are aware of.
Speaker 2:And that's that's my whole thing is I wanna pay it forward so people are aware that you can do this kind of stuff.
Speaker 1:Yeah. I mean I'll just say like I was not I'm not aware of this at all. So that's one of the reasons I wanted to, you know, you were talking about pushing the boundaries of hypermedia. Yeah. And I'm like, I'm very interested in pushing the boundaries because there's people who kind of don't think hypermedia can handle drop downs, you know?
Speaker 1:I mean, it's like I'm just kinda like obviously that's wrong, but like I see it online all the time. Like
Speaker 2:Well, and there's an exact another example that came up. One actually because we both went to the the Big Sky Conference.
Speaker 1:Right.
Speaker 2:And we didn't run into each other. But, one of the interesting ones that really ground my gears in fact, I talked to Nate for quite a while after the thing when we had dinner that night at the after party was he did a talk with, another person, John, that was abusing hypermedia. And he was saying Right. Here's all the things you should never That
Speaker 1:was fun. Yeah.
Speaker 2:No. It wasn't. I wasn't. That's the thing is I actually got really upset by it. And then not for the reason that you think.
Speaker 2:Is that I think it's the first thing he said is things that you should never do with hypermedia. This is stupid, and that's the fun of it. But my thing is use things you should never do with h t m x. Because the things that he thinks are a joke are things that I'm doing at orders of magnitude higher volume than he is already. Like I've been doing it for at least a year of using it for those kinds of things.
Speaker 2:So doodling a flappy bird is not a problem. Interesting things in microseconds is not the issue. So I actually take not take offense, but I think that people are,
Speaker 1:get it.
Speaker 2:Yeah. I take umbers to it because the thing is I I I see that the HTMX community is possibly going down the same route of spas of not understanding the underlying technology and not understanding its place. And they're gonna get themselves into a bad place where they're like, people are gonna throw out the baby with the bathwater. These great ideas of hypermedia and having hideous and all these ideas, and they're equating it to bad performance and polling. And that's just wrong.
Speaker 2:It's just wrong. So it's I've, you know, joked with Nate in the past on some stuff, but I want to stop that as early as possible. And that's kinda why, you know, reaching out and talking and stuff because there's some brilliant things to do here and has nothing to do with, like, Ryan Florence saying I can destroy your your spot app and or your your HD max app in a few minutes. You can't build break a data star one if that's, like, if the intent because the thing is I'm taking the same ideas of Alpine and all this. I'm just making it declarative.
Speaker 2:I think the declarative part, we all can agree is a better way because it doesn't matter where the back end is getting it. It doesn't matter how it gets to that. You're getting to a known state, and you can render that on screen. Like, there's a beauty to that. And I I don't want us to lose that beauty for some implementation differences between how Carson does and how I do it.
Speaker 1:Yeah. So so, like, big picture, you know, the the the talk that you're talking about, the way they were doing it was, you know, basically polling, sending, you know, I don't know how many requests per second, but if it works out to 10 frames a second or whatever. So they were just like firing off a bunch of individual AJAX requests and getting the data back and trying to and so, you know, this on a okay network, like, they sort of showed, like, okay, you can sort of do that, and the game is somewhat playable, but obviously you should never do that. So your approach to that would be to, you know, set up your screen, set up your game, have your your your shell there, open a connection that goes to the event, essentially to an event bus, and maybe we can describe what the event bus is a little bit. But you basically plug into the event bus from your server side you've got some sort of engine running that is taking in the inputs, so I'm not sure exactly how those inputs are sent in in your setup.
Speaker 2:But really post and patch. It just it just sends back an SCC event. That's it. So it's just a normal put patch.
Speaker 1:Just So each one of those doesn't need to sort of create its own. I mean it those are just those could just be regular, you know, open and closed kind of events because you already have your your main event that is kind of overseeing the whole process. As you fire things, you're just hitting into the event bus on the server. The server has its own stuff running. You know, it's like a game engine essentially, and it's taking in those inputs, which come in fast because, usually, you know, the distance for so if the connection doesn't need to be open, like, can do you have a separate connection open for the inputs too, or do each of those kind of go on its own in your ideal setup?
Speaker 2:So in my ideal setup, those are completely and and the thing is you can send multiple requests with a fetch. Right? Like they're just completely independent. It's just a normal HTTP call, but it's using ST. That's it.
Speaker 2:Like it's just a different style. And if you send it back, no, nothing but the header saying, hey, this was the content type and it's blank, then you're done. Like, you so you have one way to learn to do things. So you have that ability. And the nice part about it is is one of the things that I think a lot of people lose is that worst case is twice as fast.
Speaker 2:And the reason why is because you're making a poll then waiting for that connection and going back and forth every single time. I can send an update directly, which means that the round trip time is halved. By definition, it can be already twice as fast. So even if that frame rate, which you were showing was, like, 13 frames a second. Even if you did the exact same thing I was doing in HDMX, it would be 24 or 26 frames a second.
Speaker 2:Like, before you even gets into making it better and doing things like updating signals as opposed to fragments and all. Like there's a bunch of things that I think they were doing wrong in that example. But the point is is just think about it deeper level. You can actually make you could do this in HTMX, and I'm not saying not, but the style of how you build things is so much more complex in HD max to do the same thing that it's more code and it's less performed.
Speaker 1:Because Yeah.
Speaker 2:In general, more code is like doing stuff in game dev. The the this this special secret sauce is do less things per frame. Like, be smart about what you do per frame. So do less code is faster code.
Speaker 1:Yep. And I think Carson, from talking to him, would agree with you on that. I think he's agonized over adding anything to the, to the agent's code base. But the way that it's set up, you know, where you're handling most of your stuff from the front end, rather than sort of handling it all from the server end, you do end up needing more attributes. You need some more things
Speaker 2:like that. But here's the here's the kind of the irony of the situation is because with HMX, it's around 14 k. Right? And that's not including and I can tell you on Reddit at least, like, a third of all the things post you see are like, hey. How do I do this thing?
Speaker 2:And it's either add a hyper script or add alpine or some other thing on top of it. So the actual size of, like, what you have to learn is really high to do really reactive, websites. All of the plugins for all the things that you can completely replace both of those frameworks with is 14 k with DataStar. And part of that is because there's a lot of overlap in who owns the main loop, who owns events, how things get triggered, all these things like Alpine and to really disagree on who owns an event and what you do with that data. And by having plugins that understand and rely on each other, and that's where a lot of the data starts off is about creating plugins that know about each other and know that one has to exist before I can do myself.
Speaker 2:That, that kind of thing like that. That's what the 300 lines is all about. It's like, hey. How do I make plug ins, be really aware of their surroundings so that I don't have to think about it ever again. Right?
Speaker 2:I can just write declared a code and go about my day. It ends up being smaller. A lot smaller. And even though there's 14 k of it, most of that over, like, right around half of it is ideomorph and a fetch thing from Azure and a couple things around signals. So over half the code is just outside, like me just trying to build the bits and pieces to make that declarative.
Speaker 2:That's it. Like it's using the ideo morph. It's using so the actual size of the thing is minuscule and it's less to learn. That's the thing that I I I think it's kinda missing because everyone in the issue of X community is like, hey. This is so much easier to learn than spas, and the irony is I think ASR is easier to learn, especially when you get to day 2 and month 2 problems than HTMX's.
Speaker 2:I think HTMX starts to explode as you get more and more input, because you have to make a 1,000,000 endpoints to try to hook into your HX gets into all these different pieces. With my way of doing it, you have one endpoint. You're done. Like you're done most of the time. And then you send commands depending on what you wanna do, and that could be one endpoint.
Speaker 2:It could be multiple depending on what the structure of your stuff is. So it's way less code, and it's way easier to learn, and you get real time for free. I'm not saying every app has to be real time, but you get that out of the box for free, so it can probably handle your your basic stuff really well too.
Speaker 1:Okay. Yeah. So so 2 questions on that. I guess the first one is, in this kind of SSE connection, like, how is it handled? You know, I I still am like mentally thinking of this as almost like a web socket.
Speaker 1:Like there has to be some break like what happens if it breaks? What happens if your server can no longer send something? How do you know, when does that happen? You know, because I I mean I lose internet connection every now and then. Sometimes I'm on my phone.
Speaker 1:Stuff like that. So Yeah. So how is that usually handled?
Speaker 2:The nice part about SSE as a spec, is that it automatically handles reconnect for you. It's already processed back. So as soon as you lose connection, it just reconnects. And in fact, it reconnects and says, hey, I was on this. Could you can put in a an ID on your events?
Speaker 2:So you can actually say, hey, I sent down event 1, 2, 3, 4, 5, and then say, hey, I reconnected. Last thing I saw was 3. And you could automatically send down 4 or 5. Like, oh, there's all these kinds of parts of the spec of SSE. It just does this automatically.
Speaker 2:And it's just normal HTTP. There's nothing special about it. Like, the way you're like, hey. Do I have to open up a bunch of connect like, if you click on 3 things on it to do, set fire off 3 different events. They're gonna happen asynchronously.
Speaker 2:They're gonna get resolved separately. Like it doesn't matter. You're gonna get to the same eventual consistency. So it is truly easier than you most of the time I spend on the, the h t m x. I we're in the h t m x discord, and we have our own little channel.
Speaker 2:But most of the time, I'm trying to tell people you're over complicating it. You're making it harder than it needs to be.
Speaker 1:And
Speaker 2:that's really where I spend most of my time because it's been pretty stable over the last year. So
Speaker 1:Interesting. Okay. So and then the other piece you mentioned was, you know, you you end up with a bunch of endpoints with HTMX. And this is something this is a pain point that I would say I have encountered as well. I use I use I started with Laravel Livewire.
Speaker 1:Have you used that one before?
Speaker 2:Very familiar. In fact, I tried to make a go version of it. And the thing and the thing is I thought it's it's it's a really brilliant idea. I mean, you have to really commit into Laravel to use Livewire.
Speaker 1:Yeah.
Speaker 2:But also the problem is it's trying to keep the state between the front end and back end in sync. It's a syncing tool more than it is a like logical thing of the servers in control. It really is trying to keep the sync in place. And I think it's very easy to get decent with it. And I ran into the exact same issues with with the go version.
Speaker 2:So I went down that route. I've gone down to a lot of routes before. I just said, like, having my own JS framework is the farthest from meet an ideal situation in my mind, but it's so small and it's very easy. Like, I'm happy to maintain it, but it's, yeah, I've tried that way, and it is brought with good intentions. But it's still just web sockets, and you have all the issues you have with web sockets on top of it.
Speaker 1:Well, okay. Wait. So so Livewire isn't web Livewire ended up they they started with web sockets and switch so nowadays they use just you know Ajax request and stuff like that.
Speaker 2:Okay, that's good news cause what I use it was web sockets.
Speaker 1:Yeah, Phoenix live view was the web socket one that's all I saw.
Speaker 2:Oh, that's right, right. Sorry.
Speaker 1:But yeah, anyway, but livewire you know one of the issues with livewire that I've had is it is keeping that virtual dom. It does have to. Like you said it has to it even has, you know, one of the funniest things, one of the one of the, commands you can use is entangle. Which, like, just that word. Every time I come across that, I'm like, oh, this is not a good word for me.
Speaker 1:No. That's one of the last things I wanna see in my code is an entanglement.
Speaker 2:My favorite words in the world is complecting, which means to braid together.
Speaker 1:Comp complecting?
Speaker 2:Yeah. Complecting. I've heard it's because people tend to complect things together. They actually make it braid it make it more complicated and tangled, basically, when they don't need to. So, complecting is like the tangling on purpose, I guess.
Speaker 1:Yeah. So so okay, so you know I like some I like a lot about Livewire. I'll say the thing I really like about Livewire, and the reason I would still use it in some projects, especially if they're new projects. The fact that it doesn't go into old projects is a problem. But, what they do is, you know, your mental model of what's happening, you don't need to think about routes.
Speaker 1:You don't need to think about endpoints. You don't need to think about, you know, particular code snippets. It's like you have this one single component, and then on the back end in your PHP code, you're deciding what happens with that based on logical things, and updates, and you know actions, and stuff like that. So removing that kind of when I now that I've sort of switched to h t m x for most of my stuff, I am finding that you can't keep that sort of like I often would reach for I almost want this section, this whole widget to just whenever I make changes, this is the thing that's getting updated, you know, and I don't necessarily want to have to say, okay, there's there's this, you know, temp this little this small part and this big part and all these things. I just want to mentally think of this.
Speaker 1:I don't want to set up, you know, 5 routes for it. I just want to mentally think of this as a single component. And so that's something that's kind of tripped me up about a little bit. But when you're talking about about data star, and how you don't really have to think of endpoints, and you don't have to sort of create these different ones, Ultimately, I mean there's there's a certain amount of logic that you can't ignore, like you still have to, for instance, have it's maybe not an endpoint, but something has to update and go to the right place. So somewhere in there you're still doing that work, right, of, like, when this is clicked I need to handle it in a certain way and send back this particular data.
Speaker 1:Is that true, or are you basically building the page every time in full and then sending it, you know, with essentially an OOB swap? Like, what's the sort of, like, what's your sort of Yeah.
Speaker 2:What's the mental model? Way do
Speaker 1:you think about that?
Speaker 2:That's a great question. I I should actually let my cat out of the room because it's gonna start
Speaker 1:Yeah. Yeah.
Speaker 2:Yeah. Work. Give me one second.
Speaker 1:Yep. Yep. No worries.
Speaker 2:So it's a great thing. And this is actually, this was part of the talk as well. 1 that the final, revelations I had that I don't know why it took me so long to do this. A better game developer would have thought of this immediately, but, there's a style of doing, graphical units or interfaces in game dev. Once there's called retain mode and immediate mode.
Speaker 2:I don't know how familiar with you are with these concepts. The idea of a retain mode is very much the OOP style of I have a button. It has a on hover, on click on this. Here's its position. Here's all, you know, all the state involved with it.
Speaker 2:And then every frame, you take that state, and then you basically create the the quads or whatever to actually render the the pixels. And immediate mode says all of that is useless. And the reason why is because that button may not exist next frame because you something else is going on, or there's a cooldown or something else. And you have to know the context of everything else on the screen. Like, let's say, you have a scroll bar of buttons.
Speaker 2:You are gonna only show so many buttons on the screen in in a scroll view. So only worry about the buttons that are available on, like, the offsets that are available now and just render those commands directly. And it's a much lower level style of doing, graphical user interface. But at the same time, it's faster and it's easier to write. Because instead of trying to keeps all the state, you're just rendering what's available at that time.
Speaker 2:So in my head, spas are the equivalent of retained mode and, hypermedia is about immediate mode. So when I go and do things, there's one of the things I did in the talk that I I thought was kind of an interesting is I basically rendered every single position of every single thing in a 3 d view on every frame, and basically using web components to do that. So you're writing HTML. So I'm I'm writing out thousands of dibs every single frame, and then letting idiomarking God decide like which things actually got updated. So I did the dump thing from a performance standpoint to say, look, even when you do the dump thing and you just hand the entire app as an ID, you just hand it down and let Idiom work and other things figure out what changed.
Speaker 2:It's still so damn fast. Like it's probably fine for most people's apps. Like the front, the front page of the, there's a to do app on data start front page. I just sit down the whole to do each frame because it's not that much stuff. It compresses very well.
Speaker 2:It's easy to do, and then you let the morph dom stuff do it's the right thing. When you get into a situation when you from a metrics, because I'm very metrics focused when I'm doing stuff. And so when I see the metrics of like, this is causing this much in bandwidth, we can change this, then get into, I wanna update parts of the page and do all itself. So it has the ability to update things in a very dynamic independent way. But a lot of times, you can just send down the the current state of what's on the page and let the morph dom stuff do it's the correct thing.
Speaker 2:Like, don't make it complicated just for the sake of performance. It's already fast enough.
Speaker 1:So I I, let me push back on that a little bit because cause one of the, you know, there there was an argument recently online about, you know, it was it was a performance one. I think it was, DHH, you know, put up his maybe you saw this. Yeah.
Speaker 2:Makes sense to you seriously when it comes to performance things because,
Speaker 1:Well, so but the thing is so, you know, and he the end result of it was that roughly his the average, you know, time for a click was 90 milliseconds. And I think, you know, people kinda like took him to task for that, like this is slow. And you know, and there was a lot of these kind of like you know my app is running handling 10,000,000 requests, you know every minute, and it's like a 5 millisecond response time. And my thought for that was like the apps that I build, for instance, I don't want or I would never want to send back the whole thing every time for small things because you know, I have it's doing a lot of database querying, and it's doing actually some pretty complex database querying. I do my best to cache things when I can, and to But like, you know, you've got a lot of different stuff, and if you start to, you know, for a full page reload that's fine.
Speaker 1:I'm willing to take that hit, and that's what really slows it down is when there's a lot of people using it, and it's really right now I would say the database is my that's the the problem, you know, that's the main area. If it's something really simple, I would have no problem doing what you're sort of describing, which is just send the whole page send the whole page over and over again. That's fine. For stuff that I tend to work on, one of the things I've liked about h tmx is that I can make it feel very fast because even on these kind of complex pages where you're you're doing 600 database queries to build the whole page, to build the side thing, to build all these different things, You do that once, and then you do, you know, 2 database queries for your actual update. So it's like lightning fast.
Speaker 1:So, in that scenario, this is where you're saying you then you would probably start to look into other things that don't hit the database so much.
Speaker 2:Yeah. So this is a again, to me, hypermedia is just a tool in the toolbox. And that's like, look, I don't think people realize how much from the actual hypermedia standpoint, sending down the whole page is not expensive. Right? Like you're doing a bunch of database stuff.
Speaker 2:That's in
Speaker 1:terms of HTML. No. I totally agree.
Speaker 2:Right. So we're dealing with 2 different issues at that standpoint. Now what I would say is most people, are doing databases wrong. And what I mean by that is I tend to and I've been doing this for years, and it's finally become a little more popular, which is interesting because, like, I've been doing signals for, like, 5 to 6 years, and it's finally people are seeing it. Same thing with databases.
Speaker 2:I use SQLite embedded in every single go app I ever make. And then all of a sudden your database, you can do n plus one queries, and it costs you basically nothing. It's a function call within your same memory. It's in the same pages. It's all that stuff.
Speaker 2:So I can do hundreds of calls in a few milliseconds. And so all of a sudden my queries, I'm not waiting on the database. I can do stuff instantly, so I can't send down the whole page. And so even if I'm dealing with post press, I still use like SQLite as a local cache of that data so that I'm not relying on it all the time. So I use it as an optimistic query even when I have to deal with someone else.
Speaker 2:But most of the time people don't realize how many I deal with SQLite databases into the 100 of millions of keys in a table and it works fine. So, it depends on if you have total control. Right? Like, I know that you do a lot of, governmental stuff, and you don't have the ability to do database. So you have to break things out.
Speaker 2:In that case, 100%. Only update the parts of the page that have to update. I'll only do smart things, but also you're getting into caching and interesting problems, which has nothing to do with hypermedia. Am I like, I'm opening up the opportunity to say, hey, you can't send it on the whole page and it's gonna be wicked fast. But if it's your database that's the problem, then it's no longer sending down the whole page makes any sense.
Speaker 1:Yeah. So I guess what I'm saying is though, you know, if you can't send down the whole page every time or you just sort of don't want to for to to reduce the CPU usage on your on your, you know, VPS or whatever. So what how do you sort of handle that from when you receive a request in general? Like, what would be your go to for if you did want to just send back a smaller part?
Speaker 2:Yeah. So let's say we had a data table on the page that has stuff from the database. Right? And you're only update you need to update the last, 2 things on the page you know got updated or something like you're you're only affecting, like, 3 things on the page. Right?
Speaker 1:Yeah.
Speaker 2:So in that case, you would already you'd be sitting on your original data grid or it'd be part of the initial data of the page. So you'd have table IDs and you'd have row IDs and all these things. And so you'd want to have that be something you can target. And then you would just say, like, when I make this query and it automatically updates things, when I go to send a fragment, I know that I'm gonna update this ID and this ID on this row. And you just send those down as 2 individual elements, and you're done.
Speaker 2:Like, you can target them independently, and you just send them as 2 different events right after each other, or you send them down, as they get updated. So, you know, on each insert that you do into the to the database, you could be also sending down SSC events as part of that transaction.
Speaker 1:Yeah. You
Speaker 2:can optimistically up do those updates and do if there's any errors, then, like, revert back to where you were. You can do all these really interesting things if you can start sending down updates during a transaction as opposed to waiting till the end.
Speaker 1:That's interesting. So you okay. Yeah. So that so you could before touching the database, you know, create your objects before saving or whatever, and just send back that HTML, and then send it again at the end of, you know, your database thing.
Speaker 2:Exactly right. In this one of your, podcasts you were talking about, like, optimistic updates are the end boss for, HMX. And I pushed back and said, that's just the beginning. Like, that's that's that's the starter tutorial for what is hypermedia itself is capable of. And I feel like that's where we just disagree, but we all are trying to get to the right thing that like, Hey, I think people are not realizing how good hypermedia is.
Speaker 2:And when it's not good, my opinion is like, then you should be making a native app and doing like actual RPC streaming type stuff. Like the places where it doesn't make sense, spas don't make sense either. You should be doing like a native thing at that point.
Speaker 1:Yeah. And so, I mean, what you're talking about, like, is it it feels kind of light years ahead of where a lot of some of the apps that, you know, in terms of like speed and stuff like that, and kind of the ability to update things immediately. It does feel quite a bit ahead of kind of, you know, just sort of the general which I would probably do right now is pull every 5 seconds because, you know, people don't really in my mind, like the stuff I'm working on people are happy if they are 5 seconds, you know, behind the like, that's enough for for the stuff that I'm doing.
Speaker 2:Okay. So here, I'll give you an example of one of the projects I'm really proud of. It ended up with a software patent, which I'm not a big fan of, but it makes sense in this case. I was doing a a project where we were tracking every radar station in the continental United States, every single radar blip from each of those stations and having it live instead of a browser within 700 milliseconds from anywhere in the continental United States. So you need to be able to look at over 800,000 points per second being updated in your browser in real time.
Speaker 2:And then had the ability to scrub back to any point in time over the last hour over that data. So that had a 5 millisecond window to scrub that data. So I'm used to dealing with, like, hard I I think pushing to me, the the browser is a beautiful thing for, a sandbox to do interesting things in because everyone has it. Everyone has auto updates. Like, it's a platform.
Speaker 2:And I think that these spa people and now the HMX people are just talking past each other on, like, what is capable in these machines. And I do think having a different mentality coming from a game dev and not being a JavaScript or TypeScript person, but just like, to me, it's a tool to get the job done. I just have a different outlook of, like, what is capable and what I don't understand why people are having such a hard time making a a fast web form. Like, there's still the issue if you go to hypermedia route. This is just a default thing of if you're updating it to do, and you're going to the server for that validation, you're still gonna have those requests.
Speaker 2:Like, you still there's still that cost. But if that's to do is now share between you and a 1000 people, you've amortized that cost of that one interaction across all the other interactions that are happening live. So for certain kinds of things like web forms, it may feel slower, but you're always guaranteed to be in the right state. And you could do optimistic updates to make it look like you're, you know, like you have data, but you're not in the same state as the the rest of the system. So I think there's things there that are an interesting dichotomy of, like, what the user expects.
Speaker 2:Like, if the user expects that my changes will get automatically synced to the server, that's different than saying, I know I'm always in a safe state. I know I'm always if I can see it on my screen, it's correct with what the server is gonna see. I'm never getting into a bad situation.
Speaker 1:Yeah. And we sort of talked about this I talked about this with Carson with optimistic UIs where it's like, do you even want an optimistic UI all the time? Like, you know, if it tells you you did something, you didn't, you know, you have to put some work in to say like, okay, this is not finalized yet or something like that. Because otherwise, you are misleading people, or you're giving them buttons that are not gonna work. You know, in which you don't you won't do that either.
Speaker 2:Yeah. Even when it comes to things like game dev, you have things in what's called net code, where you're basically you have to do dead reckoning. So if you're playing a purpose and shooter and you're shooting at someone, you're shooting at where they were before, and you have to do the reconciliation and checks to see that you basically not only are shooting at that person, but also if all of a sudden the server says you were wrong, you have to actually go back in time and replay those events and basically, tween between them so that it looks smooth to you whether you hit them or not. Like and I think Is that how that works?
Speaker 1:I mean, like, it's this is shocking to me. I think it's really good. Development that this is possible. That when I play these online games, I'm like, how are they doing this?
Speaker 2:Well, yeah. It's called that we can get into a whole talk of that. Actually, Blizzard has a great talk about netcode, that I can link to you. But the the point is is that as soon as you start doing optimistic updates in the way you're thinking I'm talking about, like, as soon you get to the server, sending back a like, your thing got approved. Oh, wait.
Speaker 2:We ran into an issue. Right? I think that's a different level kind of optimistic updates. Whereas, if you wanna get into the netcode style, you are in for that's all of what an FPS is about is like how to reconcile, like what is actually happening with what you want the user to see and to make it feel like a smooth transition. And I don't think any web app I've ever used, that would be a good idea because you're you're talking about someone's, like, bank credentials.
Speaker 2:I don't want to have a tween version of whether I was logged in or whether my, probabilistic. Yeah. Yeah. I I think that that's a bad idea for what the web is. And, while I still am working on some interesting things with web transport to do like an FPS type shooter type style, the same thing is that all that logic would live inside of web components.
Speaker 2:It would not be driven by HDMX or data start, like, from that point of view. And that's one thing I did talk about in the talk is I really believe in web components now in a way that I thought they were dumb and stupid not too long ago. And the reason is is because if you're already if you're doing all your stuff in a spa, breaking out into web component doesn't make any difference. Why do I care if I can use this in React? I'm already using it in Vue or whatever.
Speaker 2:Right? Like, it doesn't make any sense. But as soon as you say, I'm gonna keep all the state internal, and I can drive it from anywhere or from anything, then things like I built a 3 d engine as a web component. That's great because I can keep the state internal inside there, but then drive it with data star. So I can drive any attribute on any element.
Speaker 2:So web components to me is about making new elements. Data started about driving existing elements in every one of their attributes. So, it's a different way of thinking about the problem. You're not getting rid of JavaScript. You're putting your internal you're keeping state in the right place because there's that there's always that dichotomy between you want separation of concerns for higher order components, but you want locality of behavior inside of debts component.
Speaker 2:So I think you have to think about this stuff at a, at a deeper level to get the value of it. And I, yeah, I just feel like the, hypermedia, which basically makes you max right now. Like I data stores and have its own disco. Like everyone that cares about this stuff is in the ACMX space. But I feel like they're missing the the forest for the trees and, like, what hypermedia itself is about.
Speaker 2:And it it's almost like the Roy building thing happening again that people are missing the the boat on what what the possibilities are and just focusing on this implementation.
Speaker 1:Interesting. So I mean, the the big picture is like this the SSE concept. Like that's just that doesn't exist in HTMX. Is that fair to say?
Speaker 2:No. This is
Speaker 1:an extension.
Speaker 2:This is an extension, but it's to me, it was such a fundamental core idea that I started mucking into the 4 k of HD Max to try to, like, add these kind of features and add some alpine like features. And I got just into the weeds. Like, it's just not I'm not smart enough to understand the the the consequences of making extensions. I'm not smart enough to understand the consequences in HTML. And same with Alpine.
Speaker 2:So both of them are just a JavaScript, like, HTML is a 4 k file that is a edifice to Carson's brain. And while I think it's a beautiful and wonderful thing to be there, I don't think it's the rock I want to build my my my future on.
Speaker 1:Yeah. And, I mean, so let me just let me ask a few questions about sort of some of the background stuff that you've mentioned. So the the event bus, let's call it, like I honestly I don't do much with events. So and part of that is because just my sort of my general distaste for my coding in the past when I've used events. It's been very hard to track down, but I'm mostly thinking client side events.
Speaker 1:So, you know, I have somewhere some jQuery file with, you know, 40 different hooks into different events that's gonna do different things on click and hover and all. That's my that's my 10 years ago kind of, way of thinking about events. And so I've just over time kind of moved away from them. But I recently saw, I don't know if you saw any of the Laracon talks, or if you sort of follow any of the Laravel stuff. Well, so, you know, one of the big talks was about event sourcing, and how if you just keep a record of your events, you can then basically, you know, export that to any sort of front end.
Speaker 1:You can keep, you know, you can have different database views based on your events, that go to different systems because your events are really the core. This is what your users have done. So that doesn't change, you know, but what does change is what happens because of those events. And so this to me feels a little bit like your the game dev example that, you know, the first person shooter. It has to reconcile.
Speaker 1:But really there is a core, here's the events that happened and how that's displayed to the different users might be different. But somewhere in the back they're keeping this sort of immutable record of the clicks that happened, where where the user you know, where the player was, all this kind of stuff. So is that sort of how you think of of an event bus at all?
Speaker 2:I know we don't know a lot about my record, but the thing I was doing I actually joined, Sanadia, which is the people behind NATS, which is, like, the premier way to do event driven architecture stuff, on the web. But also before I was doing that, I was working on on my own startup that's literally called Event Graph. That is an event sourcing way to build. And so I I could talk to you for probably 12 hours straight about event sourcing, and it's actually the very first piece of, writing we have was cuneiform that were grain shipment logs that is literally an event sourcing style. So I've gotten really deep into those weeds.
Speaker 2:I would happy to talk to you, but I think the the thing the problem with event sourcing as a general concept is once you think about it, you can't get rid of it. Because if you're not doing event sourcing, you are losing state by definition. Like, there's no way to do everything is just, down to implementation details from there. So, yes, everything to me is event sourcing because that allows you to make choices later, and projections are completely independent. So for example, one of the things that you run into both with game dev and with a lot of things is people I talk a lot about sources of truth.
Speaker 2:And really your events are your source of truth. And then things like a, index or a relational table is really a projection of what the the events have happened. But as soon as you put in an update or delete, you've now lost data. So I think that most databases should be a projection. So it doesn't matter if it's a graph database or relational or time series.
Speaker 2:All of those should be queued off of your events. So yeah. I think about events at a deep deep level, and everything has to be event based, which means everything in the end is push based, which means everything should have push based as its interface, which means things like go, things like nets, things like data star. And that's the thing is I I I feel like coming at it from a different point of view of, like, not only what is capable now, but with which how we should be thinking about things. One of the examples on the, on the dish or website was this bad apple example, which is just a it's a music video that gets used for, like, ASCII art and for, benchmarks and stuff like that.
Speaker 2:And someone brought up like, hey. Wouldn't it be funny to see a HTMLX example of this? It'd be kinda fun and be like, oh, why don't you go do it yourself? And I said, and I go look at the ASCII art, and the actual data start part of it took less than 3 minutes. And I had a real time feedback player of ASCII art.
Speaker 2:And the thing that's interesting to me about that, that shouldn't be interesting. I should be able to take the the set of events and send them down. There's nothing that should be interesting about that. But in the HDX community right now, that scene is like a really cool demo. It shouldn't be.
Speaker 2:Like, this is basic replaying of events to a page, and I should easily be able to do that 30 frames a second. Like, that's 300 30 milliseconds or or 33.3 milliseconds. That's a eon for a computer to figure things out. Even with the network involved and everything else. Like that initial connection takes time, but the latency for each individual frame should not be high.
Speaker 2:So Wow. It's and it's not a big deal. You can go play it right now, and it's it's should be buttery smooth on a free tier fly the IO server wherever it's at. But, you know
Speaker 1:Yeah. I mean, so this is, you know, I just just in general, this is this is kind of blowing my mind here because, you know, this I'm used to I'm used to a certain way of browsers taking data in and kind of processing them. And and, you know, I've been kind of pushing back against the SPA world in my own head and for a long time because I just really dislike how it has to keep its own huge thing, and how slow it gets. Like if you have ever tried to do something like this, which you probably have if you know if you went deep on it, and put, you know, let's say a 1,000 examples. So so here's something I'll just tell you I'm working on because I'm gonna be talking about it next season, but I'm building right now a page of HTML examples.
Speaker 1:And one of the, sort of, like, flex things that I'm gonna do with it is I'm gonna put 100, maybe thousands of examples onto the page that all work. Right? Which is like why would you do that? Who cares? To the SPA world, you you literally can't do that.
Speaker 1:I tried to do this with with even with Livewire, which is not exactly an SPA, but because it has to put everything into JavaScript memory, it can't do it. So I think I feel like the big trick that you're talking about, and like the event sourcing stuff, people don't even know what that is in the development world most of the time. You should check out that talk at Laracon by Daniel Colbourne. I'll say this not even just to you because you already don't really need it, but anybody who's listening it gives it's his package is called verbs, and it gives a conceptual idea of why you would use event sourcing and what the purpose of it is. Like just the big picture.
Speaker 1:What's the purpose of this? And it's exactly what you just described. A month ago, I wouldn't have had sort of a good concept of what that is. Now I sort of do, but mixing that event sourcing where you're taking this in and having this kind of game development concept of like why should the web be slow? They're all computers.
Speaker 1:You play computer games fast on your computer. Why is the web so slow? Like I think that mentality mixed with event sourcing, and then just something as simple as a basic HTTP, you know, SSE form where, like, SSE way of of sort of sending, an open I keep call I keep calling it a socket. I don't know what to call
Speaker 2:it. Yeah. That's what it's just regular h t it's just a HTTP response that doesn't finish.
Speaker 1:So so what do you like what do you what do you call it? And besides SSC, like an open ended request?
Speaker 2:Yes. It's just a request.
Speaker 1:Okay. So sending an open ended request, which I don't think I've ever done in my life, you know, and like that opens up along with these other tools. I guess that one of the big questions that I would have left, and you know I know we're already over an hour so I'll try to keep it brief here, but can you do this with any, you know, one of the things I like about h tmx and hypermedia in general, and I'm moving more towards using more browser tools, more browser built in modals, everything. It's all built in. You know, it's it's wonderful.
Speaker 1:And I open these apps that I haven't touched in 7 years. I can throw h t m x at the top and I'm already building, you know, awesome new features for this old app. Can you know, you're using Go, is there anything specific about the tech that you're using or can I as like a Laravel primarily developer, can I do this stuff just as easily?
Speaker 2:Yeah. 100%. It works in all of the things. In fact, there's a person that's actively saying starting to use up in Elixir because it matches his mental model of, you know, how events event input the way it works with that. So, yeah, it's just like HDMax.
Speaker 2:I think that's one of the brilliant things of what it's doing there. I totally agree that you should be able to do it in anything. In fact, there we have a lot of people that are using it in node, which I hate. Like, I think it's the worst back end technology. And yet people are using it, and it's making their lives easier even though they're staying in TypeScript or in, you know, like, they don't they can send down declarative things and let, like, let things work themselves out in the front end.
Speaker 2:So there's nothing magical about it. Everything you can do in HD max, you can do in data star and more. And and to be clear, this is just the plugins in the way I like to work. The thing about nice thing about a star is you could you could completely rewrite HD max in data star. You can't do the reverse because you can set up these set of plugins.
Speaker 2:I just think that that style I originally did that. I originally did it all like just literally ported all the tags over. And I was like, this doesn't make sense for like, I have this capability of doing all these really interesting things. Why would I do it? This kind of 1999 style way of doing things.
Speaker 2:Like, I believe that we should get back to hypermedia. I don't think we should get back to 1999. And I think that's the difference between, Carson and I's approach to this stuff.
Speaker 1:Yep. Okay. So just on the, like, doing something in the back, you know, using Laravel for something like this. You know, my understanding of how PHP kind of handles a request Is it it does close it shuts things down at the end, you know. So how do you stop that from happening?
Speaker 1:If you need to have kind of a process running on the server that is going to be sending stuff out, you know, that's not in my experience the general way that PHP or Laravel is sort of handling requests. How is how do you how does your sort of think of that?
Speaker 2:I mean, the thing is I I I can't speak for the PHP side because it's but I've heard that PHP has gotten pretty good lately. So it's been a while since I've used it. But what I will say, at least in the node side, because I do know that decently well, is that basically, if you have a bunch of if you have a tight loop, it's just gonna say that loop. But if you have, like, I'm awaiting some event bus for a response or some kind of network thing like NAS or something, then you just update the response. So you can do things concurrently with but still being on a single thread.
Speaker 2:Go has the the beauty of being able to do concurrency and multi threadedness at the same time, so there's a value there. But as long as it's an async thing where you're basically waiting awaiting a subscription, I know in the go side, for example, you have this idea of a context. So you can check the context done to see if the client closed the connection, or you can just close your handler and that also closes the connection. Like it does you can handle it both ways. I'm not sure what the equivalent of each piece.
Speaker 2:I'm guarantee there's a way to do it. But basically, it's equivalent of saying, did the user close the connection? Or if I just return, does that close the connection automatically for me? I we can get into I would be happy to work with you to try to figure out what the right way to do that is. But again, if you're using the h t m x, s s c extension, you'd run to this exact same issue.
Speaker 2:Like, it's just an issue of having a live connection that keeps open. There's nothing about the PHP, unless they have some kind of weird timeout thing on your handler that says you can't keep a connection open.
Speaker 1:I mean, it it is maybe a little weird, and I, you know, I I don't know without getting into it, but, I know that, you know, Laravel released kind of a big package. I think they swole or something. But it was to keep a connection open. It was like a big deal. This was a couple years ago.
Speaker 1:And I don't know that without that that there is a a built in way. So I'd have to do my own sort of, you know, looking into that just to kinda, like, figure that out.
Speaker 2:Yeah. I'm not sure what the, because it's something part of the spec. Like, when you say I'm returning a response, unless you have some kind of time out or something on your actual connection that says, hey. I'm closing connection for some amount of time, which is built into go too. But you basically say, I'm setting up what's called a flusher in the go response.
Speaker 2:Basically, it's the thing that I'm gonna start flushing down things immediately. And you send out an initial page with that flasher response. Now all of a sudden it's gonna say, I'm gonna keep this open forever. So if there isn't a lot of times I see people use an SSC plugin or something for their back end, but it's literally 4 lines of code. I highly recommend not using the SSC plugin, but just looking at the code of it and saying, what's going on here?
Speaker 2:Because it should be at most four lines of code of saying, I'm setting up the right header. I'm flushing that down. Okay. Now I should be good to send either 0 or a 1000000 events from here. So, yeah.
Speaker 2:I don't know what the answer is, but there's nothing the nice part is that even though it's not technically SSC from the client side, from the server side, any SSC library or anything like that will work out of the box. But I highly recommend not using a library because you should just know what it's doing. There's no magic. It feels like it that's the problem I think people see is they think that there's a lot more magic, that it is a socket, that it is this special thing, whereas it's just not. It's just not a special thing.
Speaker 2:In fact, it's exactly how I do hot reload of my apps. It's like a 4 line thing. And basically, I go to slash hot reload, and that SSC event, it just sent it basically opens and never closes. And that's it. Like and then when the server restarts, it's gonna automatically try to try to redo that connection because that it's built into SSC, and it'll load the page again.
Speaker 2:Like, that's all you have to do to make SSC a hot reloading work. It just uses open SSC event.
Speaker 1:And you write your application, you know, using events so that different events trigger updates and different you know, some trigger updates, some don't. Is that sort of a big picture? How your sort of apps would be set up?
Speaker 2:So if, for example, if I'm if I have an open updates, like, we just made a single endpoint, the slash updates. Right? Let's do it my way. And I had it in it, and I'm subscribing to a bunch of, things inside of the event bus. In my case, NATS all the time.
Speaker 2:I would say, oh, I got an update that has to do with user credentials, and that I already know that that's I'm gonna have to update their avatar. Okay. Well, I just send down the the you know, update that ID instead of the avatar. But it may be something that says, hey. They changed their billing to be, on the on the 5th of the month instead of the other.
Speaker 2:And I would just say, cool. And do nothing. Right? I just, like, let that thing go. So it's very much there's that switch statement that happens inside of your events of like, hey, I got an event down.
Speaker 2:What do I do? But it's very much closer to the actor model of, handling mailboxes and all that kind of stuff that you would do in in a elixir or or lang or something like that. You're just responding to the events. And then when you see something that needs to change the page, render that fragment at that moment. So you don't have to wait till the end to do a response like you would in your normal HTMX thing.
Speaker 2:Right? You're sending a response to the end sending fragments. I can send the fragment literally when it happens. So my code is actually a lot cleaner, and the locality of behavior is even tighter than what you get in HDMX. Because Alright.
Speaker 2:Directly where I'm doing the work, I just send the SSC event at that moment.
Speaker 1:Interesting. Well, no. I mean this is this is crazy stuff. I love it. I mean this is like really it's like I feel like you are one of the people in that bridge between game dev and web dev, where for some reason there just hasn't been that mentality of being able to do this kind of stuff.
Speaker 1:And I'm not exactly sure why. I feel like there's a pretty good perception of people who do both.
Speaker 2:Yeah. I did I did both, and I fell into the trap of oh, well, obviously, I I put on my web hat. I mean, web world. I put on my spa hat. I'm gonna be building these giant NPM megaliths, and it's dumb.
Speaker 2:It's just dumb. The irony is that I feel much more comfortable in, like, web GPU and, GL direct like in drivers and, building shaders and stuff. But for some reason, I think it's there's a mental load of, like, well, this is what everybody else is doing, and someone has had to have thought about doing it this way. And there's that, oh, like, I'm not you know, I'm not any special. I'm not a JS guy.
Speaker 2:There's gotta be someone who's thought of this already. And I think Carson kinda showed that, like, some crazy guy in Montana is sometimes needed. And having a guy that's done a little bit of everything from Vegas would be a value because I no one has thought about this. Because whenever I show it, people are like they almost don't believe that there's some kind of paperwork they want.
Speaker 1:What's happening here? Yeah. Yeah. You're just running like a WebGL thing, and there's like, you know, it's running in the browser.
Speaker 2:So for example, I I put a thing in the chat of just like in this I know it's mostly for radio, but if you click on that thing, you'll see it was one of the first React, the first React conferences. They were talking about how React can do things that no other framework can do. And look, it can do this thing at, like, 30 or 60 frames a second, and there's this DB monitoring tool. And if you click on the link, you can actually see how long I'm I'm actually tracking how long in the go side is taking me to do that update. And it's microseconds.
Speaker 2:Like, it's literally microseconds to do the update. So the idea of what is possible and capable, I I think the same way react kind of push people's boundaries of like, look, like jquery is a bad way to keeps track of all your state. Because if you put more and more state in the front end, jquery is not the right way to do it. We have a different way and b dom is not that bad. Okay.
Speaker 2:That's cool. But when you say, I can tell you the exact state of the entire system and everyone agrees to it in an eventually consistent way, so that everyone's looking at the same data, but they're still able to do it at, you know, 90 frames a second. That's a mental model that no one seems to have. And then one thing I will say is that when I talk to people about this, they just kinda YOLO about it. Like, if I say, hey.
Speaker 2:I made this thing and it's, you know, over 10,000 frames per second when you made it 10. I don't get responses back of like, hey. Maybe I'll go look at data starting. I'll think about this differently. They just go, well, that doesn't track my mental model, and it's it's about the lows as opposed to about the actual data and the content.
Speaker 2:And I I'm really fearful of that in the next 5 years, you're gonna see more and more of pigeonholing what hypermedia is to the current implementation. And I don't wanna see that, because the same thing happened with SPAs.
Speaker 1:Yeah. No. Absolutely. I mean, you gotta you gotta have people pushing the boundaries. And I yeah.
Speaker 1:I mean, I feel like you are pushing those boundaries. I love it.
Speaker 2:Well, the good thing is you don't just because you can do this stuff doesn't mean you have, like, you can still use it for just regular basic website stuff. Like, it's just why there's I I do think that there's inherent scale to the way HMX works. And I think you had a great podcast or or rant a little while ago, which I loved.
Speaker 1:Nice.
Speaker 2:Which is about, HMX or about, CSS Zen. And that that happened in, like, what, 2005 or so, maybe 2010. And I remember that being, like, this is gonna be the future. Like, we're gonna, like, separate the concerns of the styling and all that stuff, and it never panned out. And I really am fearful that HMX is the exact same thing that's it's giving you this instant gratification of, wow, this is so much simpler than a spa.
Speaker 2:But as you get farther around, you have more and more tags. You have more and more routes. You have more and more it feels more like an RPC as you get into the weeds of it. And I think I have a simpler way. And it's comes from experience in in a completely different industry and a completely different way of thinking about things.
Speaker 2:So I wanna make sure that it's well known that, like, I think HD max is wrong, but for the right reasons. And to be clear, I don't think Carson's wrong. I think the way people are using HD max is wrong.
Speaker 1:Interesting. And, you know, for the h t m x fan who's listening, which is like is it, you know, I don't want I don't wanna I don't wanna, I don't want to make anybody depressed. But is it fixable? Or is it like do people need to update their mental models to do this? You know, I mean data star obviously, if it has it has this sort of different approach.
Speaker 1:And I'm gonna take a look at it because first of all I think it's just the ability to do some of that stuff. Even if I just use data star for one part of the page or something like that, but it's like if you need to be able to kind of broadcast this in a way, and you know be able to do something fast. I don't see how you do that with h t m x or or with an SPA, you know. There's just a lot of that. Like this to me feels like a new kind of approach, and I appreciate that.
Speaker 1:And I think that is there something that, you know, is HTML something that they you'd be able to add this to? Or is it different enough where it's like you do need to switch your mental model, and you need to use more events, and you need to because I don't really use a lot of events. So this would be a big switch in my apps. You know?
Speaker 2:Well and this is this this comes down to the the the crux of the issue in that I don't think the real time, like, SSE part is that is really the interesting part of DataStar. I think that's just a oh, yeah. That's the way to implement. If you're gonna do back end stuff, that's the right way to implement back end stuff. In my opinion, I think the core thing of what h makes data star a long run win is that it will enable in a marketplace of ideas.
Speaker 2:Whereas, HMX, it's literally it's Carson's way to do things in a big 4 k file. I love the fact that you could completely replace what I've done with SSC stuff and change it out and do literally rewrite h m x to be the the endpoints that you go to. You can do that. So my thing is more I wouldn't see it as a, you know, sprinkle it on the page like h m x. I really do think it's a just like you did wholesale when you looked at the spa stuff, and you went to HDMX and you said, okay.
Speaker 2:I'm I'm gonna reset my brain of what's capable here. I would like to see you instead of sprinkling it, even though you can, really take that from first principles and say, how would I do things differently if I had this idea of being able to interact directly and have signals and reactive things built directly into the page? I don't have to add alpine. I don't have to have a hyper script. I don't want to do I can do these bits of code of training on and off and do two way data binding and all these kinds of things just natively.
Speaker 2:I don't have to add another library. I have one mental model of things. I think that would really change the way you look at what hypermedia can be and doing it in a purely spec way. I know you can do data dash, get and all that stuff with hype HTML, but that's not the way you learn it. Like, you do you can do this with Alpine.
Speaker 2:It's not the way you learn it. If you had one cohesive model for how you deal with hypermedia in a reactive way, I would start there. If I if you were trying to learn it, and I'm happy beyond the Discord, happy to talk to anybody about this stuff. But it is it is almost as much of a flip from SPA to HDMAX as it is from HDMAX to DataStar. And the problem I see is HDMAX, I tried to make those changes.
Speaker 2:I literally was saying, hey, I want to see HTMX more. If you go back in the history of the TypeScript Thunderdome, which basically started for me, like yelling at clouds, I was literally trying to make these changes so that we could person could be wrong about this or that or that. And then I can say, hey. I could prove out this module is better and pick and choose the things that, like, we did, but it's just not with that mental model in place. So I don't know if it's fixable in the issue.
Speaker 2:So I already tried to fix it, and it wasn't desired, it wasn't a desirable thing in their mind.
Speaker 1:Right.
Speaker 2:So I don't think so. I don't think you can fix HD Max at this point. Interesting. It's not it's it's not broken. I mean, HD Max sucks is a is a beautiful article and essay.
Speaker 2:And but the problem is is all the things in there, I feel like he cribbed off conversations we've had or, like, things that he's heard. Like, I've I've brought up every single one of those issues. And the issue is not that he he basically saying don't use a t m x if this doesn't makes if if if any of these things don't make sense to you, like, this is what a t m x is. If you don't like it, cool. Like, find something else.
Speaker 2:Well, I couldn't find something else so I ended up having to write. But I literally started with not not HTMLX 2 because before HTMLX 2 was out, I built a whole thing in TypeScript to try to fix these things. And, it wasn't seen as an issue. Like, just, like, why would you do that? That's dumb.
Speaker 2:It's basically the response from the community, not from Carson himself. So it's it's I I've already tried to fix HTML.
Speaker 1:Yep. Interesting. So okay. Maybe I'll just I I'm like I'm this is just a fascinating to me, this this whole concept. So but I'll I'll just finish with that or at least we can.
Speaker 1:I would be curious and maybe you can maybe you can maybe at some point I can check-in with you. You know, I take an old app. Can I put some of this data start concept into that old app?
Speaker 2:Yeah. I actually think it's better with brownfield than h t m s because you by default, it can change any point on any point of any screen. So it's like out of it's doing the 8 out of bound swap stuff, but it's also doing all the more done log. They just it's I think it's way easier to add into it in an existing project than, HTML access.
Speaker 1:And and you'd sort of, like, add a single route that would be your new sort of handler for that. You know, like right now I have an app with, say, let's say 200 routes defined, you know, and each one does its own page and all this kind of stuff. You might add in, I guess what I'm worried about, and I'll just like sort of I don't I'm worried about one solution that takes over, and that you sort of have to change your whole approach. One of the things that I have really appreciated about HTMX is I have all kinds of apps that I've built over the last 20 years. And I use Vue, I use just PHP, I use jQuery, like all these things.
Speaker 1:HTMLX has played nicely with all of them. And I've been able to just kind of incorporate it and use it as much or as little as I need. And what I'm like my little alarm, my little fear, when I'm sort of talking to you about the data star setup, is do I need to rethink how I do my app in terms of I don't have any events, you know, I just don't I don't use them. I don't have an event bus that's running on my server non stop. So do I need to rethink?
Speaker 1:And I'm not opposed to rethinking especially building a new app and doing something incredible. Like I love to sort of figure these kind of and being able to kind of rethink how I do stuff. That's fine. But just on a purely logistical level, if I go in to to make some add a new feature that's really nice in an old app, How much do I have to rethink this the architecture of that old app?
Speaker 2:0. The whole thing is that I think I basically, data start is just a superset of what you can do in HTMX. The way that I like to do things is a very real time, you know, gamer centric style of mental model. But you could do the same fragments and call the day and do the exact same routes and do exactly what's, you're doing in HMX. I think you're missing out on things, but you can a 100% do it that way.
Speaker 2:And then you can the nice thing is because everything is using that same style, whether you send one of it down or you send 10,000 events down, it's the exact same code. So as you add more and more, you could scale up your thing. So it's you can just do it straight and drop in replacement. In fact, there's probably a way to do HX get well, there's so many tags. You'll end up having a lot less tags.
Speaker 2:But in general, I can help you work through an h a team X thing and just say, okay. Add data start at the top, same as the one line CDN thing like you have now, and, like, just step through it and say, you're you're not getting a bunch of value, I think, out of it, but at the same time, if you're if you already added a hyper script or outline or something to your app, now you can just delete that and we can start going through and cleaning things up. And I guarantee you, you'll have less code. Yep. Even for the same mental model.
Speaker 1:Interesting. So I I almost wish there were, like, the Olympics of web development or something like that, where you could like go Oh, gosh. Like I would love to like see, you know, I don't know if Ryan Florence is, you know, like I think there were some people at big sky, but also just in general, who I'm trying to remember who some of the some of the sort of main things were, but, you know, the big concept is I'm using an SPA because I don't want to be limited. And I feel like I
Speaker 2:feel like you're loading yourself.
Speaker 1:Yeah, well, yeah, and I think it's like, you know, if you're willing to go with hypermedia you're accepting these certain limitations. And I've been trying to push against those boundaries myself and try to build. So what I would love to see is just examples, and you have that you said, you know, you have that nice example of the the, the Apple image, the video and stuff like that. So things like that that, you know, people just don't think are possible. Like, I would love to see, you know, and I don't know this exists.
Speaker 1:It's just it's all about who has the most, you know, the loudest microphone right now.
Speaker 2:I think that's definitely the case.
Speaker 1:So this is why, like, a merit based, like, here's different implementations of the same site. You know, here's the thing that SPA people think is the fanciest, coolest thing. Here it is done, you know, using web transitions in the browser with mixed with some, you know, data data star, like, for the back end. And, like, I feel like there's just these, possibilities that people don't even know about, which I don't know about either. And I'm I just wanna, like, I I really appreciate you talking about them.
Speaker 2:Yeah. Absolutely. It was interesting going to that conferences is primarily React and Vue developers because it was a Utah JS conference. And I basically said at the end of the talk, like, I understand why Carson doesn't wanna use DataStar. Right?
Speaker 2:Like, he's happy where he's happy and he's good. But I don't understand why the rest of you don't. I really don't because I'm throwing out the gauntlet of I'm showing you real time 3 d applications. I'm doing all kinds of interesting things, and I'm doing stuff that you can't do. I know because I've done the same things, like, and I'm doing them in easy in less code.
Speaker 2:Like, my entire 3 d engine with a full quest system and all that stuff is including all of the logic to fill it out. It's a 400 lines of, like, temple code. Like, it's so simple because I'm just taking the the source of truth, which is game engine, and during that tick, creating some HTML. And it's so tiny compared to the way that you're doing it. I would love it if it was a metric space.
Speaker 2:And the only person that's really talking about how good data star is is literally Carson. Carson is the biggest voice that's actually taking it seriously. In fact, I have one of the AC max disks from the thing, and, it literally he wrote on it. People should try that data star on the on the AC max 2 point o thing. So it's weird because the biggest voice is the person that we should be at odds and we're not.
Speaker 2:We just, like we agree disagree on implementation, not on the the idea. So I don't know how to get the word out better. I'm not I don't wanna be a framework guy. Like, I don't wanna be the data star guy. I'm hoping to Tom Sawyer or Theseus ship this.
Speaker 2:So over time, none of my code exists. I can just use these beautiful, like, ideas that other people have done. That's the hope is that none of my code exists in a year from now, that it's gotten popular enough that people have written better versions of what I'm doing.
Speaker 1:Interesting. So you could, like, have a, you know, somewhere out there there's a page of demos and you haven't had to build all of them.
Speaker 2:Yeah. Well, if if if you actually go to the examples page of DataStar, I took every single HTML example and I ported them over. So that should help you because it's literally a one to one with what the original one is, except for I may add in feature that you cannot do in HTML without adding alpine or something like that. So it'll be slightly different version. It's it's all the HTML examples.
Speaker 2:I ported every single one of them. And then I have a bunch of other examples. I have over, I think, 50 examples on the page that are showing all the different versions of what you can do. So I already have those in place. I just don't know how to get the word out in a better way without becoming like, I don't wanna go to every conference and just yell at the clouds.
Speaker 2:I'm like, look. I almost kept it secret. I almost was like, I'm just gonna do it this way. It gives me a superpower and no one else can compete. But at the same time, I want to see better ideas out there.
Speaker 1:Yeah. I'm glad. Don't keep it secret. Don't keep it safe.
Speaker 2:Don't worry. There's only, like, there's only, like, 12 of us that use it actively. But what's interesting is the people that use it are doing, like, hardcore medical imagery stuff. Couple military applications back in the space I used to work in. AI real time AI inferencing thing.
Speaker 2:Like, it's getting used. Where people that are using it are in hardcore problems. But everyone else doesn't seem to know or care
Speaker 1:yet. So I don't wanna, like, you know, I don't wanna give you any work that you don't are you ready to do, but, you know, you know, you've already done a ton. But like the htmx world is relatively niche and small already. So like your website, if people see it as an offshoot of htmx, like, you know, the comparison, the direct, it's helpful for me as someone who's gone deep into HTMX. I wonder if if you put data star up against the reacts, the views, and showed that we're not limited.
Speaker 1:Like this is not like, oh you're using hypermedia so you need to use some other data star. You know, HTMLX doesn't have everything. But like people who I think the comparison versus the SPA is the really interesting one.
Speaker 2:Mhmm.
Speaker 1:And that's the one that when people talk to me about it, and that happened at Big Sky, a lot of people were like, I just I wouldn't use HTMLX because I don't want to like come across some limitation where I can't do something in the front end. And I think that react versus, you know, maybe you don't want to get into like a versus type relationship, but in terms of just merit, and in terms of capability, and all these kind of things, I think if there's an examples that, you know, maybe expanding beyond HTMX as a comparison, not just to show mental model, but just to show capability versus react and view, I think could be could be useful for people.
Speaker 2:Yeah. If if there's a I wish there was a better version of, like, the to do MVC that was actually, like, a real world. Like, here's, you know, a 1000 different streams, and you have to update a page. And, like, a chat like, building a chat app is not is less than an hour in data store. Like, it's like, building a full Discord equivalent app is so dead easy.
Speaker 2:I don't even know how to I I literally can just do it on stage and show how easy it is and say, you know, if you have a a better way to do this in React, I'm all ears. I don't know how to be comfort that confrontational though, because I was one of those people. Like, I drank the Kool Aid. I did all the things. So it's it's more of the, like, wake up sheeple or something.
Speaker 2:I don't know. Like like, I I'm not it's meme heavy as Carson. It's just like
Speaker 1:Yeah.
Speaker 2:Like, we're all doing it wrong. Me neither. And the problem is we're doing it wrong, and now is doing it wrong too. So how do we fix this? And my hope is that someone could look with a better idea, and then makes it declared to plug in so that I can hook into it.
Speaker 2:Just like the way that you see SSC is just like magic sauce. Right? Like you saw, like, man, that's a mental model that I can get behind. That's just a plugin, man. Like, you could rip that out and do it the in different ways.
Speaker 2:Someone come up with that thing. I have some really interesting ideas around web transport when that becomes available everywhere, which is like what WebSocket should have been. They'll allow you to do things that WebRTC does and, WebSockets can do, but in a unified way and quick. So there's a lot of things around there that I'll be doing some hardcore plug you could build a first person shooter in that, with hypermedia. And I'm gonna be writing plugins for that, but the plugins that are there are good and done.
Speaker 2:Like, so I'm ex I want to see people explore the ideas of hypermedia more than I care about the implementation. I just don't know what that led to, because the problem is it's almost like a benchmark. You could totally game that in a million ways. And people like, oh, look how fast I'm updating my screen. I'm like, yeah, but you're updating.
Speaker 2:I can also do that in because again, it's just declarative. I'm still writing TypeScript or JavaScript or or I have that thing. So anything you can do in React, I can guarantee you I can do in Datastar.
Speaker 1:Well, and, like, just to throw a little, like, you know, bonus in there, you're potentially doing that on a 1,000 computers at once. Yeah. Right? I mean, this is like so, you know, you do something in React, You're doing it locally, and you are that's you can maybe I don't know. You know, it's like I sometimes wonder what exactly they're talking about in terms of, like, user experience.
Speaker 1:Like, is it, like, the transition from one div to another? Like, the fact that it doesn't, you know, like, whatever that sort of experience is, like, they really want, like, whatever that is, you can deliver that to multiple people at once.
Speaker 2:And see, the thing that was interesting is one person said, I really think that this approach is flawed. Like, when I click on a user add user button, I can show that add user thing instantly. And I'm like, okay. That's great for the hello world or, like, the getting started. But, like, in the real world, like, I deal with military stuff.
Speaker 2:You have things called dissemination controls. And, all of a sudden, those can change on the fly. So as soon as you say, I wanna add a new user, there's a lot of checks to happen to see if you're actually able to add that user and what that interface is to you. Because if you're on a zipper or nipper network or all these things, you you the that interface changes depending on context. And I think a lot of people have missed in the spa and the react world is they're talking about their little happy path as opposed to the, like, context of what the real world is happening and what's going on.
Speaker 2:Like, you may not be allowed to see the thing, or you may get a special bonus for this time of year, or, like, whatever. There's a lot going on to adding a user, and as soon as you get off the happy path in react review, it's a nightmare. Like there's so many checks. There's so many things. There's so many things you're turning on and off, and the also thing is, at least from a military standpoint, it's not secure.
Speaker 2:All of your logic is right there. Someone can literally look at your devs and see, oh, if I was having access to that thing, I could turn this thing on and you find vectors for, dealing with things. So for me, it's about security and all these other things that we're not even talking about real time. It's just talking about the security of hypermedia versus a native app.
Speaker 1:Yeah. I mean, a source of truth. It has to be your server. So like one of my big things, and I I, you know, did an episode on this as well, it's just like why do it twice? Like you have your source of truth already.
Speaker 1:It's you need that. You cannot, you know, and I've seen some Twitter battles on that too.
Speaker 2:Well, I and I really would look like, I didn't talk to Ryan Florence at the thing, and I haven't really talked to much of the the developers of the frameworks. But I would take any comer for any frame. If they're like, I can make something you can't make. Like, I want the Ryan Florence thing of, like, here's a react app. You can't do it, and I will make it faster and smaller and use less resources.
Speaker 2:I guarantee it. I just need to see the app to, like, show me because I'm I'm ready to go. I just don't know how to get the word out that There's no Olympics. I'm not better, but my approach is better. If that makes sense.
Speaker 2:And you would be better if you use this approach. Like, if you're a good developer, you'd be great in this.
Speaker 1:Right. Yeah. There's no web olympics and somehow there needs to be. Somehow there needs to be some sort of, not just a benchmark, but actual like and I think, you know Adam Wadden from Tailwind has talked about this a bunch where he's like people are like, ah, Tailwind's crap, like, you can't do real stuff with it, and it's like and this was early on. Now obviously everybody uses it so everybody knows it's good or, you know, but it's like he his big thing was like let me just like let me go up against somebody.
Speaker 1:Like, 1 on 1, you build it with CSS or whatever your version is, and I'll build it with Tailwind, and we'll see like which is faster and which is easier. You know, it's like Yeah. I wish I do wish there was something because this sounds like
Speaker 2:I agree. I feel it's it's such a because the problem is that you can easily get into the code now where you're like, look. I made it this percent smaller. This like, I didn't aim for data star to be smaller than AT max. I actually thought it would be bigger because I'm doing a lot more stuff.
Speaker 2:I'm including multiple libraries worth of stuff. Right? But the fact that smaller is a benefit. The same thing happens here where if I can show that it's less code, it's less stuff over the wire, and the code you write is simpler, like, I don't I can easily see that say, oh, you're just playing code golf. But I I wanna look at the metrics of the machine.
Speaker 2:I wanna look at, like, how many resources you're using. I my my I did that when I did that talk, I did a full 3 d engine with a quest system teaching lessons with a 3 d city at, you know, a 144 frames a second of stuff. And had a NAT server embedded, so all the pops up, all the key value, persistence, all that stuff. A full HTTP 2 server, all that stuff. And it was 13 megabytes.
Speaker 1:Wow.
Speaker 2:The the executable is tiny. And I think that matters because that means your Docker containers are smaller. It means it'll run on my little junk laptop or on a epic system, and I don't have to make any changes to it. It also like, there's a lot of things that I think people aren't looking at when they look at a framework. Like, most of the things we talked about for your application had to do with, like, let's talk about your database.
Speaker 2:Let's talk about how you're making your data. Almost none of it has to do with data start. Data start, I think once you get into the details of building with it, you're gonna see it as a you're gonna laugh because it's you're like, oh, that's it? Oh, I can just then you just get to your actual problem. So
Speaker 1:Yeah. Well, that's how I felt about HTMX as well, you know. I mean, for me, that that was a big mental yeah.
Speaker 2:I think it goes even farther. I really do.
Speaker 1:Yeah. So I mean I'm I think I'll, you know, I'll start to wrap up here because, this has been fascinating. I'll just I'll just, like, kind of big picture, I think Carson has the right mentality of some of this stuff, of hypermedia is a big tent, and, like, I think what you're doing with hypermedia and with pushing those boundaries, is awesome. And I think it's like I think the bigger picture of, you know, pushing back on some of the SPA stuff and, like, you know, I don't even I'm not even interested in, like, an argument over it. I just think, like, the experience and some of you know, this is a better thing for some developers.
Speaker 1:And you know, not every some developers are always gonna love sort of the React, and and the problems they're solving work great in that space. But a lot of problems, more than people think fit under the hypermedia, you know umbrella. And I think the bigger that umbrella is and and the more stuff that we can do, just the better. So I think this is awesome. The data star side is awesome.
Speaker 2:Oh, thanks. I really appreciate On the essay page, I actually have a thing called grugs around the fire. It's one of the first little essays I wrote about, we all see ourselves as grugs. We just are worried about different ideas of what complexes.
Speaker 1:Okay. Yep.
Speaker 2:So I would highly recommend taking a look because, yeah, I do really think that we're all just trying to get back to simplicity. It's just I tend to worry about day 2 simplicity as opposed to caring about day 1 as much.
Speaker 1:Interesting. Yeah. Nice. I'll check that out. Awesome.
Speaker 1:I'll I'll include a link as well in the podcast. That's great. Minor notes. Awesome. So well, thank you very much for talking today.
Speaker 2:Yeah. Thank you. Glad to get the word out. So
Speaker 1:Yep. Anytime.
Speaker 2:Alright.