Subscribe
Share
Share
Embed
Join me while I learn HTMX and talk at you about it
Twitter: @htmxlabs
Nice. What do you got for, what do you got for a drink here?
Speaker 2:I got the Big Sky DevCon mug just for this.
Speaker 1:Oh, man. Have mugs there?
Speaker 2:Well, it was a speaker gift, which is like Awesome. One of the best gifts I've ever received.
Speaker 1:Yeah. Very nice gun bug.
Speaker 2:That is
Speaker 1:a good one. Yeah. I was there at the I was there at the Big Sky Dev Con and,
Speaker 2:did we meet? No.
Speaker 1:I don't think so. I'm not a big meeting person. No. I didn't I didn't see you there, but, I loved your talk there. It was really good.
Speaker 2:Oh, thank you.
Speaker 1:Yeah. That was one of the it's funny. There was some stuff I wasn't really expecting there at Big Sky. Like, you know, I I sort of came to learn more about HTMX. I've been getting into it and stuff like that, and sort of this bigger picture, you know, I think your talk, about what was it?
Speaker 1:The life and death of HTMLX
Speaker 2:Yep. I
Speaker 1:think it was called. Yeah. So just this concept of, like, if all goes well, HTMLX will just slowly subsume into into HTML and disappear, and we'll have all the power of, you know, what HTML could have been.
Speaker 2:Right. Right.
Speaker 1:So I thought that was
Speaker 2:interesting. Be. Yeah. I think there's there's a an attitude that happens sometimes with HTML where you're like, well, we should have done this thing 10 years ago, and, it didn't happen, so that's a bummer. But I think HTML is gonna be around for a very long time, and that's the premise that informs both of the talks that I gave recently.
Speaker 2:And if you think of HTML as a very, very long lasting technology, then it's really not that big a deal that we didn't do something when we should have done it 10 years ago if HTML is a, say, 100 year technology. So I totally get the impulse because I feel that way too. And especially when you're an up and coming web developer, you're like, wait. Why can't forms do put? There's just like there's some very obvious things that are missing, but, that doesn't mean that they can't ever be there.
Speaker 2:And that's part of how they structure the web platform.
Speaker 1:Yeah. Yeah. And I like I remember you mentioning at one point, I think, just this idea of like the platonic ideal for what a minimal, like, representation of what you need is, like, you know, to do a I think it was a post request or something like that. And you mentioned Yeah. HTML has like that possibility, but like, I mean, I feel like that's why HTML has stuck around so much.
Speaker 1:It's like, what how much smaller can you get? Or do you would you want to get, you know, to have like a visual hierarchical representation of data than like tags and stuff inside it and stuff like that. Like, you know, it just makes a lot of sense. So I feel like, you know, betting on it for the long term does make sense.
Speaker 2:It's also very good at there's there's a couple of things that make HTML, I think, a really durable technology. First of all, it's it's super cheap. If you think about, like, what it costs to get started with Swift development and you have to learn, like, SwiftUI, and you have to buy the Apple developer toolkit, I think. I don't know. I'm not an Apple developer.
Speaker 2:But there there's a there's a lot of stuff involved in getting your compiled software project of any kind to somebody else's computer and distributed that way. And the web, the hard work has already been done for you. The the getting all the software that needs to be on somebody else's computer is there, and all you have to do is, structure a couple tags. And you have access to the computing power, in a more limited paradigm, but, nevertheless, a sufficient paradigm to do lots of very, very powerful things, like look up stuff on an encyclopedia or do online banking or whatnot. And those applications are what I'm interested in.
Speaker 2:I think that there's a lot that can happen in that space. And that in that space, the limitations benefit our ability to deliver good experiences there.
Speaker 1:Yeah. So so what I guess, like, I've heard you talk a couple times about sort of the stuff that you envision for this, and and I have my own kind of picture in my mind of what that is. But, like, what are some services, like, you feel like should be part of that? You see, you mentioned banking as a possibility, and, you know, I guess, like, you might think you mentioned in one of your talks, you know, a library system. Like you want this to be around forever.
Speaker 1:There's no need for it to have any special fancy technology. Like what else kinda do you feel like falls into that or does everything, you know, almost everything fall into that which is kind of where I'm a little bit at.
Speaker 2:Yeah. It it is almost everything. That that's the honest answer. Anything that requires a network request to, to be fulfilled and to have some transaction take place. So it's it's a paradigm that HTML is best at.
Speaker 2:So banking, good example. Another one, flights. I mean, why would you why would you book a flight on the phone when the information density available to you on your screen and via the web browser is is drastically, more than any other way that that information could be presented to you and the flexibility of it. So, just a lot of kinda daily bureaucratic tasks that have to get done are very good on the web, and that's not even including a lot of the things that are really fun about being online. Social media, if if you think that's fun, games.
Speaker 2:You know, there there are there's there's a ton of, like, really exciting imaginative possibilities. But even if you don't consider any of the really, any of the stuff that is is sort of artistically or creatively satisfying, there's a lot of just tasks that we have to do that have now become Internet connected tasks, and the vast, vast majority of those tasks can be done well just on the web platform.
Speaker 1:Yeah. Yeah. I mean, this this is kind of like I struggle sometimes with to tell people the sort of stuff that I work on because they're like, oh, I build websites. And it's like, well, that's okay. I don't I just
Speaker 2:started saying that too. That's my news. I make websites.
Speaker 1:Yeah. And it's like, there's you know, if I try
Speaker 2:to get into it, it's like Mine? Like, no, no, not like that.
Speaker 1:Yeah. That's the thing. So I'm like, I don't know. You might need like a Wix thing or something. But like Yeah.
Speaker 1:I'm like, I guess I build web apps. And it's, like, the distinction is, like, you need to be able to change the data and it needs to know who you are. Like, I don't like, that's what I sort of think of. And, like, I just the more stuff that I work on, I'm, like, this is most of the way you know, I I I this most of the things out there, I'm like, this is starting to fall under the under this category.
Speaker 2:Yeah. I I've had that same realization, and I keep trying to push the limits of that paradigm, and I keep not hitting the limits of it. And the more you do that, the crazier you feel because you're like, wait. But but every everything I've worked on has needed, like, 3 different NPM workstations to build, and then I had to run a Docker container so that that could interface with the Redis, which made the Postgres database faster. And I'm starting up these 5 services just to get one website web app to run.
Speaker 2:Those people have to know something that I don't because I'm not doing that anymore, and it doesn't, matter. But, I don't think I'm crazy. I I do think that and that's part of why I think there are a lot of people, especially in the h t m x community, who are frustrated that the obvious benefit of not doing all that junk, hasn't, like, immediately changed the way that websites are built built. And first of all, it has dramatically. I mean, for h tmx to be as successful and as much of a brand that that you would start a podcast called HXpod, it is far more success than basically every open source project will ever see.
Speaker 2:And and 2, again, if you take seriously the premise that the web is gonna be around a very, very long time, then it doesn't matter that we did all this junk in the 20 tens, if we are able to develop sustainable durable practices today.
Speaker 1:Yeah. So so let me just, like let me let me start off by saying, like, in this in this conversation, like, I am a 100% sold. I like, I've watched I watched I watched your thing, and, like, you know, this is just, like, sometimes in a podcast, it's nice to have, like, a a back and forth, or I'm arguing with you. Yeah. We're kinda, like, but, like, I just I watched, you know, the 100 100 year web service.
Speaker 1:I I think you called it. Yeah. And it's like and and and the talk at big sky, but that the 100 year web service particularly just, like, felt like, like a revelation where it's like
Speaker 2:Thank you.
Speaker 1:You're you're bringing together all these things that have kind of been, like, bouncing around, in my head and, you know, I think for a lot of people, like you said, SQLite's having a moment right now. Definitely.
Speaker 2:That's a big
Speaker 1:part of it. Yeah. And and and there's a reason for it. You know, there is this, like, overarching complexity. And and can I just can I redo one of your own quotes there?
Speaker 2:Please. Yeah. And that would be helpful for the listeners as well because they may not have seen the talks.
Speaker 1:So so you know the the talk I'll just like preface the talk a little bit, just from my perspective is like the idea that you're building something the 100 year web web service. You're building something that's gonna last forever. So immediately you have to toss aside the build process because that's not gonna last for 2 years, you know? So Yeah. So there's a lot of stuff.
Speaker 1:And so you go through pretty systematically and talk about, you know, 4 different parts, the web, the d the database, the app logic, and any additional client stuff. So between those things you can sort of bring them together. But let me read you this like a quote that like, I just like I had to pause and go back and just listen to it again. The experience of refreshing the page or clicking on a quote hard link is identical to the experience of partially updating the page. And that's something that just quietly happened in the last 10 years with no fanfare.
Speaker 1:All of the people who wrote basically basic HTML got a huge performance upgrade in their browser, and everybody who tried to beat the browser now has to reckon with all the JavaScript they wrote to emulate these basic features. So that, I just like That I feel like, you know, the fact that it happened quietly, and in the last 10 years, and if you're you know, if you've been a developer like me for the last, like I don't know. I want I don't want to say 20 years, but, you know, I was certainly there 10 years ago. And I've been through the That
Speaker 2:was not, by the
Speaker 1:way. Okay. So you're you're I feel like you're early on.
Speaker 2:For 5 years I've been doing this.
Speaker 1:Okay. So for those of us who have been around, like, I remember what it used to be like and why when SPAs first came out, I was drawn to them. And I I wrote a lot of stuff, and I started with Ember and then Angular and eventually moved to Vue. Yeah. And, you know, I had my own awful SPA that I built, and it it's just like what a mistake, on every level.
Speaker 1:But I remember why I did that. It's because nobody liked this kind of old school thing where you, like, hit hit post, you know, you hit your, like, submit and then, like, you wait and you don't know if your browser's broken
Speaker 2:Yeah.
Speaker 1:And you don't know what's going on and you click a link and everything, like, moves around and so it was like that was all there, and that's literally what people remember that, like, people have that ingrained in their head who were developing 10 years ago. And Can
Speaker 2:I challenge that for a second or just Okay? Yeah. Ask a question because I first of all, I used the web at that time. So I know exactly the kind of experience that as a web developer, you're like, this feels clunky. I don't want it to feel like a web page from 2005.
Speaker 2:I want it to feel fast and fluid. The part I wanna kind of ask more about is you say you click a thing. It's a post form. You don't know if the browser is broken. And, by the way, I I very much remember when you click a form and then you, like, either click a refresh or back button, and it says, do you wanna resubmit this data?
Speaker 2:And as a user, I'm like, I don't know. Why are you putting that on me? You you should know what's happening here. I have no idea. Is it bad if I resubmit this data?
Speaker 2:So Yeah. The yeah. The part I wanna ask about is, is it was the SPA that you built, in the kind of failure case, where the the thing was submitted and the network didn't, like, fully respond you know, there's something bad happened, which always happens because networks are unreliable, even under the best of conditions. Did the did the failure case get better communicated to the user? No.
Speaker 2:If so, how? Oh, okay.
Speaker 1:Well, then It was bad. It's all bad. Like, what I lost doing that, and I didn't know I was gonna lose all these things when I started. You know, I was like okay look we need to make it faster which means like we're going to have 1 Javascript thing. It's going to handle like we take it and we get HTML.
Speaker 1:I sort of I think of it now as like the whole thing was basically like an HX swap OOB system. Yeah totally. Yeah. Where you just like the back end threw everything in It's
Speaker 2:just going here and it
Speaker 1:goes to the
Speaker 2:top of the page to the bottom of the page. Yeah. Yeah. Yeah.
Speaker 1:Sounds great. All of a sudden, like, none of my users could use their back button anymore. None of my users could refresh. Like, none of my user you know, it was like I lost all these things that I had taken for granted and by that point it was too late. So, you know, obviously that's been solved in some versions of SPAs.
Speaker 2:But like Sort of. Sort of. Has it?
Speaker 1:Yeah. Has it? None. And it's I mean, honestly, it's still even with HTMX and stuff like that you still need to think about it. Like, it's still, you know, the web one point o, the the multi page app, like, man, they that is solid.
Speaker 1:Like, they did solve that.
Speaker 2:It's really solid.
Speaker 1:Which was really nice. Yeah. And and so I understand still trying to use that as much as possible.
Speaker 2:One of one of my theories about user experience on the web is that, and through no through no fault of their own, but users don't have a really good grammar for describing what is or is not a good web app experience, and not developers even don't. So how on earth would users be able to do that? But, and I I talk about this in in that piece you quoted, which is called who's who's afraid of a hard page load. And the when I reflected on my own experiences as a web user before I had the the grammar of being a web developer, I realized that the the websites that I most enjoyed using, the websites I felt most comfortable, on, and the websites I felt like I understood how the behavior happened were ones that had fundamentally multipage structures because they use this common grammar that browsers have taught us how to interact with a web page. So, in in that piece I talk about, I used to have an iPad Touch, which, only had Internet when you were connected to Wi Fi.
Speaker 2:So Wi Fi felt like this really precious commodity. And And what I would do is I would go to websites and I would load them, and then it would not navigate because I knew that as long as I didn't click anything on the page, the page was loaded. It had gotten the thing, and now it was on there. And I knew what kind of interactions with the browser would call would would mess that up. And, as in, like, the 20 you know, the middle of the 20 tens when a lot of websites wanted to feel more modern, a lot of applications switched to a more single page app like architecture, I knew instinctively, even though I didn't name it, I knew which apps I had to baby.
Speaker 2:I I knew which websites. Mhmm. If, the Internet cut out in any way, I was just screwed, that there would be no recovery. If I refresh the page, the whole thing would break. Like, I just knew instinctively what even visual cues in the way the app was created, told me, the user, hey.
Speaker 2:Be careful with this one because you're not gonna be able to click the back button. You're not gonna be able to click the refresh button. And if you, you know, pause midway, you have no idea what's gonna get saved. So those Yeah. So yeah.
Speaker 1:Yeah. No. I mean, absolutely. And and this is one thing that, you know, you weren't around for, so I don't know if you've got any of the the context for this, but I also went through and I don't not I'm not saying exactly that I think SPAs are gonna go this direction, but I was there 3000 years ago when Flash was the the thing. Okay.
Speaker 1:You were there for Flash.
Speaker 2:Okay. As a user.
Speaker 1:As a okay. So, yeah. So I was I was, you know, at the time kind of just dipping my toe into into building websites for people, but I was building them for artists. Artists and musicians. Interesting.
Speaker 1:Yeah. And so they, you know, Flash was cool. Like, you could do these cool things. But What were
Speaker 2:you using, by the way? What was your, like, how did you build the websites? What program? Because I remember there was, like It
Speaker 1:was yeah. Macromedia Fly. I mean, it had its own sort of IDE and stuff like that.
Speaker 2:Yeah. Yeah.
Speaker 1:But you would then, like, you know, export and SWF, which you could just embed. Yeah. And then it could sort of interact with the stuff around it, but sort of not. So,
Speaker 2:you
Speaker 1:know, it it had some some quirks, but it almost, you know, there's something similar there where you're sort of building in the same way that an SPA. It's like using JavaScript to kind of just build there was also these things called applets where it was like just this little self contained system
Speaker 2:Yeah.
Speaker 1:That lived on your in your client, in your browser, and Flash was kind of like that. They tried to integrate it a little more, but
Speaker 2:Yeah.
Speaker 1:But Flash came and wins.
Speaker 2:Was a Java applet for a while. The the web game Runescape. So anybody who looked would see like Java like load loading bar.
Speaker 1:And games are great for stuff like that. Like Yeah. You know, I think they're a self contained thing like that. But like What? I do think there's a reason Flash isn't around anymore.
Speaker 1:And I think part of it is, like, what you can do with HTML. And, like, that's the stuff that I think you're right, that this is gonna stick around. And I don't necessarily know the SPAs are gonna go, like, the way of the way that Flash went and just kinda disappear, but, like
Speaker 2:We can hope. Yeah.
Speaker 1:I mean the stuff that you're talking about in that quote that you know, all these things that quietly happened when you And this is like a big talk, Anthony Alaribe also at Big Sky Dev Con talked about Yeah. These people these myths that people
Speaker 2:That's right.
Speaker 1:Hear about MPAs, which was another, you know, that sort of got me thinking about this and and what you're talking about here. It's like I didn't really notice this performance upgrade either. And Right. This is what's giving me this kind of like, you know, bullish, like, just optimism on this this way of building. I mean, besides just my own experience where you can sort of see the benefits over time of you build something and then you don't have to touch it that much.
Speaker 1:Right. Yeah. Like, that's a big deal. That saves me, you know, I'm a sort of a solo dev, you know, sort of working on different projects and stuff like that, and that just saves me, like, a ton of time. So when I think about that for other people, you know, that's the sort of thing that makes me really believe in the stuff that you're talking about.
Speaker 2:Yeah. One one note about Flash, by the way, and I think this kind of speaks to some of the advantages of the web as a place to build, even a place to build a thing like an SPA or a game or whatever, is that Flash is back, actually. You really can't make new games in Flash because there's no macromedia Flash, but a number of browsers, at least Firefox and Chrome, have a built in web assembly Flash emulator called Ruffle now. And so, like, 3 years ago, there were a bunch of articles about how much of the web is lost because SWF files can't be played in the browser. Apple famously killed Flash by not allowing it in the iPhone.
Speaker 2:And now my my mobile phone just has flash in it. People don't make apps that way anymore. But the fact that it was just on the web and that there's just an asset, made it possible, you know, a number of years later to recover that in a way that's, like, really, really hard for, native much, much harder for native applications to to emulate. So that that's kinda neat. And the other thing about, well okay.
Speaker 2:So, anyway, moving on from Flash. You one of the, like, early SPA frameworks, if you would, do you ever build an Angular app?
Speaker 1:Yeah. I I will say I didn't really get that into Ember or Angular, but I Yeah. I experimented with both, basically.
Speaker 2:Yeah. So I I've never built an Angular app from scratch, but I did I did inherit 1, when I worked at the Washington Post. And the the nature of the app that I inherited was that it got built by contractors in the mid, 20 tens, and then basically was untouched for, like, a very long period of time.
Speaker 1:Yep.
Speaker 2:And so it was a little bit of a fossil frozen in amber that missed a huge chunk of web development trends, from 2016 to 2022. And Mhmm. That nobody wants to see an Angular app today. Right? Like, if you look at a code and you see you go, oh god.
Speaker 2:I have to deal with
Speaker 1:this. What is n n g dash or something? Yeah. Yeah.
Speaker 2:Yeah. You see NGs everywhere, and you're like, wait. Where does the there's all there's, like, there's data, NGs, and there's 4 n there there's just, like the data model makes no sense to modernize. I'm I'm really sorry to the Angular heads out there, but, it just it's very hard to wrap your head around, an existing, like, Angular 1 application. However, because it is a thing that came out of the trend, because the the zeitgeist then was to add attributes to HTML, and there really wasn't a lot of thought that we would be running all the web stuff in JavaScript.
Speaker 2:JavaScript was still kind of secondary to the actual DOM. There are aspects of that application that enabled it to basically be, frozen in time for for 7, 8 years, and nobody nobody worried about it. Part of that has
Speaker 1:to do
Speaker 2:also with how Angular is served. So Angular, at at that time, just a a JavaScript file, like a couple megabytes, I think. But, nevertheless, just a JavaScript file that's in your browser. And so nobody's getting security warnings being like your Angular 1 has you know, is a is a problem now. It's just it's just a file that's in your browser.
Speaker 2:And and HTMLX, in many ways, I think, is a spiritual successor, if not in application model, but in development model to the way somebody might have built an Angular one application. However, far and this gets into the library versus framework thing, but but far, far less of a conceptual burden because it's it's really just an extension of HTML.
Speaker 1:Yeah. Yeah. And and I think about that a lot with just kind of how I mentally separate, you know, the different sort of JavaScript frameworks and and libraries and everything, and it's like there's just this massive difference between is this building a virtual dom and turning your site into everything as a virtual dom and, like, is this just your dom and it does a few things.
Speaker 2:Plus some extra stuff.
Speaker 1:Yeah. And so it because like I mean, I'll tell you that the first way that I sort of came across h tmx and, sort of got got into it was I was building a very large page. Like, so it's it's, you know, it's a project that I haven't I haven't really moved on in a while, but, the the idea is basically, you know, you're writing something. Yeah. But it's could be long.
Speaker 1:You could have the equivalent of like 50, 100 pages worth of writing, but it's all like got, you know, bullet points and tags and stuff like that. So Sure. You could sort of picture it. And I was just thinking like okay, you know, I want this to feel slick. I want it to feel good.
Speaker 1:And when I tried to do it I come from the Laravel kind of development background. So I tried to do it in Livewire. I love Livewire. Caleb Porzio, who built Livewire and Alpine, I think is really sharp and, like, it's sort of a hypermedia feel. Very good.
Speaker 1:But Livewire, like a lot of other tools that sort of have to deal with the front end and back end, does put everything into a virtual DOM. Yes. It has to process everything. And so That's why I haven't used it. Yeah.
Speaker 1:And so I was using it and I was like, okay. And then I do I was like, you know, I should stress test this a little bit. Like, I want this application. If if you're like writing, some people like to have, you know, command f and they find the word they're looking for, you know. Totally.
Speaker 1:So I like that and that's what I'm building on building it for me. So, so I wanna be able to show everything. I was like I better stress test this and I'll put, you know, a thousand paragraphs. So I just, like, ran up a for loop, put a 1,000 in there, and all of a sudden, it was just dead slow. Like, first of all, it didn't show the page for, like, I don't know, 5 seconds or something like that.
Speaker 1:Yeah. And then I tried to edit something and it was like, you know, it has to build a virtual DOM out of everything. And that's a huge overload. In JavaScript. In JavaScript, like JavaScript is not that fat.
Speaker 1:You know, it's like it No. It it makes you pause. It's fine. Well, it thinks. You know.
Speaker 1:It's like you just you just wanna use it sparingly. So so at first I did that, and then I was like, okay, maybe I'll do this with Alpine because it's like that's sort of actually similar, but you know, it's like I was like Livewire might be a little too much. I'll try it with just Alpine. So I did the same thing with Alpine. Man, it's like a little faster, but it's still, like, we're talking 5 seconds to load the page.
Speaker 1:So I was like, I'll just get to the HTML and see how slow that is with a 1,000. So I go to the HTML and just do that lightning fast. I'm like, okay, this is good. So then I'm like, I'm reading a little bit of HTML. So I'm like, you know what?
Speaker 1:Let me see if I just do this with HTML. And, you know, I just added HTML at the top. I was like, you know, I don't have to change that much. It's just HTML. And if then it's like when I edit it, that's when the HTML comes in.
Speaker 1:It's not building a virtual DOM. I don't need to declare anything. You know? It's just like so I put HTML, I rewrote the HTML, and it was within milliseconds of the HTML.
Speaker 2:Oh, that's awesome.
Speaker 1:I mean, that was just like to me, this was like a whole new paradigm and kind of change, you know, change the way that is. And so this is like when I think about tools like this and, you know, in your 100 year web stack, you know, you had those 4 parts and maybe we can go through those. But Sure. HTMLX fitting into that because, you know, the first one in your web part there was HTML and CSS. Like those are the core for displaying on the web.
Speaker 1:Right? Yes. And so so Okay. So so the 4 parts for your for your thing are is like the web, the database, and so what I mean, I I sort of from the talk, I my understanding of SQLite is like because it's a single file. Yeah.
Speaker 1:What what's the sort of big picture for SQLite as to why that would be the the main choice?
Speaker 2:So so what you're referencing is is basically the the concept of the talk is if you make an HTML file today and you just put it on a server somewhere, and there are many many cases of this, It'll last forever. There will always be an HTML file that will render, maybe not identically, but it is it is robust to the changes in the way that we deploy Internet infrastructure. And so the question is, can we take that general robustness and apply it as much as possible to web apps? It'll never be as good, really as an HTML file because we just have such great abstractions around the idea of, like, saving a file for a long period of time, but we can get close. And we wanna take those concepts of what's good about the file and get get that to something that might be more that is more dynamic, so a data a database backed service that you can update and interact with.
Speaker 2:And the first the hardest part of that is the database because that's the that's the dynamic bit. Right? That's the part where users are gonna change what you have, and and that's way more dynamic than a file that they can't. So the thing about SQLite, unlike any of the other databases, is that it doesn't require a separate service. It's just a file.
Speaker 2:It's just a library in your application. And I don't have a I don't have a technical term to describe this concept, but, and maybe that's that's a thing that I would like to make more academically robust in the future. But, basically, what you're trying to do is you're trying to remove as many moving parts from your application as possible. And what is or isn't a moving part is a is a little bit, wishy washy right now, but I'm confident in saying that SQL, that Postgres or MySQL are moving parts. They are they require active may orders of magnitudes more active maintenance than running SQLite.
Speaker 2:SQLite just kinda happens. And one of the big gains of the last 10 years is in both the, cost effectiveness of raw computing power, and also SQLite has gotten a lot better and able to take advantage of that. Now Richard Hipp, the creator of doctor Richard Hipp, the creator of SQLite, has been, you know, saying for years, hey. If you have a website with moderate traffic, you're absolutely fine with SQLite. But people are now it has, you know, right ahead lock mode and other conveniences that make people believe him a little bit more.
Speaker 2:And so what that means is that, I I and I said this in the talk. There the the first thing, if you try to make a web service today and you try to stand it up and you're like, okay. I'm leaving it alone. It's up there forever. Well, it the database you set up in one of 2 ways, most likely.
Speaker 2:There's a physical computer somewhere that is, likely different than the physical computer that's hosting your website. And you have to, like, I don't know, open the closet and make sure that it's still running and still connect to the Internet. Or much more likely, you paid for a managed hosting service. And, eventually, that managed hosting service is gonna get sick of hosting your outdated version of Postgres because they they that is not cost effective for them to manage every single version of Postgres that's ever been released indefinitely. And so they will start pushing you to migrate it.
Speaker 2:And that's there are these in in application maintenance, there are these cut points. And, again, this is not a robust concept, but it is one that I think everyone can identify with on some level. There are these cut points where the the the organization or person or team that is in charge of maintaining an application that has not had to deal with this application anyway is suddenly reminded that it exists and that if they want to keep existing, they're gonna have to do something. And that is when, the boss might say, alright. Fine.
Speaker 2:I will resource this upgrade, or I won't. Or that is when you start calling things tech debt because this is a thing I no longer want to do that I have to do, and it's taking away from whatever my current priorities are. So Postgres introduces lots of those. It creates moments where somebody has to do work to keep this thing running, and SQLite introduced because it's just a file that is collocated with whatever your server is. SQLite never does that.
Speaker 2:It it just keeps working. And that's pretty magical and I think way more important than people realize.
Speaker 1:So so this is like I'll just say this is like shocking to me when I so when I was I was watching, your talk on this because, you know, I've been developing and building, like, pretty big sites for, you know, 15 years or whatever. And I just default to MySQL. Like, I just do and that's How you defaulted? You know, it's like it's always been fine. And luckily, I think MySQL I haven't had to deal with a lot of upgrades.
Speaker 1:I'm always running my SQL on the same server that my website is. Like so far, that's all been mostly fine. Yeah. And and that's you know, I appreciate that about MySQL, I suppose, over someone. I never got into the MongoDB, and I never got into some of these other Postgres and stuff.
Speaker 2:I can talk for an hour about MongoDB. I won't we can just we can just say you never got into it, and that's fine. Yeah. You won.
Speaker 1:Yeah. So but, like, listening to what you don't you you've been saying about SQLite and I'm just like it's so obvious. Like, that's what I should be using. Like, the sites that I work on are not millions of users. I work on niche sites with, you know, maybe hundreds of users at a time.
Speaker 1:Yeah. But they're doing, like, business logic. Like, it needs to hit the database. The database needs to be fast. Absolutely.
Speaker 1:Yeah. But I need to be able and I need to be able to back it up. And like what's easier to back up than a single file? Like there's nothing, you know, it's like Right. Then you just can't like okay.
Speaker 1:Just like run something that copies it every hour. Whatever you want to do. Like you just don't it's not you know, don't worry about it.
Speaker 2:Shell commands. Yeah.
Speaker 1:Yeah. And so I'm just like I'm just I'm surprised at myself that, like, with all the, you know because I started looking at SQLite, you know, recently in the Laravel world. It's kind of, it's been picked up. There was a couple kind of there's a big course out right now with, Aaron Francis, and and I haven't looked into that yet, but it's like when I sort of now that I'm actually looking at SQLite, and I'm like, okay. It's robust.
Speaker 1:It's running on, you know, what, 4,000,000,000 phones right now as we speak. It's like in every single system you can imagine, and it basically just works In airplanes. In airplanes. Yeah. It basically just works, the same as my sequel, like, the queries.
Speaker 1:Like, how different are the queries? I haven't used it enough. Every query I've ever tried in SQLite has worked. Like, I don't maybe there's some difference between my sequel
Speaker 2:and SQLite. Function that you wish was there and it's not. Like, they have everyone's got their own extensions, you know, but for the most part, right.
Speaker 1:Yeah. So I'm I'm I was just like, I'm like, you know, that's so obvious now that I think about it. Like, why am I not using SQLite by default? And so I I feel like that's gonna be an easy switch in the next kind of project I work on.
Speaker 2:Well, let me know how that goes. And I wouldn't be hard I mean, we only have so much time in the day to be questioning our default assumptions and familiarity. So, again, it's a long, long process.
Speaker 1:Well, here's the thing though. Like, because of the type of work that I do, which is, building stuff for people that I am ultimately responsible for. Like I it's not getting passed off to anybody else. Yeah. And so I have such an incentive to do what you're talking about.
Speaker 1:Massive. To build something for the long It's like, you know, if I can build something really good and I'm still, you know, getting paid to maintain it and stuff like that, if I can make that maintenance as easy for myself as possible and And you're processing. Regardless Yeah. Regardless of whether I'm even getting paid for it, if the maintenance is easy, I'm doing more interesting things. I have more Right.
Speaker 1:Time to experiment with HTMX podcast stuff. You know, it's like my incentive is what you're talking about to, like, build systems that are not gonna need to be changed. I'm even a little bit starting to question my Laravel, like, some of the Laravel stuff because, you know, every time I go into an old app, I'm like, should I upgrade this? Like, gosh, should I upgrade this?
Speaker 2:Like That's the that's the cut point. That's the moment where you're like Do it. It propels you. You're like I'm not gonna deal with this so I'm I'm just gonna leave it alone.
Speaker 1:Well, but okay. So first of all, h t m x has actually saved me in that world, in
Speaker 2:that realm. Tell me how.
Speaker 1:Well, so this is this is like 90% of my h t m x use is going into old apps that I thought I can't even bring Livewire into them because I was like, you know what? Most of this sort of fancy front end stuff I do right now, is with like, if I build a new feature and I want it to have this kind of, you know, feeling of like you change something, you get a little partial page update.
Speaker 2:Yeah. Sure.
Speaker 1:Yeah. And I I do a lot of those and people users really do appreciate, having this kind of interactive thing where it reveals stuff as you use it that you need.
Speaker 2:Yes. Definitely.
Speaker 1:So so that's what I'm working on it. And I my thought before, h t m x was like, okay, so to do this on my old apps of which I have, I don't know, 5 or something, 5 or 6 that are active and have a lot of users and they're old. To do this, I'm gonna have to upgrade the the Lara version so that I can bring Livewire into it so that I can start doing these fancy interactive things. Sure. Instead, I'm just I just plop h t m x at the top and everything is there.
Speaker 1:All my stuff. All that everything. It's I feel like I'm like in a modern development world again, and I'm just like I don't need to ever upgrade this app again because, you know, even though it's on Laravel 5.4, that doesn't matter anymore because I don't need any of the other requirements. The HD
Speaker 2:MX version usually doesn't matter. Like, I have I have live apps that are running on HD MX, like 1.8.6, and HD MX is a 2.0 now, and it just doesn't matter. It h t max 1.8.6 does what I need for the 10 attributes I used or whatever. That's that's so much that's so freeing. It it's so such a pleasant makes bank banking websites fun again because you you don't sign this contract with somebody else or yourself where you're like, now in 6 months, I will come back to this and figure out which backwards incompatible library upgrades I have to make.
Speaker 2:It just it's you're free. You're not you're not doing that anymore.
Speaker 1:Yeah. No. Exactly. Exactly. And I don't know I I when I when I start recommending h tmx to people it's like I almost feel I feel like I shouldn't be able to say this, but I do anyway.
Speaker 1:It's like, you know what? You can just use h tmx. It's gonna work in 10 years. And, like, I tell people that I I don't know, you know, I'm like what why can I say that, you know, about some library that has been around for like a year or 2 or you know, maybe it's longer now? Part of
Speaker 2:that stuff. And I
Speaker 1:know that was intercooler, and it's like seriously like and then I'm like you know what it is? It's the values of the people behind it. And this is like you talk about this a little bit in your talk like the values of you know Carson and and you are a core maintainer and there's other people. The people that are involved in this project similar to the SQLite concept like Very similar. It's the the reasoning behind it and, you know, the core values like we are gonna make this backwards compatible.
Speaker 1:If we have to do something big at some point, my my sense is, you guys are gonna make it backwards compatible because that's, you know, not even that I don't even know what you would change, but you're not like, you know what? We need to rename all the attributes. So, you know, hmx 3.0 is gonna happen.
Speaker 2:Never gonna happen.
Speaker 1:We're not using post anymore. Like, I don't like h x. H x is no longer cool. It's gonna be like h t m x. It's a branding thing, you know?
Speaker 1:I was like, that's just not gonna happen. Yeah. So so like I recommend it to people like, if you want the long term, then use HTMX.
Speaker 2:Yeah. There there's a couple ways that those values, There's also, like, a harder if you if you want something more than just like, I trust these 2 guys on the Internet or there's a couple of us. It's not just 2. But, like, then one thing you can point to is is the loading mechanism. Right?
Speaker 2:So and and I also you can download HTMLX from a CDN, so you can just, like, add a link that's like j s, you know, deliver, whatever, slash h t m x slash version. But the way I always recommend people is just copy the file. Literally make a directory called vendor. This would have been called the vendor pattern, you know, at some point. And put h t m x dot j s in there, serve it with a year long cache, and you're done.
Speaker 2:And and that's there's there's there's a mindset shift that happens when you do that, which is no longer is this bundle of JavaScript something that I'm dependent on the APIs because there's a whole set of things I have to do to make changes that's not worth the hassle. No. It's just a JavaScript file. And so if if there's a even if there's a bug, you'll feel a lot more empowered to just edit a JavaScript file that's copied into your project than if it were delivered via NPM. So there's a mind there's there's a there's a mindset there, but there's also a more, I think, robust or a more a delivery mechanism that encourages ownership, in a way that, yes, technically, you can peg, you know, the version, but, yeah.
Speaker 2:The other thing that's true about HTMLX, and this is kinda comes back to the cut points thing, but and also very true about HTML, there's never a situation in which to take advantage of new HTML features, you have to move off of old HTML features. That's the the HTML is the most radically backwards compatible, probably software delivery mechanism that we have. I think that I think that's I can't think of another one. Alright. T Mobile is is really up there, by the way.
Speaker 1:Yes. I saw you. It was like 2,005 was the last, like like major change. Isn't that nuts? That's awesome.
Speaker 2:It's awesome. That's a
Speaker 1:that is really funny.
Speaker 2:Why the the question that that comes to mind when you say, well, why why was the last SQLite major version upgraded in 2005? Well, it's got a different development model than most open source projects. And this is kind of an uncomfortable thing to talk about because there's a lot of people that are very committed to the, let's call it a a democratic method of delivering software, and and that has its place. But if if you know anything about the SQLite project, it it they do accept contributions, but, like, not really. It's very, very hard to contribute anything to SQLite, and there's a handful there's a foundation, and there's, like, a handful of people who work on it, and it's been the project basically.
Speaker 2:It's been it's been spearheaded by 1 guy its entire lifetime. And it makes Unreal. It's unbelievable. Yeah. And it makes different choices that I think are downstream of the, organization that is in charge of that software.
Speaker 2:And those different choices because in part because this is something that that Richard Hipp believes, are far, far more backwards compatible. And this I talk about this in the talk. I I love their I love their documents page that's like, here's all these mistakes we made in the 2000, and we're stuck with them now. Here's the config changes that you can make. And I I love that.
Speaker 2:1, because it's funny. They're just like, we messed up. But And we're
Speaker 1:and we're not changing that.
Speaker 2:And we're not changing it. Yeah. We we want to be compatible with MySQL 3.x or whatever, and that's why you can use double quoted strings and whoops, that was a horrible decision. First of all, that's just it's kinda cute. But, also, it speaks to the just a very different set of values, and that is that, I'm a I'm a new user of a piece of software exactly once, and that's when I set it up.
Speaker 2:And I make it, and I, set all the values. I set all the configs. I do whatever it takes to get that thing working. And then for the rest of the lifetime of that piece of software, I am an existing user of all of the libraries that are included in it. And over time, the the time that you demand of your existing users, is is gonna be orders of magnitude more than what you demand of your your new users.
Speaker 2:So I even though people are like, well, why don't you just change the defaults? Well, because changing the defaults will keep will will impose more on the upgrading of my existing users than it will on all my new users. So I I think that that that there's a lot of things that come from that value. You can imagine a a a benevolent dictator for life who has a different set of values and runs their project completely differently. And that's fine.
Speaker 2:Like, if they're like, I'm gonna make a 3 point o, and it's gonna be completely incompatible with the 2 point o, and that's their choice too. So it's not just the governance model that leads to that type of software, but that's a part of what makes that type of software possible.
Speaker 1:Yeah. And there's also, like, a piece of it that's there's some magic in getting it right such that you can be that backwards compatible. I mean, that that's like something, you know, if if I not that I'm a terrible, you know, I'm fine programmer, but, like, there is a sense where, like, not everybody can hit that home run so that they can then support it and not change it for 20 years after that. Yeah.
Speaker 2:It's true. That's really true.
Speaker 1:Like this guy did it right. You know? And and, the the sequel like guy. You know? It's like and, you know, in my opinion, Carson Gross.
Speaker 1:Yep. Exactly.
Speaker 2:And and I don't know. I've never actually talked to Carson about this, but I wonder what made him because he he talks about HTMX as a intercooler 2 point o. And on the intercooler website, it's like, hey. There's intercooler will be supported indefinitely, but if you want to move to HTMX, then, then you can, and here it is. And there's there's something kind of important about that that is hard to pin down.
Speaker 2:Like, there was no intercooler had users. I feel the Hacker News comments of h two x, every so often, somebody pops up and is like, I'm a very happy intercooler user of 10 years. Thank you for making such a nice little library. So Carson very easily could have said, I have this existing brand name. I'm gonna I'm gonna u and I and that's what the vast majority of open source software developers do.
Speaker 2:They say, I have this brand name, and I'm gonna protect that brand name and and and iterate on it in the way that I want to because my initial choices are confining. And there's there's a social magic in saying, this is a new thing. And, and I will support the old thing, but this is a new thing. And because I have already done the old thing before I mean, HTMX is a is a removal of the intercooler or the jQuery dependency from intercooler. But much more importantly, h t HTMX is a better interface than, intercooler.
Speaker 2:And that's the that's the key, is that h x get, h x post, h x delete, the the swaps and by the way, I think the swap default is wrong. Like, h the default swap is inner HTML, and I often end up changing that to outer HTML.
Speaker 1:It's almost always outer. Yeah.
Speaker 2:It's almost always outer. Yeah. And I, I yeah. And I think I, you know, we go back and forth on this, but I have never advocated that we change that default even though I think it's wrong. I think it is a bad default, because when you make the app and you want an outer swap and you get an inner swap, the first time you do it, you're like, oh, crap.
Speaker 2:Should have been an outer swap. So, that but but, nevertheless, the options in there, inner or outer, before begin, before end like, first of all, they draw on the language of the HTML standard, which is important. The JavaScript APIs for adding, new elements also use before, begin, after, and, you know, did they use that language? That was very smart. But just that that is the for the majority use case of what people wanna do with this kind of software, which is extend HTML with with partial page replacements and make use of the full, set of methods and maybe more advanced stuff than that.
Speaker 2:But that is what HTML is optimized for, and that interface is really, really powerful at getting that done really, really simply. And, I think that I'm excited to see that inspire lots of new people and do different things with hypermedia concepts and the HTML parts from the browser and so on. But that that core idea, that limitation, inherent in that interface that you're mostly gonna be swapping in and out partial DOM replacements with HTTP methods, that was the right one, and that's why that's why it can be the kind of project that you described.
Speaker 1:Yeah. And I mean, I've never used intercooler, so I I can't Me neither. Really compare them. But I mean, I just think maybe this is maybe this is just kind of one of those like you you strike lightning or whatever it's called. But I mean h t m x is just such a perfect Branding.
Speaker 1:For an extension of HTML. Like it's just like Yeah. It's so immediately you get like oh, okay. It's not quite HTML but like it's something a little different a little more but it's rooted in HTML. Yeah.
Speaker 1:So like whatever that I know he said he had some other name that was like a swear word in Danish or something. Yeah. Yeah. So like whatever that was like it just wouldn't have captured. And so like Right.
Speaker 1:You know there's some however that comes up sometimes it's just luck sometimes you just have a great idea but I mean I just feel like that it's so perfectly encapsulates what it is that it's just like that's you know you can't do better than that for for branding.
Speaker 2:There's an amazing alchemy to that and you know, there's a there's a hoary cliche about, something about luck being a function of preparation or or whatever. But Right. You can see that in a lot of Carson's work. First of all, you know, H. G.
Speaker 2:Max, great name, great branding. He's very funny online. So all of that combines with the fact that he'd been doing, JavaScript libraries for partial DOM replacement for 10 year. I mean, that's not insignificant. Right?
Speaker 2:Those things combine. And even if you had all those ingredients, you might not be able to make them combine. And the timing was right, by the way. I mean, if you'd done h t m x 1 point o was released in, like, 2020 or 2021 or something like that. And, if you had as evidenced by similar projects from the late 20 tens that didn't take off, the timing was wrong.
Speaker 2:So timing's a big part of it. But, also, you can see that in the in the writings too. I mean, a big part of the the themes in the first talk and about the life and death of h t max. But also in the second one, where I'm talking about building web services for a long time, is that there are is is the grammar of rest, right, is is is reclaiming rest as a useful way of describing a particular architecture for online services. And if you read, you know, all of Carson's tweets, and he's, like, going off about rest in, like, a particularly deranged way, and he's using BAE IART, and he's, you know, in all caps.
Speaker 2:Sometime one time, he he's like, hey. I woke up and I had a manic break today. I'm sorry. Like, you know, that you look at that, and you're like, that's a very funny person. But, but then you go read the essays on the website, and you realize that there's a very deep, rock solid intellectual core to the arguments he's making.
Speaker 2:And even if it's gonna be 10 years before anybody uses the the phrase rest correctly again, and you're gonna be wading through millions of comments that are like, who cares? It's over. It means this now. Blah blah blah blah blah. It's like, no.
Speaker 2:That there's there is value in being able to accurately, academically, and and precisely describe a an architecture, and all of the memes just create a funnel for you to look at the very real, very well thought out, philosophy that underlies it.
Speaker 1:No. I mean, and even, you know, I came to it through grog brain, and it's like Yeah.
Speaker 2:I get to actually.
Speaker 1:If it was just the grog brain essay and nothing else, like, I still would have tried I would have tried whatever was on the website. Right. Like, I'm like, this this the the grug brain stuff is, a lot of experience distilled into something that is
Speaker 2:very fun. A lot
Speaker 1:of people miss that. So yeah. Yeah. I mean that's like a lifetime of software development. Like Yeah.
Speaker 1:Frustration. Via all the different companies I've worked for. Like, I'm like, okay. Yeah. This is this is in there.
Speaker 1:Yeah.
Speaker 2:That that really resonated with with me too. And I saw at the bottom of the Greg brain, he's like he says something about how he now has some modest open source success. And I was like, oh, it's the h tmx guy. I've been reading it. Let me check that out for real.
Speaker 2:So
Speaker 1:Yeah. Nice. So so one of the things that like keeps oh, okay. So, one of the things you mentioned in in the the, you know, the four things for the the 100 years is this idea of the routes file.
Speaker 2:Yeah.
Speaker 1:Mhmm. And and, you know, I think of this as, like, part of what you're sort of saying with, like, bringing rest back as, like, a Yeah. Central way of talking about your web application. Correct. You know, I love the routes file.
Speaker 1:And, you know, Laravel has that. Something that they have sort of argued different places have kind of argued. Yeah. Like, oh, we don't need like, this is so weird to have this just like one file where you, like, just declare all these, like, random route. Like, it just some people I feel like people are are moving away from that a little bit, but to me that's always, like, that's my rock for a Laravel application.
Speaker 2:It's your point. It's your way of it's your starting point.
Speaker 1:Exactly. Like I go there and and I can see everything that the app does. And with the exception of, you know, there's a lot a bunch of these kind of, third party plugins now that go into the vendor folder and so you don't necessarily see them in the route. So that's actually a problem sometimes. It's a problem.
Speaker 2:Where did that come from?
Speaker 1:Yeah. Like I have no idea and then they have other ways to look at the routes but my favorite is just to go to the routes file. So Yeah. Like I think that's that's good. But so and this is like, you know, maybe in under the the the classification of like just something where I feel like, maybe this is the academic or intellectual side, but I just I don't get and I feel a little like like I should, but this happened at the talk too, and and you're the triptych stuff.
Speaker 1:Yeah. Like, what does it matter? PUTs Yeah. And patch. Like, really?
Speaker 1:Because I I've been developing for 15 years, you know, making these sites and I just use post and I'll just make my case first. Please. Like post is like I just think of it as I'm changing something. I don't know if I'm changing something to add, I don't know if I'm updating something, editing something, like whatever it is. It's like to change something you need some sort of extra permissions and like when I do a get request maybe I knew it need an auth but post is like your server is gonna block things that try to access this route, you know, if you haven't sent a post request and so so you need to do you know I this is just my the way I think about it.
Speaker 1:Yeah.
Speaker 2:Yeah.
Speaker 1:Yeah. I need to send a post request to do something that's gonna change something on the back end. And I don't That's the first
Speaker 2:one you said. Yes.
Speaker 1:Yeah. So deletes, put, patch. I've never thought about it because I've never needed to think about it. I looked it up after seeing your talk. I'm like, okay.
Speaker 1:They're adding these, like, then I'm, you know, then I'm just like, yeah. But, you know, does it matter? And also, like, is it really if you had a PUT and a PATCH and you knew what they meant, is it always that simple? I guess, like, sometimes I feel like when you make when you're when you're editing, maybe you're updating, maybe you're creating, you know, and maybe you don't know until until you get to the application logic, and that's where you make your decision about what's being changed. So I don't know.
Speaker 1:What's the what's the case for for put and patch and deletes like needing their own thing besides a post?
Speaker 2:Sure. Let me ask real quick before I answer that. When you have access to put and delete in h t m x do you use them?
Speaker 1:You know I've used delete just because I I just like that clarity. Right. And you're deleting the thing
Speaker 2:at the URL which is nice.
Speaker 1:Yeah. Exactly. And Laravel has a nice you know, Laravel accepts in the routes. You can put like, route delete. Yeah.
Speaker 1:So, you know do. Like, it's it's all there, and so I get so, yes, I I have used deletes, and I don't always, but, yeah, I usually do now
Speaker 2:Right.
Speaker 1:Because I'm using the HTML.
Speaker 2:So you referenced Triptych. Triptych is what came out of the first talk, which is three proposals that I think take the core of what's useful and interesting about HTML and they Okay. Wait. Wait.
Speaker 1:Yeah. Sorry. What what's the name triptych? What's that? I get the tri part.
Speaker 1:There's 3.
Speaker 2:But, like, what's the triptych in in art is a set of 3 panels. It it typically, they're religious, imagery. And so the center panel has 2 panels on the side, and they sometimes fold together, and you see them in altar pieces and stuff like that. And so there are 3 images, and the 3 images all interrelate in some way usually to create a larger picture. So that's where that's where the name comes from.
Speaker 2:Yeah. So, yeah, it's 3 HTML proposals that interrelate to create a lot, that I that altogether, I think if these things existed in HTML, it would be a dramatic leap forward in the ability to create, websites that have no, a, have no JavaScript at all, and, b, are, like, way further along in this durable architecture that I talk about in the second talk. So if you can start creating applications that are whose functionality is entirely described in the HTML, entirely in the hypermedia, then you return to something that is very, very close to the static site, maintenance experience. And, that's all the those two concepts are are tied together. I think the more that you can, the the rest the academic term for this would be the self describing nature of a web service, like the extent to which that self description fits entirely in HTML.
Speaker 2:There's just like a a much there are a number of web services that I maintain right now that use HTMLX that if Triptych were implemented, I wouldn't need HTMLX at all. I would just be super happy with hard page loads and but so the the three proposals are, 1, put patch and delete support for HTML forms. 2, buttons should be able to make, requests without being wrapped in a form, which is entirely that actually doesn't even add new functionality, but it's it's very, very important syntactic sugar for making a document interactive. Mhmm. And you it's it's much, much more useful with the first one, with additional methods because you can do things like model a logout button.
Speaker 2:There's no if if if you've ever had that moment where you're like, how am
Speaker 1:I executing a logout button? I've ever done,
Speaker 2:I'm
Speaker 1:like, do I just do, like, a get for logout, which is what I usually do. It's weird.
Speaker 2:Yeah. And a get, by the way, is bad because a lot of browsers will prefetch. So, there's a bunch of Stack Overflow answer. And they'll only prefetch GET requests because in theory
Speaker 1:That's funny. I don't think of it.
Speaker 2:The developer using the GET request knows that it won't have any side effects on the server. So I'm previewing what I'm gonna say is important about methods in a moment, but not the fact that there are use cases in the web that are as common as a logout button, which, again, is on every single website
Speaker 1:you go to,
Speaker 2:that don't have an obvious way to model them within the existing semantics of HTML is evidence of a lack is evidence of something that's missing there. So, and then the third one is partial page replacement. And I don't even think partial page replacement is, like, tremendously important. I think it is it's valuable, but going back to the, it is valuable, and people will continue to reach for JavaScript if they don't have it. So that's a big part of why it's there.
Speaker 2:But, there are even if I just had the first two, there's a lot of things I'd start building without HTML at all. But partial page replacement, very good, and we will get there. So the first one, by the way, we have already worked with the standards body. There's some updates that need to be made to the proposal I'm working on right now. And and there is, there is interest from browser makers, which is very exciting.
Speaker 2:That is not, I think, the the median experience of people who wanna make changes to HTML. So that's really cool that they are working with us on that. We're very excited about it. But to answer your
Speaker 1:yeah. Go for it. I can I can well, I'm just how did you how did that I mean, then maybe that's a whole separate story?
Speaker 2:But Yeah. Let me let me answer your question, and then I'll I'll explain. We'll talk a little more about that. So why why is it important to describe the web application in, in roots and methods and kind of this basic semantics of of the web platform? And this is there's kind of like a practical reason for it.
Speaker 2:I think the practical reasons are are much easier to explain. If you like having stuff in your roots file, then it gives you a very useful grammar to be able to not go so far deep into what the the root what the URL of the root has to explain. So if I have I I use, like, a reservation, like, a hotel reservation site as an example a lot because it's a very generic paradigm that you could imagine applying to, like, basically anything. It's like, I'm saving I'm making something, and it's it's quote, unquote CRUD. It's create, you know, read, update, delete.
Speaker 2:So, if if I make a reservation and I post a new so you post a new form and you say, hey. I wanna save this. I wanna reserve this hotel room for 2 nights on these dates. The server does it, and it responds with a URL that is the URL of your reservation. So it might be at, like, slash reservations /, 123.
Speaker 2:And then I'm now viewing that reservation. So that every time I go to slash reservation slash 123, I can see the status of it and the upcoming and the details and all that. Now as a web developer, I have to decide how do I wanna let people interact with this reservation. How do I wanna let them update it somewhere? And the easiest, simplest thing to do is an update is a put.
Speaker 2:You just put at / reservations /123. And, already, I have moved a lot of logic that would have happened, in the application to the root because I no longer the part where I figure out what reservation I'm acting on now happens in the router because this what comes after slash reservations is some ID, and the router will extract that ID from the URL. So the URL describes a resource. It stands for uniform resource locator. And it describes a resource, and all of the methods describe different actions that the user can take on their resource.
Speaker 2:So a put is an update. A delete is a delete, and, a patch might be a partial update. Now you absolutely could use post instead of put to do an update. So the pattern would be you post to slash reservations, and then you get a slash reservation slash 123. And maybe you wanna post to that 123, as well.
Speaker 2:And That's what I yeah.
Speaker 1:That's what I
Speaker 2:usually do. Most people do that, and that that's okay. But first of all, you can't even do delete. And the delete one is really obvious. Like, that's a thing where I should be able to delete.
Speaker 2:So even just having delete is a really big deal. And once you have delete, the in in turn from the browser's perspective, all that's supported right now is post. So you have to make some pretty substantial changes to the navigation spec in order to genericize that. But if you've already if you're already genericizing it, well, just give us PUT. And, PUT is nice also because and and by the way, this is all in the Triptych proposal.
Speaker 2:So I I like I there's a section 8, I think, has all of the practical examples where I talk about how this makes the life of application developers easier. But, but if you have put, you can you can have a different you routers often, like in Express, let you do permissions as well. And I think that's like a really nice, really auditable way to do permissions. Like a random unlogged in user shouldn't be able to delete your reservation. And frankly, logged in users that aren't you shouldn't be able to delete your reservation.
Speaker 2:So, when you're doing permissions in the router, you also have access to like a really reusable, but still very granular mechanism. But, once I'm describing the whole life cycle as method x on resource y, as opposed to what you have to do now to work around, like, say, do something like / 123/delete, or there there are limitations to all those workarounds. But when I have access to that full life cycle set of methods on a resource, then I can preserve the usefulness, the utility of that router file across a larger variety of behavior because there aren't things that I have to then kick out to the imperative logic of the application for. So I can model in a way that's that's that preserves that scannability that, like, I'm here's my entry point to the application. Here really is all the things the application can do.
Speaker 2:This is every way somebody can interact with my application, and here are all the branching. I'm putting a ton of the branching logic into the description of the application itself. And that that kind of, like, transitions into the the headier philosophical concepts, which I don't I don't even think Carson and I have have totally nailed down yet. Like, I sent him a message once when we were writing this thing. I was like, what?
Speaker 2:Why why is, why are methods essential to the uniform resource description? And and I believe that they are, but I think and and this is cited in the proposal, but I think that a lot of the existing literature on this is very contradictory. I think Fielding contradicts himself a bunch on this question. But but I think they are. And I think that the next step once this stuff is in use is to take that and put it in, like, an academically precise way so that people can keep building on, their understanding, the kind of the human body of knowledge of understanding of what the web is.
Speaker 2:But for the time being, I can just point to, I'm an application developer. Here are very, very obvious, very, very common paradigms that this makes much, much simpler, and we need to build this functionality into the HTML. And it's already in the platform. It's already it's it's reserved for JavaScript, which is, again, a thing that I I think that causes a lot of the decay over time. It's it's functionality that is stuck in JavaScript.
Speaker 1:Yeah. I mean, so I I think something that, like, I think you guys both are, you know, just in general, h t m x, there's this link to academia, and academia, but also maybe not academia is not maybe not the right word, but
Speaker 2:No. It's definitely the right word.
Speaker 1:Is it? Okay. Yeah. I mean, so this link to, like and this is something that's, like so you you don't
Speaker 2:work in
Speaker 1:for, like, in a university type thing.
Speaker 2:Right? Is that correct? I I am affiliated with Dartmouth College, because my very first well, I went to Dartmouth, and the very first application that I built using these principles was like my my test run was to completely rebuild an application that somebody had built for them in React. I've referenced it actually in both talks, but completely rebuild it. And I'm still trying to figure out what the best way to tell the story completely is.
Speaker 2:But, with that had React, MongoDB, and 2 repos
Speaker 1:It was right effect of or Yeah. It was like something.
Speaker 2:Yeah. It was it's exactly the zeitgeist of 2018. And
Speaker 1:Right.
Speaker 2:It was just it would cost 100 of dollars a month to run. It had a ton of issues. And I was like, you know, I've been reading about SQLite, and I've been reading about HTMX. And I think if I put these 2 together, I can make a thing that that lasts a really long time, and that was a smashing success, in that, like, that is a functioning web application that is serving really active traffic that I don't have to maintain in any active way at all. Occasionally, there's, like, a new feature or something they want, and I make time for it.
Speaker 2:But I really don't have to think about this thing kinda ever, and it's it is doing, you know, a couple thousand requests a day, with active database transition. So but, no, I'm not, I'm not like a master's or PhD student or anything. I have a I have a BA.
Speaker 1:Okay. Yeah. So but, like, there's this sort of academic, you know, and maybe this is what I'm kind of wondering is, like, how is it is it that link, the academia link that gets it into, like, actually changing HTML? Like, what's that connection? Like, how do you even No.
Speaker 1:Get started asking about that stuff? Like
Speaker 2:Actually, yeah. That's a great question. That they seem like they would be the same thing. Right? They they seem like they would be related.
Speaker 2:Like, having some Carson is an m the creator of HNX is an MSU, Montana State University. Yeah. Montana State professor. And so, obviously, he is he is academic, and he's pursuing a PhD at the moment. But that's totally separate from how you get stuff into, the web as a platform.
Speaker 2:And these are, these cons I think that studying the early history of the web and that's, by the way, something I'm pretty deficient in, I think. There's a lot more that I could learn about how this stuff happened. But, there is there's a ton of tension between the, and there this is true of any field anywhere, but between the academic purity of of the self describing hypermedia system and, the the practice of it. A very obvious example of this is like and and this goes back to your point earlier about Tim Berners Lee, like, getting, you know, this basically perfect interface. Well and and I I apologize if my history is wrong, but I'm pretty confident that that Tim Berners Lee was on the committee that really wanted to move to an XML, based, HTML.
Speaker 2:So, like, XHTML, there was a big there's a big push for that, and, that push ultimately failed and led to the formation of the web hypertext application technologies working group, which is, like, related to the, World Wide Web Commission, but it isn't. But they're like that it created a whole a splinter body that was like, these your concerns about what would be like their these do not reflect the reality of using HTML. So HTML 5 ultimately sort of won the the battle between the x HTML people and the HTML 5 people. So there there's a there's always tension there, and there's a ton of tension in the fact that HTML, you know, has patterns that can lead to security. Like, there are there are problems with the default ideas of HTML that we now have to patch in an additive way because we really I don't know if Marquee still works, but for the most part, we, like, mostly don't take things out of HTML because we don't wanna break the web.
Speaker 2:So I think that the and I'll talk about the the practical, you know, how you get stuff into the web platform in a second and with the caveat that I have not done so successfully yet. But, the the purpose of the academic stuff, I think, and it's I I think that I don't wanna say it's undervalued by software practitioners, but I would say that people tend to dismiss the the you know, terms like rest or or or or the attempt to describe these things at a academically rigorous level because they're like, well, I need to make something work. And today, I'm gonna go to work, and I'm gonna get paid, and I'm gonna make something useful. And that's fine. That's a totally fine attitude to have.
Speaker 2:The value of describing triptych, describing HTML, describing my proposals at a, at a really egg heady level is that it lets you see things that you wouldn't otherwise see. Let if if you did not first define the language, that lets you talk about them usefully. So part of why it's so important that car star Carson started ranting about how rest requires hypermedia, after we was that Carson read a lot of Roy Fielding stuff where Roy Fielding says, a REST API isn't just about using, like, you know, post and get correctly. It has to be hypermedia based. It has to be self describing.
Speaker 2:So the API needs to return some HTML, and that needs to display to the user's browser. That that is crucial to REST. If you don't if you're not willing to engage in the discussion about what REST is, then you can't you you can't even fathom that possibility because you're not you don't have the language to do so. So it's it's important because it sharpens your ability to then take take the, the case for why your idea should be adopted into HTML and describe them really efficiently because you have already, worked on doing so in a less practical realm. So then you have the ability to take that, be like, this is exactly what's useful about this.
Speaker 2:This is why I have the the language and the the the the citations to answer all of your your practical concerns.
Speaker 1:Yeah. I mean, it's just it's fascinating because it feels like there's such a, like, strong foundation or base, for like like, so I read the Hypermedia Systems book. Yeah. And it's just like it you know, when I sort of work on other, pieces of technology and kind of, you know, learn about them, it's very, you know things are practical based. You know, it's based in, like, here's what you can do with it.
Speaker 1:There isn't much of there isn't much of a need to go into the deep part of it. So I I think I just it felt very novel and it feels very different to have this kind of wealth of actual academic essays. There's papers about hypermedia stuff. Like, this is a realm that I've never gotten into. Probably would have no reason to ever get into in any realistic way, but I I really appreciate the thought that has gone into it.
Speaker 1:And and, you know, the fact that, you know, members of the h2mx team and and just people involved in the project are thinking about those sort of things, thinking about this, like, bigger picture of the web, and I think that gives such an advantage to all of this stuff. It's like it's so cohesive in a way.
Speaker 2:Absolutely. And and even if you don't care about the academic stuff, you pick up on the cohesion, and that that counts for something. And I it it makes the ideas better, and it gives it it gives you the feeling like, hey. These people care. They're trying, and they they wanna make a difference, and that's true.
Speaker 2:Everybody involved, is does so. There's really no money, associated with it. It does so because they really believe it's the right way to move, forward. Right. Yeah.
Speaker 2:I didn't answer your your other question about the process of getting something into the, HTML spec, and it's not it's not really that mysterious. There are there are public meetings that happen all the time, and there's a there's a public spec for all the the web browser standards. So there's there's just like a process, and you can go on their website and read about, you know, how to make a how to make a WATWIG issue or how to make a PR request. And, the fact that Carson has been in touch with browser engineers because of the success of HTMX, and and they've inquired. They're like, what what about HTMX should be included in the browser?
Speaker 2:So, one of the things that I, was able to do this this past summer was take those basically, like, follow-up on that thread. Okay. Well, let's let's try and think about, given the constraints of the web platform, what could be included. And that, the the academic stuff we're talking about earlier, that matters in so far as it gives gives me a sense of, like, why. But that really all that stuff is kinda downstream of me just, like, looking at the existing web APIs in HTML and going, okay.
Speaker 2:How can we fit this in here? It's really easy for methods because there's a method element on the form. So the method element should just support more methods. That's not
Speaker 1:a problem. Not changing anything. You know? It's just it's added purely additive.
Speaker 2:Purely additive. So that one's, you know, from an API standpoint, very easy. Partial page replacement's gonna be a lot more difficult.
Speaker 1:Right.
Speaker 2:But that's okay. We're going going 1 by 1. And yeah. So we got a bit of a of a boost there. And so I would say that if, if you have something you wanna get into the HTML standard, attach it to a very popular, web library, and maybe you'll get a little more attention.
Speaker 2:But at the end of the day, like, we did the same thing that everybody else has to do, which is write it down in excruciating detail, and then that's what that's what triptych is and is becoming. And then show up in a meeting and be like, here's my detailed idea and be prepared to answer questions about it.
Speaker 1:That's awesome. I mean, that's Yeah. Just the just the possibility of of having that sort of, chain you know, making an actual change to something so fundamental is just kind of exciting to to win. I'm excited for you.
Speaker 2:If I accomplish nothing
Speaker 1:else very cool.
Speaker 2:In my life, and I am was it was was a part of putting something in the HTML standard. I mean, That's gonna kill at parties. Hey, you ever you ever used a put form? That's me, baby. I get that.
Speaker 1:Yeah. Well, alright. Well, I think we're we're at about an hour 15, so I wanna I'm gonna, I wanna be a I really appreciate your time coming on and and talk is there anything you you wanna, like, plug or anything like that or or just kinda mention, that we didn't cover?
Speaker 2:Super super fun conversation. I would say that if if anything we talked about here was interesting to you or you were frustrated that we didn't explain some background, I apologize for that. And check out. So my website, alexanderpetros.com. The Triptych proposals that we mentioned are at alexanderpetros.com/triptych.
Speaker 2:There are two talks that I've given recently that we've referenced a fair amount. One of them is called the life and death of HTMX from Big Sky Devcon. The other one is called building the 100 year web service that was at Utah JS. And, all three of those things together, are part of the larger project that I'm trying to pursue to make HTML, better for developers and ultimately make, you know, the web better for everyone. So if, if you're interested, find me, be in touch.
Speaker 2:That's what I'm working on.
Speaker 1:Nice. And I will try to include every one of those links you just mentioned, in in the show notes right at the top.
Speaker 2:Oh, and, I have a blog also called unplanned obsolescence.com, which is in which I talk about a lot of these topics and also kind of like includes practical tips for how to build web applications for htrpix.
Speaker 1:Nice. Excellent. That's good, 10,000
Speaker 2:Yeah. I'm sorry.
Speaker 1:Oh, there's a good 10,000 Maniacs song called Plan dot obsolescence. You should check that out.
Speaker 2:I will definitely check that out. Yeah. And I I love the conversation. I had a great time coming on, and I think this podcast is super cool. So I hope you stick with it.
Speaker 1:Awesome. No. I'm I'm, having a great time. This is really good. So thank you very much.
Speaker 1:I really appreciate you you talking. My pleasure. Have So Have a good one. Alright. You too.