Server-driven web apps w/ R. Mark Volkmann
Yeah. I don't I don't do a ton of editing, but, you know, the main thing is, you know, I
Lazarus:I wanted to talk, a little bit about I'll hold this up. Excellent. This book that you wrote called Server Driven Web Apps with HTMX. So I'm joined today by Mark Volkmann. And my first question is, what's the deal with the r r Mark Volkmann.
Lazarus:So how do you so, you know, what do you go by? Do you go by Mark or is it go by r?
Mark:I do go by Mark. My first name is Richard, but that's a common thing in my family for people to go by their middle name instead of their first name.
Lazarus:Oh, okay. Interesting.
Mark:And then I don't wanna be confused with people whose first name is Mark. And so I started throwing the r in there.
Lazarus:Nice. I like it. It's got there's something, auth authorial about it. You know, and maybe I'm just thinking of the, the famous, you know, fantasy authors, j r r Tolkien, George r there's a lot of, you know, sort of, I'm trying to think of who who else I know who starts off with a with a letter, but I I can't think of it right now. Yeah.
Lazarus:But anyway, so so you wrote server driven web apps with HTMX, and, you know, I've sort of gone through it. And I guess, like, my my first question is sort of like, what kind of got you into like, what made you first sort of look into HTMX?
Mark:I think that I've been on a quest for simplicity for a big part of my career, and I've worked with a lot of different web frameworks. Started with just vanilla DOM and then did Jquery and Angular 1 and then React and then Angular 2 and then Vue and, more React and then Svelte and now HTMLX and there's been some other ones as well, a foray into Astro, which I really like. But in all those cases, I think I was just looking for something that was simpler. And I feel like in our industry, we almost worship complexity and run to it. And sometimes I think we're just not aware of the complexity that we're accepting.
Mark:There's a bit of a boiled frog syndrome going on. So, for example, I'll pick on React. People who started with React when it was brand new kind of did it as a reaction to Angular, and they saw React as a simpler alternative and I believe that it was then. But people that stuck with React from the beginning maybe didn't quite notice how much complexity was added over time and it just gets more and more and more. And, it doesn't bother them because to them, it was just adding a little bit over time.
Mark:Mhmm. But people coming to React new today, I think it's kind of shocking compared to what some of the alternatives are. And so I think that Svelte is quite a bit easier than React, and then I think HTMX is quite a bit easier than Svelte.
Lazarus:Sorry.
Mark:Yeah.
Lazarus:I mean, it seems like there's been a, you know, Svelte sort of popped up recently. It seems like there's an appetite for that simplicity, you know, whether that's h t m x or, you know, some of some of the other frameworks also sort of talk a little bit about simplicity. I think, like, I don't know them all off the top of my head, but, what is the one that's, like, with next, Nuxt or something? I don't know. There's sort of, like, there's some options in there and, you know, simplicity is mentioned, but I think it's kind of a simplicity relative to what you're starting with with kind of react right now.
Mark:Sure. Sure. And I don't think that HTMLX gives you everything you want, and that's why I think pairing it with something like Alpine is great because you don't want everything the user does to have to trigger an HTTP request. If you need data, fine, and that's what HTMLX is there for. But there's certainly cases where you can have interactions with the user that don't require a trip to the server, and then Alpine works great for that.
Lazarus:Yeah. And that was, you know, like, a big part of the book that I really appreciated was that, you know, you've got a whole bunch of stuff in there with Alpine. I like Alpine just in, you know, that's obviously sort of in a in a similar mindset. The creator, Caleb Porzio, is, you know, creative creative Livewire also, so sort of hypermedia focused and also keeps attributes right there, in line in the same way that HTMX does. So I think, you know, the book, you you sort of do do Hyperscript, but also a lot of Alpine JS examples and sort of show how you can pick either one or including, you know, vanilla JavaScript, which you use quite a bit, which I thought was cool.
Lazarus:I think that was a neat mix of
Mark:stuff. Yeah. And I think I might use Hyperscript even more if I gave it more time. It's just I think there's maybe a little bit more learning curve there, but I certainly don't dislike Hyperscript.
Lazarus:Yeah. Hyperscript, I mean, I've I've mentioned this before on on net on this on this show here, but I gave it I really I've I've tried to use it for a project, and it just wasn't quite matching. Like, I could never guess the right syntax. I had to keep looking it up and looking it up, and so it's one of those things that I really I appreciate when I see someone else's code. It's so easy to read, and I really appreciate that about it.
Lazarus:And I'm like, oh, this is obviously what's supposed to happen, but when I'm trying to write it, there's, like, a mental block where I'm just, like, I I don't remember or I don't know or I can't quite figure out what that syntax is supposed to be. Right.
Mark:I I feel like if you wanna be successful with it, you need to take the time to develop maybe a one page cheat sheet of common things you're gonna wanna do and then keep referring back to that.
Lazarus:Yeah. That would probably make sense. In fact, does that even exist already that I'm trying to remember if that that might be something they have on the Hyperscript page. I feel like I may have seen that before, but I'm not sure.
Mark:Right.
Lazarus:But yeah, I wasn't I I did I tried to use it for a project and, you know, I had to get the project done. I was like, alright. I actually just need to switch to vanilla JavaScript because I know what I wanna do. I just can't quite get the wording right. And I know that hyper script can do it, you know.
Lazarus:That was like a big part of it.
Mark:Yeah. Yeah. Yeah.
Lazarus:So so one of the things in the book that I noticed is you sort of have a bunch of very practical examples. You know. I I think of it as, like, these are things that you're gonna use in, you know, 90% of your websites, you know, infinite scrolling if you want, lazy loading, just sort of stuff that's, like, you know, the kind of things that you probably would use for for most things. So so what sort of websites are are you building in general, I would say?
Mark:Yeah. So I I do work on some pretty complicated web apps. The unfortunate part of that is that I'm building these web apps for clients that often have selected what frameworks they want to use. And to this point, none of them have selected HTMLX. And so I'm actually doing a lot of work in React these days.
Mark:Before this, I worked for on a lot of client projects using Svelte. And if I wished that I could use HTMLX, but it hasn't reached the point yet that we've been able to convince clients to do that. In this particular case, in my current project, the web app already existed, and we were brought on to help them add features. And so there isn't really an opportunity to transition to it. But when I do things on my own, I'm always reaching for HTMX.
Lazarus:Yeah. So I think that's actually kinda cool because I think there's sort of like 2 camps of people who are using HTMX or,
Mark:you know,
Lazarus:there's probably more. But but, you know, there's this sort of people who, have come from a sort of traditional, like, web background where they use PHP or they use some other scripting language, and they mostly just built, like, HTML pages and sort of MPA, like, multi page applications. And now that, you know, now it's like it just the mental model sort of fits really nicely, with HTMLX. And then there's people who are coming who are maybe newer to development. And for them, HTMLX is, kind of a different paradigm.
Lazarus:They're not used to those sort of, what I think of as kind of the the web core, the HTTP stuff, you know, the the get put, like, all these things are kind of, like, old school how the web used to work in a lot of ways kind of stuff, but but, you know, some people if you haven't started with that, if you started with React so so there's I feel like there's not a ton of overlap actually between, like, the people who are who've used a bunch of React and who've used a bunch of HTMX and who so it's kind of I think it's kind of interesting that you're sort of have a that nice comparison of both to really give it, like, you know, it's not just, oh, HTMX is better because I don't know React, you know. It's like, oh, h t max is, you know, it it fixes a lot of things.
Mark:Right. I think an interesting thing to consider is does your web framework frown upon you reaching out and touching the DOM? There's very useful things you can do with the DOM and some frameworks. I'll give Svelte as an example. There's no problem if you want to do things directly with the DOM.
Mark:But that's a very bad thing to do in React because it's trying to update the DOM for you. And if you're also updating it, there's kind of a contention there. So that's another thing that I dislike about React. And a thing that I like about h t m x is that it embraces the DOM. It doesn't try to stop you from reaching out to it.
Mark:In fact, there's a chapter in my book about the functions that HTMX provides that are exactly for that purpose, to try to make it easier for you to work directly with the DOM.
Lazarus:Alright. So so which, like, stuff like what? Which which functions are you talking about?
Mark:Yeah. Let me pull that up. And so I'm referring to, chapter 6, utilizing the HTMLX JavaScript API. Yes. So, yeah.
Mark:On page 107, there's a bunch of DOM methods they provide. And I tried to give side by side examples and show like, well, here's how you could do it with HTMLX, and here's how it would look with the raw DOM equivalent. And for the most part, it's just making the code a little bit shorter, but it's doing the same thing. And so, for example, in pure DOM, you could do a document. QuerySelector and give it a selector and you find the things that match.
Mark:With h t m x, you can just say h t m x dot find and give it the same selector. And so, like, what's the big deal? Well, it's just shorter to type.
Lazarus:Well, I so I found this fascinating because, you know, I've been I've been working with h t m x, you know, for about a year now, and really, you know, trying to dig into it, trying to, like you know, I've been doing the show about it and kinda, like, going through the different things, and I had never seen some of the stuff in the in the HTMX JavaScript API. And, like, I thought of that as, you know, that's like the realm of Alpine or Hyperscript or vanilla JavaScript. Like like, for instance, you can in the HTML JavaScript API, they have dot add class, And so you can do a selector and you can add a class and you can remove a class, you can toggle class. Like, this is stuff that I did not realize was part of h tmx at all. Like, so I mean that's the first time I saw it was in your book.
Lazarus:I was and I was just I was like, oh, this is, like, very surprising to me.
Mark:Yeah. And I'm speculating a bit on this, but I I feel like perhaps Carson Gross would say, he doesn't really care if you use any of that, but he needed it for implementing HTMLX himself. And I imagine that the HTML implementation is using all of those functions for its DOM manipulation.
Lazarus:So it might be, and I don't know because I I honestly, I didn't look it up after I saw it in the book. I was just like, oh, I didn't know you could do that. But it might not even be documented. I mean, is that did is it you think it's is it in the documentation page?
Mark:Yeah. I'll say it's documented, but I don't think it's documented well. And so that's the thing I like about my book being out now is that probably at the at the current date, this is the best documentation you'll find on those features.
Lazarus:Yeah. I mean, it gives examples. It goes into, you know, specific code for it. And I mean, that's it's it is cool. Like, I don't know how much I haven't gone through the whole API that's available, but, I mean, some of the stuff, like, you know, by default, I'm adding some vanilla JavaScript.
Lazarus:That's sort of my first default. I'd like to get do a little hyper script. Alpine, if it's a certain kind of project where I know there's gonna be kind of a lot of front end stuff ahead of time, I'll probably say, okay, you know, this Alpine will make this a little easier. But now I'm, like, thinking, like, for the really the basic stuff, like hiding, showing, like, I don't know, like, find class, add class, remove class, toggle class. They have one called take class, which is cool.
Lazarus:Like, it's, like, you it's, like, does the sets it so that one of the siblings has a class and then removes it from all the other ones. So such that, you know, which is what you wanna do almost all the time. So instead of having all that code where you're, like, add this class and then go through the list and remove it just sort of does that for you. So little things like that, like conveniences, like, I wonder how far you could get now even without an alpine or a or a hyperscript.
Mark:Yeah. I guess in my view, I reach for alpine when I want some client side state. And so alpine can store that for me, and then it can be reactive when that client side state changes. So that's really what I'm reaching to alpine for.
Lazarus:Okay. So client side state. So it's not yeah. So with HTMLX, you're manipulating the DOM such that you could respond to that state if you wanted to, but it's not like it's has a array somewhere of client side variables that you're tapping into. So that's where you'd reach okay.
Lazarus:That makes sense. That makes sense. Right. You don't wanna
Mark:And I guess further, I would say that I'm not trying to move a lot of state to the client. I I like the state to stay on the server. But if it's a piece of data that the server never needs to know about, well, then I'll use Alpine and just keep that on the client.
Lazarus:Yeah. Yeah. And you talked a little bit about, client side via validation in the book, and sort of using it, doing the server stuff with it too, because sometimes client validation does include server stuff, you
Mark:know. Exactly.
Lazarus:I think the example you gave was, checking to see if an email is already in the database, and it's like Exactly. Yeah. I mean, that's like you need to go to the server for that. No amount of client side stuff unless you're willing to expose every one of your database emails to every browser. I don't think you wanna do that.
Mark:So Yes. Oh, yeah. So one thing I feel about HTMX is that one of its most touted features is also kind of a negative, and that's the whole howl concept, hypermedia, on whatever you like. It's great that you get to use whatever you want for the back end, but a somewhat of a downside of that is that that means that all of us out in the HTML community are making different choices. And now we can't share code examples because we've done it in a different way.
Mark:Or you have to be able to translate, like, you did something in PHP, and so I have to be able to read a little bit of PHP to understand your example, and someone else did it in Python. Here, I'm doing it in JavaScript using the bun, JavaScript engine. So, yeah, it's cool. You can do it however you want, but it makes it not as easy to share with other people using HTML.
Lazarus:Yeah. So so that's interesting. I mean, that must have been a challenge, you know, writing the book because you have to make that decision, and you know that, like and for me, for instance, I've never touched BUN, I've never touched, you know, I was when I when I was, reading your book, those parts, the server side code, I kind of just skim you know, I glossed over because it's true. It's a different stack. I'm not familiar with it.
Lazarus:I feel pretty confident that I could figure out what the code's doing if I needed to, But it's not something where I look at it and I just know what it is necessarily because the syntax is a little different and all that kind of stuff. So I did try to emphasize
Mark:I did try to emphasize in the book that you ought to choose what works well for you, And don't just go with JavaScript because I picked it for the book. But, two reasons why I picked it. 1, is that that's what I was most familiar with. But 2, I feel like, HTMLX is something that appeals to web developers, and most web developers already know JavaScript. And I can't guess what other language they might know.
Mark:Yeah. So that's why I went that way. But certainly, there are people that might not buy my book when they see that all the examples are JavaScript because they don't do JavaScript, and that's a shame. Well,
Lazarus:yeah. But let me let me push back on that for a minute because, you know, the continuation of that is that, yes, I skimmed over a little bit of those examples, but that was the server side code. There was no HTMLX most of the time in there. You know? For for most of the examples, the h t the HTML page with all the HTML attributes and everything like that, that's all the same.
Lazarus:And to me, that was that was what I was getting from it. You know? I was like, I know how I'm gonna handle the back end. What I want to see is how are you dealing with the front end and with the HTML? How where are you putting the attributes?
Lazarus:And that was all the same. You you know, there was nothing in there that didn't make sense to me. So I I think for anybody who's looking at the book, like, just my personal opinion, like, you don't need to know bun or what was the you something else. I'm forgetting the name
Mark:of the Ono.
Lazarus:Ono. Yes. So you don't like, all that stuff, even if you just don't even look at those sections, which obviously you can and you'll understand them because they're a bunch of little small snippets, like, they're separated. That's the back end snippet, and then, you know, a couple paragraphs later, here's the front end snippet. That's gonna be all the code that you you know, the h t m x code that you're gonna use.
Mark:Alright. And one of the things that I I liked about choosing bun for this is that it supports JSX, which originated with React and looks a lot like HTML even though it's not exactly HTML. But that made it so that if I was writing an endpoint that needed to return some HTML that used HTML attributes, at least at a glance, it looks just like normal HTML. So even though that's in the server side code, it should be pretty recognizable.
Lazarus:Gotcha. Yeah. That makes sense. Nice.
Mark:Yeah.
Lazarus:I mean, I I will say I love the howl aspect of it and but I am struggling, you know so one of the things I'm working on next, that I I mentioned in the last thing is kind of building this this page of examples. You know, I I wanna build sort of a page of HTMLX copy and paste examples. And it is that thing where it's like, okay, even though most I'm gonna I'm gonna try to stick to the front end to the htmx stuff, but you still have to show what's happening on the server side, you know. You gotta have to give some indication. So I'm gonna have to make that choice, you know, and I'm probably gonna do PHP Laravel because that's sort of what I know.
Lazarus:But, and and the blade syntax is pretty straightforward. Like, you know, it's probably as short as you could possibly make it, You know, not too many funny symbols or anything like that. But but it's still something where it's like, you know, you you I'm gonna try to limit that as much as possible to keep it sort of as vague as possible. But it's sort of I think, you know, the beauty of it and as you mentioned, like, it does make it probably harder to sort of, share a project with somebody, you know?
Mark:Right. Yeah.
Lazarus:If it's all one if it's a a Laravel project and you're just working in Laravel, you just share someone else who's working with Laravel and they they see everything. They can download everything. They can get it, you know, so I do think, if you're trying to do that with HTML, you know, I don't I'm not going to understand a Django, or be able to, like, download a GitHub Django link. As much as I think it's cool, I just can't. I don't know how to process it.
Mark:So I did listen to your last episode where you were talking about building out this catalog of examples.
Lazarus:And so if there's
Mark:anything in my book that you'd like to copy in there, that's fine with me. All that's open.
Lazarus:Yeah. Okay. Great. I mean, that's interesting because there are some some stuff, like I said, I'd never seen before, which I thought was cool. And, you know, yeah, just kind of looking around, You know, I'm gonna start sort of basic with just the get and the post and, you know, just kind of go through, but but I do wanna go deeper.
Lazarus:And and that so that was, like, one of the big surprises that I I, like, made a mental note of was that what you called the JavaScript API of HTMX, which I did not even know existed and could be extremely useful, you know, for some things.
Mark:Right. One of the things I wanted to point out, that I talk about when I give talks on HTMX is what you should do when you're getting started and you've selected your tech stack. I feel like it's really important to start by creating a couple of tables to describe how you interact with requests and responses in the framework that you selected. And so, in the slides for this talk I give, I show these tables for the Hano framework. And so, yeah, I I think, you could recreate those for Laravel and, all it is is to show concisely when you're working with a request, how do you get a request header?
Mark:How do you get a path parameter? A query parameter? Or if the data is in the body, how do you get it if it's plain text? Or what if it's JSON? And then on the response side, how do you set a response header?
Mark:How do you set the status code? And, how could you put data in the response body? What if you want it to be plain text or HTML? And what if you want to, send back a 404 error? Or what if you want to redirect to another URL?
Mark:So I feel like if you answer all of those questions in the beginning and you have them written down, now when you're ready to implement all your endpoints, you won't be struggling and thinking, well, I haven't done that for a few weeks. I forgot how to do that. You've already documented how those things work in your framework of choice.
Lazarus:Interesting. So let me, like, ask you about that because I I almost I found that I researched them quite a bit and I sort of worked out how to use some of the response header stuff and how to, like but I in my actual projects that I build, I don't think I've ever had to use, like, change the response header. Like, there's all these there's all these response and request headers that are sent either automatically with HTMLX or you can tap into them and send them yourself, you know? And, like, it's sort of this, like, infrastructure that powers the whole thing, and it's very powerful to be able to tap into it, but I just have never needed to. So, like, I guess I'm wondering, like, when when do you need to?
Lazarus:Like, what's the sort of, like, when does it get to that point or does it sort of start that way for you?
Mark:For me, there are two common cases. So perhaps the most common is hx trigger where I need to return a response header that's gonna trigger an event back in the browser because I'm thinking about 3 ways that I can get data back from an endpoint. Either I send back a chunk of HTML that's the main thing, or I can do some out of band things so I can return more than one chunk of HTML. Or I'm trying to emit an event back on the client side, and that's where I'm reaching for that response header. Then the other case is that there's a chapter in the book on security concerns, cross site scripting things and, CSRF, which I honestly knew very little about before I wrote the book.
Mark:But I decided I needed to have a chapter covering this and, learned about it and documented it in the book. And so that's another case where you're gonna have to set some headers to get that to work correctly.
Lazarus:Yeah. Actually, I should say that is, I I there's I have a couple ways that I do that, but the one that looks the best or that looks the most the easiest is is setting that, setting an event that's basically anytime you send a request, add the the, CSRF token to that request. And then you just sort of set that once in theory, and then every request after that has it. And so then you sort of don't have to think about CSRF anymore. But, yeah, every time you do a post, you have to have that CRF CSRF token.
Lazarus:And that kinda tripped me up a little bit, having to do that on the first few of trying to figure out the correct way to pass that. You know? Like, if it's already in the form, you don't need to worry about it if you're passing a form. But with HTMLX, you're not always just submitting forms. You know?
Lazarus:You can do a post on anything. And so so you have to remember to also do the CSRF token. But yeah. Like, I think the big the differentiator, it sounds like and and the reason this has come up a few times, I think, with people is is that I just don't do a ton of event based, architecture. Like, most of the stuff I do is, like, you know, send a request, get stuff back, and I'm mainly replying on that.
Lazarus:I think if you lean more heavily into events, which are very powerful and, like, nothing nothing it's a very powerful thing to do. That must be it sounds like that's when you start to come across maybe these sort of more advanced needs with h tmx.
Mark:Right. Right. And I have an example in the book of a to do app, which I think is a a really good kind of app to start with with any web framework and make sure that you understand all the interactions there. But in a to do app, if you're gonna display at the very top, the number of to do's that you still need to accomplish and the total number of to do's. So you can say, 3 of 6 remaining, for example.
Mark:And then you think about, well, what would you do in that app that causes you to have to update that line? Well, if you add a new to do, that has to update. If you delete a to do, that has to update. Or if you toggle 1 from not done to done, that has to update. And so, in my implementation, of course, there's more than one way to do this, but one way is to say with all of those endpoints that add and delete and toggle the done state, they all send back an event to the browser.
Mark:And when the browser sees that, it says, oh, I guess I need to update this status line. And then it sends a request to get the updated numbers. So I I thought that was a good use case for an event.
Lazarus:Interesting. So, yeah, I I can see that. So so, like, another way to do it would be to have your every time you update, you use an out of band swap
Mark:to Exactly.
Lazarus:Then send it to every place. But the problem with that is, like, at some point, you may as well just return the whole page, you know, if you're if you're sort of updating everything. So what you're talking about is kind of a sequential, you know, you get the data back and that then triggers so then your pedama's updated, and then that then triggers the new thing, which is, okay, there's been a change to our accounts or whatever you wanna call it, that goes to it. And then you maybe do an out of band swap at that point, but it's very specific. The only purpose is to update the counts.
Lazarus:Does that sound kinda what you're
Mark:saying? Although I'm not doing an out of band swap. I'm sending a new get request that is returning the new status line, and it's not out of band. It's the main thing. So potentially the downside is that every one of those actions you do actually triggers 2 requests.
Mark:I've got a request to add a new to do, and then the event comes back, and then I make another request to get the updated status.
Lazarus:Yeah. And there might be a little delay. You know, you'd see first your thing would update, and then you'd get the second update would happen afterwards. But, I mean, I think that's a perfectly fine way to do it, and, you know, the main thing is to get the main request back. So I think, like, I think I have a negative I have, like, I don't know if it's, like, from from having problems with it in the past, but I just like things that are asynchronous like that, I think that's why I sort of move away from event driven stuff.
Lazarus:I just have this this I've had too many times where it things just didn't work. And so so, you know, because of something, well, you know, this asynchronous thing was supposed to happen, but something else happened in the meantime. And so now that one didn't kick off. And so now I'm missing some important piece of data, and I don't know why. Stuff like that.
Lazarus:So so I just this is just my own, you know, 20 years of development trauma. That's one of the things that has bitten me is the asynchronous stuff. So a lot of the pages that I work on, I try to sort of encapsulate all the data that I need into a single request and just bring it back, and it's like and that's what I love about h tmx actually also is that because it's affecting the real DOM, I don't have this fear in the back of my mind that, like, what I'm seeing is not the truth. You know?
Mark:Right. Right.
Lazarus:Like, I don't want things to be true.
Mark:I don't wanna give the impression that I prefer events over out of band. I I prefer out of band swaps over events.
Lazarus:Oh, really?
Mark:I think there are cases where it's useful to use them in addition.
Lazarus:Yeah. I mean and I'm not like I don't wanna push out a band either because I I I think you can go a little nuts with that. And like I said, at some point, you may as well just return the whole page. It's not like it's really that slow to update the DOM, you know, when you return the whole page. But, you know, sometimes you'll have a page where you're doing calculations all over different parts of the page.
Lazarus:You don't want to have to do that every time. And and, you know, I I work with a lot of stuff that is businesses with a lot of people collaborating on large datasets. And so, if I you know, I don't it doesn't something you know, to do a full page reset can be over a second or something because you're pulling data from all over the site. You're pulling data from everybody's private stuff. You're checking permissions for everything.
Lazarus:So I do think it's, you know, it's nice to be able to not do that full page thing, but I do think you can go a little nuts with the out of band stuff and and end up with something that's very messy to keep track of because you've got some file somewhere just like shooting stuff out, you know, into the ether.
Mark:Right. Right. So I don't know if you're aware, but before this book, I wrote a book on Svelte.
Lazarus:Oh, really?
Mark:It's called Svelte and Sapper in action. Sapper was the framework on top of Svelte before they came out with SvelteKit. And so, sadly, now my book is very out of date. But a point I wanted to make is that that book is quite a bit longer. I I forgot.
Mark:It's maybe 400 pages. And so some people might wonder, why is my HTML book only a 160 pages? And, the real answer is that that's what the publisher wanted.
Lazarus:Unless, one of
Mark:my own devices, I probably would have written a 300 page book and included a lot more detail. But, I'm happy with the way it turned out. It certainly was a challenge for me to decide, what stays and what goes because you can't describe everything in a 160 pages. And it was also a challenge to see, how concisely, but still thoroughly, could I cover all the topics.
Lazarus:Yeah. I mean, I would say in terms of the size, like, I you know, obviously, if it had been a bigger book and and it was, you know, however you want to do it, you want to do it. But I do think this size is really nice, just in terms of being able to kind of, like, look through it, and it seems to be sort of the essentials if I had to kind of, like, put it into you know, it's like this is if I'm just gonna sit down and I'm, like, I'm gonna commit to building an app with this, like, this is, like, 95% of the stuff that I'm gonna need plus some extra stuff, you know. Like, I don't think you skimped. That's my impression.
Lazarus:Like, I feel like you hit some a lot of extra things that, you know, just I have some notes here, like CSS transitions. Like, you added some stuff to keep it fancy, you know. You're not just making the most basic app like you did. You also hit on actually, I want I meant to ask you about this, but you hit on optimistic UIs. Just a small portion in the book.
Lazarus:But I thought that was interesting because that's something that has been sort of talked about as a limitation, in the HTMLX verse, you know, the the, server server side versus client side. So, yeah, what was the sort of thought process for for the optimistic UIs?
Mark:Yeah. Well, I think there's a lot of cases where, the users, if if they click something, and my example in the book is there's a like button that is actually a heart icon. And if they click that and it doesn't change from white to red within a second, they're thinking they did something wrong and they click it again, which maybe causes it to toggle back to white when they wanted it to be red. So the solution I came up with, which I really like, is why don't you immediately make the heart pink? And then the user knows they did something.
Mark:And then a split second later, it changes from pink to red, so they know it's been confirmed on the server. And Yeah. Going in the opposite direction, if it's red and you click it, it changes to pink, and then a fraction of a second later, it changes to white. So I thought that was a good way to let the user know something happened, but also let them know, well, maybe it's not actually confirmed yet.
Lazarus:Yeah. So what's the logistics of how you chose to do that? What's the, like, what's the did you do Vanilla JS? Did you do Alpine, HTMLX API?
Mark:Yeah. I don't actually remember for that specific example, but I'd be surprised if I didn't use alpine for that. I probably did use alpine, but, yeah, I'd have to dig through the code and look into it.
Lazarus:Yeah. But I mean the basic concept, like, let's say let's say it's vanilla JS. I think my recollection was it was that it was vanilla JS, but I don't really remember. But I think the concept was that, you know, in this so it was an event. It was you had an event listener that you added.
Lazarus:Right? And and, was it? Let me think. I think it was an event listener. And how did you put it in the right place?
Lazarus:That's what I'm kind of I may even look this up because this is something that I've sort of thought about because, you know, as as a general rule, like, optimistic UI with htmx, I kind of like I'm a little bit skeptical because, like, you know, can you know what the server is going to give back? You know? So, like, how optimistic can it be really? And maybe it can be very optimistic. Like, in this case it works nicely because you you know what you're gonna get.
Lazarus:You're either gonna get a white or a red heart, you know? Right. So so you can put a a pink one in that in that situation, and that's actually, like, a really good, I think, solution for that. I think when you're getting back when you don't know what the server is gonna give back, I think that does get a little bit tricky. And so, like, that's why I'm curious of what the actual, like, mechanics of it are and and how you like, how that could be used for other forms of, you know, optimistic UI here.
Lazarus:Let me just pull this up.
Mark:Yeah. I'm looking through the code as well trying to refresh my memory on how I did that.
Lazarus:Here we go. Optimistic updates page 49. So let's see what you did here. Yeah. We've got, yeah, vanilla JavaScript function, optimistic like event, It replaces it.
Mark:Yeah. Yeah. It looks like I'm just changing the, changing it to a pink heart as soon as you click the button, and then I send a put request. That put request is returning new content that is then gonna replace the pink heart with with the new one, which could either be white or red depending on how you were toggling it.
Lazarus:Okay. So you're yeah. Now that I'm seeing it, you're not even you're not using any sort of event listener, which I actually prefer, you just have hx on click, so along with whatever else happens, you're also calling the optimistic like, so that it can it can trigger that. So so if you were to generalize that, let me just think how that would work for other things because because, you know, you don't know what the server is gonna give back, for for other things. I think for this case that this works perfectly, because it's, you know, gonna be a variation on that heart one way or another, you know, heart or no heart.
Lazarus:But if you wanted to sort of continue that for other things, like, do you think you would maybe put, like, a placeholder or or maybe some, you know, what what would what do you think that would look like for sort of other data?
Mark:Right. So in in this case, the heart is just a Unicode character, and so I'm actually sending back text that is that one new character. But there's certainly a piece of this that I've omitted, which is if there's an error on the server and you were trying to change the heart from white to red and it changed to pink, it ought to go back to white if there was an error. And so I ought to have something on the client side that's handling that case as well. But I feel like this would general generalize pretty well if I was returning, say, a new row in a table and I've optimistically added the new row, and then it's going to fill in in a way that lets me know, hey, this is permanent.
Mark:Well, I might just have it, have that new row appear immediately with some opacity, like 60% opacity. And then when it's finalized on the server, change it to a 100%. Then I don't even have to send back any content. There, I probably would use an event, and I'd say if I get this event that indicates it was successful, just update the opacity. Right.
Lazarus:Yeah. I mean, so one of the things that, you know, when I talked to Carson Gross about about optimistic UIs, you know, it was just kind of interesting because, you know, his general thing was, like, do how optimistic do you really want your UI to be? Like, you don't if it's so optimistic that if it screws up you don't even know. You can't visually tell, you know, you think you did something and you never actually did, and this is the big, you know, issue that that you have and an example here I think he gave was, you know, you're trying to buy a plane ticket and it optimistically you click submit and it's like, you know, here we go. You got your here's what it should look like now that you have your reservation or whatever.
Lazarus:You're trying to reserve a hotel. And it's like, if that reservation never went through, you don't wanna see, you know, at a minimum you want like, having the opacity low tells you something. Right? But even then, you don't wanna see a success response. You don't want to see your final thing.
Lazarus:In my opinion, I think this is something where it's like I don't for it from a user perspective, like, I understand that sort of just wanting everything to be super smooth and you just click and it immediately does things. But from a user perspective I wanna know that something's happening and that something happened when it happened. So I I think, you know, what those sort of things you're talking about where you're, you put something there as a placeholder immediately, I think that's good. And then I think opacity is kind of a pretty well respected, you know, kind of way to to handle that.
Mark:Right. You might also want to label it as pending in some way, and then you might want to, on the client side, start a timer and say, hey, if I don't get confirmation in 5 seconds, I'm gonna assume this failed and and let the user know that it didn't work.
Lazarus:Yeah. And in in your case
Mark:cases where you don't need this optimistic update because it's just so fast. And in my case, if you notice in that endpoint, I have a call to bun dot sleep sync for 1,000 milliseconds. That's because if I didn't have that in there, you'd never see the pink heart. It's just so fast.
Lazarus:Yeah. And that's been my experience with a lot of this stuff too. It's like I I worried a lot in the beginning about some of the server calls, and I had the same experience with larva LiveWire where, you know, that's all server, you know, it's it's sort of you you write your PHP code, and it sort of handles the ajax calls in between, in a similar kind of way. And, you know, my concern is like, well, okay. It's I just like I've been on sites where you where you can feel it's really slow and, I don't know, janky or whatever, and and, it's annoying.
Lazarus:You don't you type something and the characters don't appear or something, you know, and it's just, like, what is going on here? So that was part of my concern with some of the stuff. And, like, what I found is, like, realistically, like, especially if you're embracing returning snippets and returning little bits of HTML, I mean, it's just as fast as it possibly can be. Right?
Mark:Exactly. Yeah. Yeah. Another thing that I wanted to mention is that for people that like HTMLX and wish that they could convince their developer teammates to take a look at it and use it, I think a good way to get them started is to really emphasize the four things that you're thinking about when you're using HTMX on a particular element. And that is, what triggers this element to do something?
Mark:Is it clicking on it? Is it an input whose value changed? Was it a form being submitted or or something else? Some event has to trigger this element. So that's number 1.
Mark:Number 2 is when it's triggered, what do you want to happen? What kind of a request do you wanna send and what URL are you sending it to? So that's number 2. Number 3 is when the response comes back, where is it going? What's the target?
Mark:And then the last one that maybe is the most complicated, but also interesting is you told me a target, but exactly how does it go in relation to that target? And there's 8 different options, and I think it's important to understand those. And I have one slide in my deck of my HTMX talk that I shared, that reviews all those HX swap options. But that's the thing that you could discuss with a developer that doesn't know about HTMX right off the bat is those four things are what you have to think about. And when you grasp that, you can go a long way with just those concepts.
Lazarus:Yeah. I would I agree. And I think I mean, really, I'm just trying to think about the sites that I've built and, you know, you throw in some extra attributes for, like, for instance, hx indicator or something like that, or or you you know, you add some other things for times you want to do something a little extra, but yeah. I mean so I think what you just went through was, you know, a checks trigger, a checks get, hx, target, and hx swap. And it's like Right.
Lazarus:Between those, you're just covering the life cycle of so much of what you need to do and not just with HTML, like what you need to do as a web developer, updating people's websites, responding to user stuff. I mean, it's like, that's the core of it. Right? Like
Mark:Right. But the amazing thing is that while you have to consider those four things with any framework, you're not gonna get it to be any more compact than doing those things in HTMLX, and that's what I love about it.
Lazarus:Yeah. I think that that's an interesting way to look at it because yeah. So I don't I really don't use React anymore. You know, I I have I've done some test projects and, like, a while ago, I, you know, I think everybody sort of looked into it. I got a little into Vue, Vue JS, which I think of as similar, but kind of in in between between Alpine and React.
Lazarus:Vue is sort of lives in the you can you can just add a little bit of it if you want to, but Vue sort of takes over more and more. You know, I think the big split for me and and I guess just technically is how much is being pushed to the virtual dom, right? Like how much are we living in the virtual dom? And with h tmx, the answer is basically 0. And with react, the answer is basically a 100%.
Lazarus:Like like you said, they don't want you to touch the DOM. If you touch the DOM, you might screw up their perfect model, their virtual model of the DOM. So, you know, somewhere in there, there's these other things that are sort of partially, but that's really, like, the big difference. So, like, how do you so you're sort of moving between these two different worlds on a on a sort of daily basis.
Mark:Yeah. It's painful because a lot of times I know exactly what I want to do to update the DOM, and I know that I can't or or or I've got to be really careful about how you do it. And so in React, you end up using this hook called use ref to get a reference to a DOM element, and then you can modify it. But you just have to be aware that React might blow away whatever change you made.
Lazarus:Right. This is like those those config files that say, like, don't modify this yourself. This is an automated config file that gets put here for you, except now that's your whole DOM. Yeah.
Mark:Yeah. But, yeah, if you work in the React world, I feel like you have to accept that the whole virtual DOM thing, while it works, it's incredibly inefficient. And, really, the only way to support that is you say, well, yeah, it's inefficient, but it's fast enough. And, yeah, a lot of times, if I put in a log statement, I'll see that this component actually got rendered 2, 3, 4 times. Why did it get rendered multiple times?
Mark:I don't know, and we don't have time to figure it out. We just move along. And so there's so much inefficiency happening in React apps, for those kind of reasons that just go away when you use something simpler like HTMLX.
Lazarus:Yeah. And so I don't add a few things on that and, like, you know, I don't I don't wanna be I don't wanna be aggressive towards react or anything like that. Like, people use what they I one of my good friends uses react and nothing else, and, like, you know, it's like I'm not trying to argue with the way if he likes that, if that's the way he used to use it, but, yeah, like, I saw recently going around you know, it's, like, I guess there's some website that will show you your React renders. So you can, like I don't know if it's a Chrome extension or if maybe it's even part of the inspect element now. Someone's been sharing it on Twitter, so I haven't looked into it yet.
Lazarus:But it it'll show you your React paints, so every paint. And you and it so you go to a web page, and there's just thousands of paints, and you scroll, and there's 300 more paints. You know, it's, like, something, and it's, like, unclear what it is. Un like, there's no to my mind, there's no logical path from, oh, I scrolled down a tiny bit to this one div had to rerender, you know, 50 times. Like, it just doesn't it doesn't quite make sense, but this is why these these these layers on top of it.
Lazarus:And that's, like, not even mentioning the amount of memory that all that is taking. Like, to create this virtual DOM, I mean, these DOMs are they they get big or they should be able to get big, and when you have this kind of memory thing, like you just can't really hold some stuff in it. Well, I mean, so that's one of the things that I, as part of this examples site that I want to do, and correct me if I'm wrong here because, you know, if you if you know react a little better, maybe this is something that, you may be able to speak to a little more, but one of the things that I kind of want to make this example site a flex on is what h tmx can do with the size of the dom. Right? So, like, the size of the dom makes no difference to h tmx as far as I can tell, you know.
Lazarus:I mean, it it has to kind of probably register something with each attribute. So in that level, if it has to register, you know, a 1000 attributes in some capacity because it has to, maybe it even figures out at real time, I don't know. But you can have an HTML page with, let's just say, a 100 pages of text. So, you know, let's say, like, let's say we did an HTML page that was literally this whole book. Like, you could display this in a browser, you know, if it was all HTML.
Lazarus:And if you added HTML tags, if you made every one of your books examples a live working example in an HTML page, I think you could do that with HTML. If you tried to do that with React and make every one of your examples a live working React example and register a 100 pages of HTML, I mean, I don't know. What do you think? Is that is that doable in React? What would happen?
Mark:Yeah. No. I don't think so. I think you're exactly right. It would be very inefficient.
Lazarus:I mean, it's just it would try to fit the whole thing into memory, and you wouldn't be able literally, you would not be able to click on a single part of the page because it would just never finish you know, it would blow up your your browser, I believe.
Mark:Yeah. I suppose, people in the React community would say, well, that's not a realistic example. We would never actually try to do that.
Lazarus:But So so let me push so, I mean, I agree. And this is what I so I one one of the reasons I initially came to, to h t m x was that this is something I wanted to do. I have ambitions to someday write, and by the way congratulations on writing at least 2 books, which is I think it's amazing. It's very cool. It's a book that is really well done, really well done books.
Lazarus:I really appreciated it. And you know, I I have had ambitions to write before. So I was building an app where I when I'm writing I like to be able to do command f and c, for instance, every time I used a certain word. So when I'm using, some other writing program, like whether it's just kind of, not Microsoft word. That's not what I use, but, whatever I'm using for writing pages or something like that, whatever I'm using for writing thing, you can open your whole document.
Lazarus:You know, it's just text. Like, computers can handle plenty of text. But if I wanted to make a writing app, like, a function is something that I could go online, and I would it would be available from anywhere. And then I have my specific flavor of writing tags to help me keep track of my writing. You know, this paragraph, I tag it with something.
Lazarus:You know? So this is the idea for the app that I had, but what I wanted was to be able to show everything on the page, like, everything, even if I'd written a 100 pages. You know? And so I started building. This is before I learned what 8 by HTMLX.
Lazarus:I started building this, and I used first, LiveWire, and it was way too slow. Just couldn't load everything. Everything was going to the virtual DOM. Then I switched to Alpine. I was like, okay, Alpine's a little more lightweight.
Lazarus:Same problem. Everything has to go into this virtual DOM, has to get stored in client state. Then I just tried HTML. Everything was perfect, loaded fast, but now I lost all my, you know, cool front end capabilities. And that was where I discovered.
Lazarus:That was when I found HTMLX was, you know, and it filled that gap. And and I think so I do think the React people will tell you, and and this is not, like, nothing against React. Like, this is the the web. Most people, not just React people, will tell you nobody wants to see that much information at once. Right?
Lazarus:That's why there's pagination, that's why there's infinite scrolling, that's why there's, you know, all these different, you know, breaking up your navigation into reasonable, all very reasonable, like, but every now and then users want a lot of information, and that's true of the apps that I work on, and I think it's I think there's a contingent of people out there, who do want more information at once, and I this is I feel like, HTML makes that possible for them.
Mark:Yeah. I would agree with that. Certainly.
Lazarus:Yeah. I mean, it's, you know, it's so this is just kind of a pet project of mine that I may never end up doing, but that's gonna be part of this h tmx examples. The hype cp page is, like, showing that off. You know, I just think it's a cool thing. And, you know, people talk about the limitations of a server side thing, and and I think there's limitations of the client side thing too.
Lazarus:So I think just kind of, you know, highlighting those and making it so that the the the client side ones are are also so you can sort of see the power of the server side ones as well.
Mark:Yeah. Yeah. That'll be great. So I wanted to share, information about my blog. I'm constantly writing about different tech topics and HTMX is one that I started writing about and, many other things out there.
Mark:And so my blog is at, mvolkman. Github.ioblog. Lately, I've been writing a lot about the small talk programming language. I've gotten fascinated with that over the last 6 months or
Lazarus:so. This is like the language from the seventies. Right? Like this is like I think I learned about that in computer science when I went to college.
Mark:Yeah. So it's one of those things where I feel like there are good qualities of it that we've forgotten about and not replicated in other programming languages. So, yeah, I've been having a lot of fun with that. But, more than just pointing out my own blog, I would encourage everybody to, write about the things that you're learning. I can say this as a person who's probably older than most of the listeners that, you just can't hold all this stuff in your head.
Mark:And there are things that I learned very deeply, like, 2 years ago. And now if you ask me about them, I remember almost none of it. But it's all very well documented in my blog, and I can go back and retrieve that anytime I want. So I think that's important.
Lazarus:Anybody else. Yes. Exactly. Just yeah. I mean, this is a this is a great service, I think.
Lazarus:And this is just something that I see that a lot of people online do this. Not I mean, not really not that many, compared to how many people are there, but I really appreciate when people, after they figure something out or usually write as you figure something out, it sounds like, you know, you kinda write it up, and and that's that's the perfect time to do that because you're discovering it slash learning it, and and then you put it up there for everyone going through that.
Mark:Right. And it's especially useful for you because it's described in the way you describe things with examples that mean something to you. And a a tip for how to get started if you haven't done this yet, Pick a platform for creating your blog. I use Eleventy for mine, but there's so many options out there. Astro is a good option.
Mark:There's many others. And so the first thing you should document in your tech blog is how your site generator works. Just document the thing that you're using to build your blog. That's what I did. My blog was initially just all about Eleventy.
Mark:And once I had it up and running and I felt like I was done talking about Eleventy, then I just went on to other topics. And so nowadays, anytime I learn anything, it has to go in the blog somewhere. Some of my pages are very detailed. Others, there's not a whole lot. Like, for example, I have a page on SQL, and it's not very long, but I don't have to remember what an insert statement looks like in SQL.
Mark:I just go to my SQL page in my blog and refresh my memory.
Lazarus:Yep. So
Mark:I think that's a good habit for developers to get into.
Lazarus:No. That's, like, that's great. And I'll just second that and say, you know, if you're like me and if you have ambitions of writing and you still find it very challenging or time consuming and difficult, like, you know, powering through that and, like, everything that I've ever actually produced I really appreciate. Like like you said, like, it's useful for me and I feel like it's a record, but this podcast is the same mentality. I was learning HTMX, and I was like, you know what?
Lazarus:As I learn it, I'll just talk about the things that I've learned. And that was really the genesis too. It was like this is, you know, because it also it also guides your learning a little bit, you know, when you start sort of thinking about it and talking about it. You know, for me, talking is probably, 50 times easier than writing. So so, you know, I wish that I could sit down and write something comprehensive and clear and, you know, what what you've done with the book is awesome, and I think this is something to strive for and and something that's very useful.
Lazarus:But, yeah, if you can talk, that works too.
Mark:Yeah. I've listened to most of your podcast episodes, and I can only imagine how much you learned when you started the series of going through the advanced features. Because I would guess that for most of those, before you decided to talk about them, you probably didn't know a lot about them, and now you do.
Lazarus:Yeah. No. I mean, I made it a point to try to get all the requests and response headers, and I, like, I just I barely ever need to use them. But going through that process and seeing that they existed and trying to figure out in my head, what would this be used for? And then for some of them, I set up some examples and stuff like that, just for myself.
Lazarus:And it's like, it's it's totally true. It's, you know, you don't know what you're missing until you start to kind of get into it a little bit. And then it's like, wow. Like there's this whole other world of options out there that didn't even know it was possible.
Mark:Yes.
Lazarus:And, yeah, that's that's just from the writing and from the I mean, not so much from the writing, but from the talking about it.
Mark:Yes. Exactly.
Lazarus:Wow. Very cool. So so let me just, like so what was the like, was the other book you wrote, was that the first one or so you sort of did you start with articles and then you like articles on your blog and then you sort of, like, realized, well, I'm writing a bunch and I probably can put together a book now. Like
Mark:Yeah. So if I go back in time a bit, I started teaching classes when I was in my twenties, and I was teaching things like business math and Excel spreadsheets and then quick basic. And then I went to work for my current employer, and I was teaching c plus plus and a lot of Java related courses. And so back then, I was creating my own course material and creating slides. And then I started into writing some articles, and trying to give talks at conferences.
Mark:Yeah. So it's just more and more writing, and speaking, and presenting from slide decks that I created. And so for both of the books, before I got the book deals, I'd already written maybe half the content. Because since it's my practice that if I learn something, it has to go in the blog, That goes first. And then all of a sudden I realized, hey, I've got like a 100 pages of content here.
Mark:Maybe this is the start of a book. And so by the time I pitch it to a publisher, it's kinda half written. The main job is to reword things in the way that they like the writing to be for that publisher.
Lazarus:Wow. Interesting. Yeah. And I noticed the publisher was a pragmatic press, which I thought was good here. Which is that makes sense for the this is a kind of pragmatic book with a lot of, like, real world problems in it and stuff like that.
Lazarus:So it feels like you found a good match for that kind of stuff. Definitely.
Mark:Yes. And
Lazarus:then, yeah, you can see some of those kind of, what I would think of as, so you said you did some teaching as a as a professor or as just kind of, like, what was your sort of role?
Mark:So we we the company that I work for, Object Computing, we were big in the training business early on, and we were doing part software consulting and part training. And we were working in conjunction with a local university called Washington University in St. Louis. And they have a continuing education program where employees from local businesses would send their software developers to these mostly evening classes to to learn new things. And so we were applying a lot of courses for that department of Washington University.
Lazarus:Interesting. Yeah. I mean, I noticed that almost all your chapters end with or maybe they all do, but end with, now you go try this, and that gives you, you know, a an assignment. So this feels very academic. It feels very like Yeah.
Lazarus:Like like you're taking a class. And so you, like, you know, they you you show the example, the generic example, and then you leave, you know, you leave people with it. Now you try it. That's a variation with something a little different, something to kinda, like, take the next step and recreate it a little bit. So I thought that was cool.
Lazarus:Nice. Well yeah. So I I mean, I guess, you know, anything else you sort of would like to we're at about an hour. So, anything else you'd sort of want to say about the the book in general or, anything we didn't touch on?
Mark:Yeah. I would just emphasize that the point of the book is not to convince you that you should implement your back end in JavaScript or use Bun or Hano. Not at all. And part of the book is talking through, what are the qualities of a server side framework that are good, so that you can make your own choice. And so, yeah, I think it'd be a good idea to take some of the simpler examples in the book and reimplement them with your choice of server side tools.
Lazarus:Yeah. Yeah. Definitely. And that part, you know, I don't want to say trivial, but the stuff that's happening on the server, you know, is not that's not the focus of the book, you know? It's like this that's it's really the stuff that's happening in the HTML with the attributes.
Lazarus:You can see, exactly how the attributes are kind of working together, and you do a nice job of kind of laying out as a narrative, the reasons for that. So, yeah, I just thought it was a super cool, very well done, you know, any language, less code, simpler code is kind of the tagline. And so I think the simpler code, less code and simpler code concept, I think is very appealing to a lot of people who are in, who are, you know, listening to this and into HTMX in general, myself included. You know, anything that makes your life a little easier.
Mark:Definitely.
Lazarus:So, yeah. And I don't know, just, I, I would, I would second what you're talking about with, with writing up what you've learned. And I think that's a really cool way to approach things. It sounds like your blog. So how long has that blog been around?
Mark:I think it's only been maybe 3 or 4 years. So Okay. I was just, writing in text files before that.
Lazarus:Oh, so you had your own personal blog that you were keeping just for yourself?
Mark:I have a GitHub repository. I think it's called my unix env, where I have all my dot files for setting up a new environment. And then I just have a directory in that repository called notes and then a separate text file for each topic. So that's how things got started.
Lazarus:And this is all public?
Mark:That's public as well. So if you go to
Lazarus:my GIFs and
Mark:look for my UNIX ENV, you can find that.
Lazarus:How far does that go back?
Mark:Oh, that that probably goes back 25 years.
Lazarus:Oh my god. Yeah. I mean, that's crazy. That's cool. This is like I mean, I this is like, an entire career's worth of knowledge kind of, like, divvied out 1 by 1.
Lazarus:Are are they, like, organized by date and stuff like that? Like, can you sort of tell when stuff is from?
Mark:I mean, I guess I can look at the time stamps on the files and see when I created the file when I last modified
Lazarus:it. Okay. So somehow you could get that info.
Mark:Yeah. Yeah. But certainly the content on the blog is much newer.
Lazarus:Yeah.
Mark:You know, there's a lot of information on different programming languages. For example, for a while, I was writing a lot about Rust and OCaml and Lua and Swift. So a lot of different languages. There's a lot of information on developing iOS app applications using SwiftUI. Oh, interesting.
Mark:Like I said, now there's a lot of content, content on small talk, just a whole lot of different things out there. A lot on different tools, like, tmux or, my new favorite terminal emulator that's called Warp. A lot of information on that. There's a Mac utility called Raycast that's really popular. So I've got a page on Raycast.
Mark:So, yeah, as I said You
Lazarus:gotta figure out some way to, like, some automated process to go through these files and then create a blog post out of them. Like, that doesn't even have to change the text. All it needs to do is check the time and, you know, new post with a new name and put that up available. I mean, this is like a wealth of information. That's super cool.
Mark:Yeah. Yeah.
Lazarus:Actually, one more thing I'll say about that. So do you are you I I just wanna are you, have you used AI much with stuff? Is that sort of part of your process or do you sort of,
Mark:Yeah. There there are 2 tools in particular that I use. So I started off, using GitHub Copilot because we were working with a client that was paying for us to use it. And when that engagement stopped, I had to decide was I gonna pay for this myself or could I find an alternative? And I found one called Codeium, which for me has been just as good as GitHub Copilot, and it's free.
Mark:And it integrates with Versus code. And so that's why I'm using Codeium. And then I also make a lot of use of chat GPT, just going to a browser tab and asking questions.
Lazarus:No, me too. I think it's great for
Mark:me. In a typical day, I bet I ask 20 questions of chat GPT.
Lazarus:Yeah. You
Mark:know, like a lot of people say, it's only useful if you're being careful to look over the answers and don't just automatically trust them because sometimes that's wrong. Yeah. But as long as you keep that in mind, I get a lot of use out of it.
Lazarus:No. I do too. For sure. Especially when I'm poking and prodding into new technologies and new things, and I'm like, what's the syntax for this? Like, I know what I wanna do, but I have no clue how to do that.
Lazarus:I'm using Flutter right now for a project. And so that's like the big thing where I'm like, don't quite haven't quite understood the syntax for it. So it's extremely helpful for that.
Mark:Yeah. Well, I'll I'll just throw out that my blog has a large amount of content on Flutter.
Lazarus:Nice. That's cool. So if you were to, like I'm trying to think how you would do this, but it's it's probably too intensive and would end up, like, taking too much because it's gotta be I don't know what the amount of words is, but, like, I'm just imagining a very cool document that you could produce if it went through if you took all the different notes that you've done over the years and organized them into year, you know, so just, like, by the created timestamp, put them into a year bucket, and then ran that bucket into chat gpt. So each year gets its own summary. I bet that would be a super cool, like, look at your career.
Lazarus:It would probably have some surprises in it that you've forgotten about.
Mark:Definitely. Yeah.
Lazarus:Well, yeah. If I had that kind of data, I think I would I mean, the thing is I know it's it's a pain in the ass probably to to cycle through everything and put it into chat gpt, but I just think that's fascinating to have 25 years of your own personal notes, you know, that are not just not just notes that are incomprehensible, because it sounds like you've been writing them up in a way to be useful. Right? I mean, it's like I
Mark:want it to be consumable by other people. Right?
Lazarus:Yeah. I mean, this sounds like this is very cool. And and, you know, if, it'd be awesome to have that sort of I mean, I know it's public in some ways, but it's also sort of hidden, but that's that's just a very, very interesting thing. And I'm not surprised now that you say you've been doing that for 25 years, that you were able to write a book with about new knowledge because it sounds like you've been prepping for that purpose for a long time.
Mark:Exactly. Yes.
Lazarus:Yeah. Awesome. Alright. Well, I just wanna thank you very much for your time. I really appreciate you you talking today about hypermedia stuff and and and your book and HDMX in general.
Mark:Sure. This is great.
