What is htmx good for?
So a question I see a lot online, and a little bit on Twitter. And I did check out Reddit a little bit and I got some good ideas. I put a post up there about what to do for the next season after the advanced attributes, and I did see some some great ideas, for, you know, future sort of seasons and and what kind of to talk about. But a question that I I did see a lot in different threads is what is HTMX good for? And it's not always in, like it's not said in, like, a mean way.
Lazarus:Like, people are genuinely people who have tried it or haven't tried it are genuinely trying to figure out where it fits into the development space. Because some of the other tools out there, it's pretty clear. Like if you're building, you know, I don't know, Flutter, it's like, okay, that's for mobile apps. And if you want it to work on iOS and Android, then you use Flutter or one of the other ones that do that. If you're working on the back end, you can use Rails or Laravel or, Django.
Lazarus:If you are building stuff in the crypto space, you're probably using React JS, or just in a in a lot of different sort of, applications and startups. Maybe that's what you reach for because that's sort of what's what's popular now. So where does HTMX fit into this? What is it good for? What type of applications?
Lazarus:And this is probably, this is too big a question for me to really like fully know the answer to. HTMX is relatively new. I think it's kind of getting a foothold. It's part of a class of frameworks and libraries that are treating, you know, high hypertext and hyper script, hypermedia, as kind of a first class citizen, where you are sending HTML using HTML for different things. You're sort of doing Ajax, Laravel Livewire is 1, Phoenix Live View, h tmx, Hotwire as part of the the Ruby community and the Rails community.
Lazarus:So there's a kind of a new class of tools that are that are doing this. Some places have been doing it for a while. GitHub, I think, is one that's been doing it for a while. So what do you when is it sort of okay to use these? They're all sort of relatively new.
Lazarus:So people are trying to figure that out, And it's not it's it's not exactly just a technical question. It's also, what the market kind of needs. So I think one of the things that, you know, the creator of HTMLX has said you know, people ask him all the time, like, you know, what what's a good use case to use it? I've seen him answer, it's not if you're if you're looking for a job, go learn React. And, you know, I don't think that's just that's that's fair.
Lazarus:You know, that's the market right now. If you are, there's all these boot camps for React, a lot of the big companies, that's kind of like what they're that's that's the zeitgeist. That's what is out there right now for the sort of the top thing. That sort of style of building a a massive SPA that you just sort of more and more JavaScript and the JavaScript frameworks, and now they're sort of pushing JavaScript frameworks on the front end, sort of trying to use those in the back end too. So that is maybe more likely that it's more difficult.
Lazarus:So, you know, people who can who learn that and are get good at it, there's a bigger market for it. So, you know, it's a little bit, it's maybe a little bit of a joke, sort of like, well, if you don't if you don't care about getting a job, then use HTMX. But, you know, it's not something where you're like there's not like a big search engine for, like, we got to find HTMX developers quick. That's just the case right now. That's just the market.
Lazarus:So that's like a reality to accept, but none of that is technical. So the technical reasons to use HTMLX or to choose HTMLX over other tools, that's kind of what I think I'm more interested in, what sort of projects. So the bigger picture is that I think HTMLX can be used at any scale for almost any type of project. It's not the best for every type of project. I just I came across this site the other day that let you, it was a React site, and it let you basically paint with JavaScript, you know, or paint like in your browser.
Lazarus:You could like choose gradients and use these like color sliders. I don't know. It did a lot of stuff, all front end. Everything was front end. Maybe there was a save button somewhere that went to the back end.
Lazarus:I have no idea. But that's a good use case for like a little app that's like an SPA, that just kind of lives on the client and doesn't really need it doesn't need a lot of data. It's all about your client side, front side, front end interactions, and dealing with those in in basically, it never moves outside of JavaScript land. Perfect use case for React, terrible use case for HTMLX, in my opinion. You know, I just you're gonna end up writing a bunch of JavaScript anyway, so that's fine.
Lazarus:But that's not the majority of projects. There are most projects involve, you know, these kind of basic rest concepts. You have a database somewhere. You are you have tables in that database. If you were to think of every table as a model, as, something in your application, which is how most of this stuff works, you know, you save stuff, you update stuff, you, you know, insert, update, delete, all these kind of basic things.
Lazarus:And, yes, that gets complicated. You can do fancier stuff. You've got all these connections between the different models. You can do all these different things. But none of that is you know, that's all kind of expected.
Lazarus:That's part of every app. So some of these apps that I think people now are sort of defaulting to React would actually be much better served using something like HTMLX, which sort of simplifies that process. It keeps a lot of your your interactions, and it keeps it sort of closer to the back end, closer to your your database, and closer to, you can generate everything from the server side. And, you know, where you need to update and change things for the user, give the user a good experience, you can. You can load different things at different times.
Lazarus:So, you know, there's a there's a vast pile of projects that, in the technical sense, htmx is excellent for. So practically, what sort of stuff could you use it for? I think this has been said before a bunch, but if you're just getting started, you know, maybe you don't want to to take a, you know, just jump in and and build some some project for, you know, if a client is kind of like pushing for something, you know, do you want to have that fight and try to say, you know, let's start with HTMLX and, you know, maybe. I I don't think you would actually go too wrong doing that because it's so easy to learn that you'd probably be fine. But if you just are getting started, I think an internal tool for your company, for your own personal projects So this is, you know, this is again just for people getting started.
Lazarus:If you have if you have some project that you've been thinking about building, that's a good place to get started. Build it with HTMLX. Build it this is something you're learning now. That's the best way to learn. Just build it and see what happens.
Lazarus:Same with internal company tools. You know, make the case. If you have the if you have the voice in your company to say what technology you can use for internal projects, I would push for HTMLX because it's such a low ask. You're not you're not, like, it doesn't require a bunch of other stuff. You're not introducing, all these other layers of complexity.
Lazarus:You're just saying, like, you know, along with our regular HTML that we're serving up, can we have this little include? And then we can manage our project through that. We can manage our project through AJAX, and it basically will play along with whatever else is going in there. So if you start doing this on internal company projects, internal company tools, you'll get familiar with it, and the company can get a feel for it. And you can sort of, you know, I've done this with with a bunch of projects now, and there's a certain level of stability, that I really appreciate.
Lazarus:You know, you're not running npm run build dev. You're just not running any of that stuff anymore. You're not compiling the front end. You're not coming across conflicts. You're not updating.
Lazarus:You're it's just an include. Those attributes, maybe they'll change at some point, but they're such core they're set to have such core uses that they're not being updated. They're not changing all the time. They don't need to change all the time. So you're sort of able to to build this tool and just have it work, and it's it's extremely reliable.
Lazarus:So for an internal company tool, that's perfect. People get used to stuff something being reliable. And then, you know, eventually that can sort of migrate into your primary primary tool to use. So another great use for it is legacy codebases, and I think the very first episode I ever recorded of this sort of talked about that, but because you can just put it into any project as an include in at the core level, it's just, you know, a CDN or whatever. You can put that into really old projects, and build some very fancy stuff in places you kind of wouldn't expect.
Lazarus:That's something you just you cannot do with one of the big kind of, other front end JS frameworks where you have to, go in and basically rewrite or reimagine all your web based things, to fit with the mental model and with the physical, you know, the actual virtual dom model that those things require. You know, this doesn't put a virtual dom over everything. It doesn't care what the rest of the DOM is. You know, your how you use the h tmx in your project, you can just use a tiny little bit if you want to. And that way it's kind of similar to, you know, this this sort of like using these attributes.
Lazarus:Tailwind and and alpine are kind of similar. You use these attributes inline. You don't have to rewrite your whole the whole, you know, it works on the outer layer of your HTML. So you don't have to go in and rework how you do all your HTML, and how you organize your entire site, and all the models, and everything like that. So for legacy projects, older projects, projects that you don't know the code base that well, Those are all really good ways to get started, and and sort of incorporate HTMLX, and also just build some cool features that you might not otherwise be able to build.
Lazarus:So there's a I read the book Hypermedia Systems, which I really highly recommend. Reads really like a novel, not like a novel, but it just reads really smoothly. It carries you through the process, you know, starting web 1.0, and then sort of bringing in these other HTMX things. And I think it's it's really well written. And one of the small things that they mention is there, the book actually recommends against, like, a spreadsheet style application, because because HTMLX doesn't, you know, you sort of when you make changes in a spreadsheet, you're sort of expecting this cascading results to happen somewhere.
Lazarus:Right? So the thought, I think, you know, from the author, authors is okay. So, you know, that's probably front end stuff. It's probably doing some validation. It's probably, you know, you need to see immediate changes.
Lazarus:So a spreadsheet style application, maybe is not that good for h t m x, which which would probably, you know, your instinct would be to have it hit the server or something like that, rather than just do things on the front end. I would actually heavily contest that. I have done some experiments with like large spreadsheet style applications, and I've used, Alpine. I've used React. I've used, this is just as a test.
Lazarus:Larva Livewire, which is another one of these great sort of hypermedia systems, and I have used let me think. What else did I try with? I tried basically just tried a bunch of different samples of different frame you know, front end Oh, view. I also used view. So the problem with every single one of those, and the reason they just basically do not work for large spreadsheets, is that they all put the they have their own virtual DOM, which is just stored in the memory of your browser.
Lazarus:Right? So it has to know all these different things about every single cell. And what it does is it just gets slower and slower and slower. So, you know, for trivial situations, you have like a quote unquote spreadsheet with, you know, 50 rows or something like that and 10 columns. You know, even that might be hitting some of these limits.
Lazarus:But that's tiny. That's not a realistic situation. Realistically, if you're doing building some sort of cool spreadsheet app, you're gonna have a lot more data than that. What I found was that straight HTML is extremely fast to load, extremely fast to show. Just adding HTMLX to that, still extremely fast.
Lazarus:And when you make a change, you know, sure, maybe that has to hit the server, but you're not hitting the server with a ton of stuff. You know, HTMX gives you the control to decide your server can send back the data exactly to where it wants to go. If you've made some update, you know, you need to have some logic somewhere, whether that's on the front end or the back end, that tells you if that's gonna update somewhere else. Right? You're gonna you change something and there's a sum somewhere.
Lazarus:Right? Something like that. That's just a simple example. There could be much more complicated examples, but that's a basic one. And somewhere that logic has to happen.
Lazarus:If you have used one of these front end frameworks that has put this entire virtual DOM into your client, and you start having 100, let's say, 1,000, 50,000 cells, it's just gonna crap out. Doesn't matter how good it is, how efficient, you know, Alpine is like one of the most efficient, tools for front end, you know, it's like a you can use it just sprinkled in. It doesn't take over your whole app. It's a great great product, but it still requires its own model, a complete model of all your data stored in the client side. So it's going to crap out once you get to a large number of cells.
Lazarus:HTML does not do that. It just doesn't care. It you know, it's the HTML is enough. It's not storing its own mental I should say mental, but it's not storing its own map of all the data and linking it. It's relying on that HTML that's there contains the information that it needs to send updates as needed.
Lazarus:So the updates only happen as needed. You're not it doesn't have this listener these these I mean, it has listeners, but it doesn't have these kind of, you know, I can't think of the right word for it, but anytime something is modified in the dom, these things are are looking at it. These morph dom programs. These are they're checking to see what all the changes are, and what the cascading effects are, and all this stuff. Extremely expensive once you get to high volumes.
Lazarus:So, HTMLX, I would say, is actually the the way place it really shines is when you need a lot of information on the page, and that's a spreadsheet style app, would be perfect. Apps with lots of text, you know, you can do a lot of stuff with the text maybe, you can edit it, you can do this and that, but you need to display a lot at once. Perfect for HTMLX. And there's just, you know, I don't really know what the full limitations of h t m x are, because I have tried to push up against them, and I just have not hit that point where I'm like, oh, okay. Well, you can't do this.
Lazarus:I mean, you know, there are obviously things that are because h t m x is is sort of handling the request, the AJAX style request. So, you know, you can still use these other tools as needed. So if you want to put a little bit of Alpine in there, which is kind of I would say that's probably what I do in those situations where if you do have to have either you just use vanilla JavaScript, straight JavaScript, if you do have to have those type of client side only events, you can still have those. And there's plenty of things that, you know, need that. Plenty of, plugins and stuff like that.
Lazarus:Those are all still there. So HTMLX doesn't limit you in that way. It's not like if you use HTMLX now, JavaScript is off the table. It's just taking those things that you're generally doing with JavaScript, those server requests, and encapsulating those in sort of a simple way. So it doesn't I'm not hitting sort of the limits that I think people are sort of imagining with a tool like this.
Lazarus:And in fact, I'm getting much better results, much faster loading times, and just a really good user experience. So I guess what this is all to say is, you know, what is HTMX good for? It's good for so many apps, and it's good for people who grew up in an era where it was still kind of web 1.0, and the mental model of how the web works, which is actually, you know, the way that the web works. You know, I think there have been a lot of, you know, this kind of concept of of an SPA, and where you basically just build everything on the client side, and then you just have this kind of communication layer of JSON back and forth. You know, I remember this from much longer ago, and I'm not just trying to say that I'm old, but, you know, they had these things called applets, And it was little applications that you would go online, you download this applet, and the applet would be like a little game or a little program or, you know, something.
Lazarus:And it would have some level of communication with the outside internet, but it was mostly self contained. And you you could still sort of run it. I think it ran in the browser, but maybe it was something you downloaded. You know, this I kind of forget that. But that's what I kind of see the the goal of the sort of SPA is like, you want everything to be moved over to the client side.
Lazarus:And you're sacrificing some stuff by moving everything over to the client side and keeping all that stuff in memory at all times. You're sacrificing just so many of the good things, the simple things about the web where you have, you know, the the internet and the web, it's all these HTTP protocols are very good at caching and saving links. And, you know, if you use regular links to go back and forth, you are it's optimized for all that stuff. Your browsers are optimized to show you HTML. So if you start sharing HTML, showing HTML, using that, instead of kind of building this little private, you know, repo inside your inside your page, you get a lot of gains from that.
Lazarus:So all this to say, I guess, h t m x, I have not found what it's not good for specifically except kind of, what I would call kind of edge cases of apps that have these very specific, you know, user interactions that you just it's all JavaScript. If you're if you're using something like that, you know, I that makes sense. And if you already know and understand gulf between, you know, the apps that need to be built and what you can sort of build with h t m x. To me, those 2 are are very close. And I'm open to sort of hearing people's experiences trying to build, you know, a bigger app.
Lazarus:Obviously, h t m x is relatively new so I don't know that there are that many sort of big projects. You know, people don't also always like ad advertise what technology they're using for different projects. But I expect to see, you know, a lot more large scale projects and kind of popular projects built with it, as we go forward. And I just saw, you know, someone posted something today on Twitter that was this is a sort of a sample site built with HTMX, and it was gorgeous. Like, animations for little inter user interactions, everything loaded nicely, the URL changed so you could refresh.
Lazarus:I mean, this was just like this felt like a very slick, front end app. And it was all built with h t m x. And I just I I think right now people are trying to figure out what's possible, and I think that they are going to find out basically that a lot is possible and that some things, particularly large amounts of HTML and data heavy sites and stuff like that. Some things are going to perform just incredibly well, with HTMLX and long term are going to be easier to support and your team is going to have probably an easier time picking it up because that's just There's a level of complexity with some of those other things, that you're just not going to come across with h t m x. The the level of complexity is so low.
Lazarus:You know, the the theoretical concepts you need to understand. If you sort of have a basic understanding of how the web works and how HTTP works and how AJAX calls work, once you get familiar with all the tools in the toolbox, that every one of those tools you know just kind of expands the limits of of what you can do. So what is HTMX good for? Is it good for getting a job? You know, you put that at the top of your resume?
Lazarus:Not yet. Is it good for building apps? I would say absolutely. And I hope to be building I hope to be posting more. I'm already building apps, but they're private apps.
Lazarus:So, you know, I can't necessarily post. I do, you know, I do a lot of client work and I also do some work for myself. So at this point, you know, I can't really post a lot, but, I would like to start sort of posting some examples if people have examples, of, you know, cool apps or sort of things pushing the limits of what HTMX is doing right now, like that I'll I'll post in the liner notes, I'll post in the in the notes that, HTMX video site, which I just thought was very slick. So things like that, you know, I think kind of building those things up and just helping people get an idea of, you know, expanding their their mindset on what's possible is kind of exciting to me. So thank you for, indulging.
Lazarus:This is, probably the longest episode I've recorded yet, and, I hope it made you think a little bit.
