Is HTMX a Joke?

Welcome to Syntax. On this Monday, hasty treat, we're going hypermedia.

We're going hypermedia. We're talking all about h t m x from a practical perspective.

So we're not gonna be getting too much into actual code here, but bigger picture things. What do you need to know about this as somebody who might not know anything? My name is Scott Tolinski. I'm from Denver.

With me, as always, is Wes Bos. Wes, what's going on, my man? Pretty excited to talk about HTMX

Today, it's funny that if we go back to the potluck episode questions we had, we've had questions about HD Max for years. Here's the ATLOM account. It only seems recently with the, like, sort of swing back to the server, a lot of people are are talking about it, and, I'm pretty stoked about it. And it it is not the new Microsoft version of HTML that you may have thought. You know, when Yeah. Microsoft, what what version was it? Were they, like, XLSX and docx? You know, they added an x to the end of all their new formats. And everybody, yeah, everybody got angry. I got angry about that. That was obnoxious.

That was like Windows Vista era Wes they were just really

making big mistakes all the time. Yeah. Well, like, it was a new format. So, like, the same thing happened with common JS JS that there's some way you need to Put some sort of metadata in the file extension so they added an x. Is that why they did it? Probably.

Probably. And you know what, Les? It it it It's like, only you could tie, XLX x Excel The word x or whatever, docx, whatever these things. Only you could tie docx to the e s m common j s, kerfuffle that we've had.

So, I I'm gonna preface this episode by saying, if you hear some of my words come out different, I had dental surgery on Thursday. It is now Tuesday, so it has not even been a full week. My mouth is recovering.

And if you are doing surgery on your code, you're gonna want to have a tool like Sanity in your corner to to make sure that you capture all of your errors and exceptions.

My mouth hurts. I don't want my brain to hurt as well because I have a bunch of bugs and errors in my code that I can't find and solve. And so this show is presented by Century, something that you might actually need if you're getting into Tools like HTMX.

So let's get into it, Wes.

I have Fallen for h t m x like so many other people in the meme world online.

I like it.

I I I feel all kinds of things using it, and I I feel odd right now. I feel odd that I like it so much. So we're gonna be talking a little bit about high level, what this thing is, what you need to know about it.

Basically, HTMLX is a small library for swapping out parts of your UI with a response from a server. That's the big picture.

People talk about this often in the context of HTMX versus React.

React is doing a lot of different stuff than what HDMX is doing.

And I think it's gonna be really helpful for you to kind of Get a what you need to know before even thinking about HTMX, so that way we're all working from the same bits and pieces here. I I do want to credit HTMX.

I've often been critical of some of their humor online. I think some of it It's too much from that's coming from the guy with a monster truck intro to the podcast.

So I I guess I'm Node to talk. But I gotta say, my favorite piece of humor in their documentation, which is which is good, is this line right here. It says, HTMLX finished 2nd in the 2023 JavaScript rising stars front end frameworks category just behind React. And then in parentheses, it says, HTMX is a library, by the way.

Which, React folks We'll laugh at that because React, may a big thing to be. We're just a library. We're not a framework.

And I thought that was Just a cute bit of humor. Oh, that's a nice little jab. It's a nice little jab, and it's just playful.

So what do you need to know before working in MX. One, you need a server, straight up. You need a server to return HTML, which, is important because, you know, many of our servers, they return JSON right now.

Maybe some of them are returning HTML, but you know what we've been working or maybe they're returning React code. Who knows? Right? You're using React Vercel components.

Long story short, to work with this tool, you need a server that is sending HTML to the client.

Yeah. That's that's a big part. And we had a question on the last podcast of, like like, is is HD Max a replacement for, pug or for server rendering or for templating, and the answer to that is is no. Right? HTML does not care what your, your back end is like, and it only cares that you are shipping HTML to the browser,

and it will know how to swap out the parts of your app. Right? That's big. Correct. In fact, one of my things on you need to know before starting is You will most likely need some kind of templating ESLint.

And that goes along with whatever server side manner you choose to use.

Django has been very popular of a choice. I don't write Python myself, but I've used Django before. People seem to really like using Django.

And you would use Django to generate your HTML.

Right? And, likewise, many people are using Go as a back end that's fairly popular in this space.

There's people using JSX and transforming it to HTML.

There's people using Pug. There's people using any of these, handlebars, whatever. Any of these templating languages.

You you could use React.

Right? Like, you could A 100% server side render your React and then just use HTMLX on on the other Node? It's probably you're probably not do that, but you could. Right? You could. Absolutely. You could use Svelte. Anything that gets you from code to HTML

as a string is fair game. 2 or 3, you most likely do not need as much client side JS as you think.

So you still need something to do client side JS.

A lot of people reach for something like Alpine, which is a lightweight client side library.

And this is one of those things where you're like, okay. If it's a replacement for React, which I don't necessarily feel like it JS, and it it it's not analogous. Right? Yeah. You still need occasionally things to work with client side code. That could just be straight up vanilla JS. In fact, that's how I'm doing it right Node. And I I got not a lot of beef with that. I think it's pretty great. Yeah. Like like example, if you had like a

A ESLint of people and you wanted to, like, remove somebody from a team. Like, you could render out the whole team. You have Scott. You have Wes, you have Sanity, put little x's beside them. And then, when it comes to actually removing one of them, you could use HTMLX, just to, like when you click on that x, it sends the event to the server. The server removes it from the database and re renders and sends that back.

But if you wanted to, make that let me start that again. But if you wanted that to to be a little bit more interactive, maybe you wanna drag and drop, maybe Do you wanna, do some stuff in the browser that is based on browser events? That's when you need to reach for something.

Alpine JS, Vercel JavaScript.

There's lots of different options out there. Right?

Yeah. Absolutely. So whatever that may be. And the cool thing is is you're working with the DOM, so you don't have to bring in, you know, HTMLX, draggable library. You just Get to use JavaScript, which is something I really appreciate about Svelte, right, is that you can work with the DOM.

Therefore, you don't need as many specialized tools. To go along with your point is you don't work in JSON. So what you're not doing is you're not modifying the data structure underneath the UI to affect the UI. In React, you're removing something from an array, and then that therefore will remove a DOM element from the UI.

With this, You're removing that DOM element from the the UI or adding a DOM element. You're doing so via,

working with straight ajax, which we'll talk about in a second. Yeah. Can I can I ask 1 question about that, that I'm curious? And you might be getting to this, but I'm I'm just kind of trying to visualize it in my head, like coming back to like the Wes have a page called Team Scott HTML. It renders out the header, The entire team and the footer and the sidebar. Right? If I remove 1 person from that, it goes to the server, re renders the entire page, And then it knows to just, like, take part of that page and swap it out? Or is there some way for HTMLX to talk to the server and say only rerender this part.

So there's some way for HTMLX to talk to the server and it's not rerendering. It's straight up just manipulating the DOM. Right? And I think that is like a thing. And it it all depends on how you do it. There's a way that you can do something called boost, which which is a little bit more automatic.

But the way that you're typically working in this thing, because I don't wanna get too deep into syntax, is you're saying, I have some JavaScript I have some HTML coming from the server, and HTMLX is telling Your application, where to insert that into the DOM.

So you have targets and things of that nature. Yeah. But your your server is still rerendering the entire page. Right? No. Not necessarily.

Okay. So you you can tell it, Like, you you can hook it up to your your server then and and say only rerender this partial?

Kind of. You're Okay.

I'll I'll tell you. You're you're you have full control over that. HTMLX does not determine that. So for instance, if I say Add a new to do.

My to do function on the server might add that to the database.

Then it's going to return from that that route, perhaps Wes a string that's a list item with your HTML in it. And then when HTMLX receives that response, it has just that bit of HTML. It doesn't have the whole DOM. It has just that little bit, and it puts it where you tell it to. Gotcha. Yeah. It makes sense. Yeah. So oftentimes, you're working with these responses that are just small chunks of HTML or big chunks of HTML.

It's not something that you can just swap out your UI for in a spot. This is not taking a React website and turning it into a Svelte website. This requires a bigger a bigger change on how your application is working overall. Again, we're not working with JSON there. So that's a a big part of it.

And one thing you'll see a lot is hypermedia, where basically HTML is king. We're sending HTML. We're swapping HTML.

And the JavaScript we're writing is client side JS unless, of course, we're doing that on the server side.

The big thing here is that it brings back Ajax, which is a term that many of you will remember in your Dreamweaver textbooks, AJAX, asynchronous JavaScript pnpm XML.

And, basically, the the whole thing about AJAX is what we've been talking about. It talks to the server and replaces a part of the UI without refreshing.

That's it.

JQuery had a, a function in that Wes would use quite a bit JS you could you could fetch a page and it would return The entire page, but then you jQuery would be able to just say, okay, I only want this one part of it, and then you could, like, use dot HTML function to to push all of the HTML of that response into the div.

It's kinda funny that we stopped using the term Ajax. Yeah. And next now it's all what? Like, what do we call it? XHR or, like, most people call it, like, a fetch, I guess. Yeah. And that's I think that's largely because what we're

sending and receiving is data rather than Rather than HTML. HTML. Right? That's really the crux of this entire thing. And so when you start to think about it, like, what can you do with that? Because if you're replacing parts of your UI, how much of application development is simply talking to the server and replacing parts of the UI.

When I got into it, kind of a lot kind of a lot of stuff, especially if you're sending a small amount of HTML from the server. Or maybe you're doing this all at the edge. Right? So it really takes a shift of, Do I need to be doing this in the client Node, or am I really just adding and subtracting divs here and there based on the server response? So what can it do? Hey. If you think about it, client side routing is really just that. You're taking a section of the page.

You're swapping out the contents of that page.

So while, people will get mad if you call it client side routing, because technically it's not client side routing. It really is, and it has the ability to do the same style of routing that you get Wes sections of your page don't change, but sections of your page do change. And this could be even nested into nested routes. I've been doing some really cool stuff with this. It also allows you to progressively enhance forms. Right? You submit a form. That form does your data. That data comes back in the form of HTML.

The HTML has somewhere to go.

Bingo bango. You have yourselves a progressively enhanced form that would work, maybe not in the UI without HTMLX, but it would submit the form correctly and do all those things like you'd want it to do.

So it offers a lot of progressive enhancement. But I think the big thing to think about here is it can do a lot more than you imagine it can do because so many of us have have had our our brains, modified by working purely in a client side context that we don't think about just how much of the stuff needs to be done client side, which I think that was the biggest shift for me Wes, does x, y, and z need to be done on ESLint side? Yeah. I don't maybe not. Most of the stuff requires like, the kind of stuff that does require, like, client side interactivity JS like mostly swapping CSS classes. Right? I mean, there's there's obviously more to this if you're getting into heavier ESLint side application. So Let's get into a little bit about what it doesn't do. It doesn't do any client side JavaScript really, as in interactivity bits, doesn't do it.

But, again, what do you really need a JavaScript framework to do? Swapping classes on on something to do? Maybe, like, what? You're toggling A hamburger menu. Right? You're just swapping classes.

Writing a slideshow, you can do that with CSS now.

I think HTMLX really powers through because of the enhancements to CSS lately.

The CSS is so much more capable than it's ever been before that we need client side JavaScript less and less. And this is Especially with popover too. Hey? With popover and dialogue and, anchor. All of these new APIs are going to make HTML so much more formidable that You really start to look at the web apps we're building.

What do you need client side JavaScript for? And then when you start to think about it that way, You really say, I'm shipping way too much JS for the amount of stuff I actually need client side JavaScript for. Makes sense. Like, I'll give another example,

of something like this JS GitHub if you have an issue on GitHub, and you want to like, GitHub is such a good example of, like, an application meets a website. You know? It's not like, oh, this is an app, and and this is a website. It's it's it's both. Right. Doing a lot. And if you're if you're on the the an issues page, like there's a lot that it's server render. Right? A list of all the The the issue with the all of the comments that go underneath it. However, there are some bits of those issues that need to be interactive, like, adding a emoji response.

And the way that that works is that when you when you click on Node of the emoji responses, it sends that request to the server, and then it just comes back with the, like, List of emojis in it as HTML and just swaps out that little part. Or if you add a comment, it Could just rerender the list of of comments behind it. So I thought that was a good example of Yeah. The difference. Yeah. I've been really examining

on websites that I use every day. Reddit Yeah.

GitHub.

And I look at these things and I say, which of these Client side interactions are not talking to the Vercel. And it's it's not a, you know, a ton of them because they're oftentimes, they're just hitting hitting the server and getting back a response. That response comes back as data. The UI knows how to handle that data.

You're just cutting out the middleman here and getting that HTML and putting it somewhere rather than having to jump through the whole loop of of working with data. I gotta say it's really compelling. Another thing HTMX itself does not do is it does not do the server side responses. So like I mentioned up top, you still need a server that's able to understand the requests, do something, and send back HTML.

I have been working on a framework, to do some of this stuff for me.

And one of the cool things this framework does is that it knows if it's an HTML request or not.

So if I choose to load the about us route, and it's an initial request that gives me the full Dom.

But if it's an HTML request, I know that's a client side navigation, and therefore, it just gives me the body of the about page, and it swaps Scott accordingly.

And that to me is really sick.

Works really super Wes. But you need a server to be able to do those things smartly. I wrote that code myself. I'm putting it into a framework, but, you know, that's something to consider. But what about These following things, animations, you do them with CSS or JS light or any JS lib that you want for animation. Screen sock, Sanity JS, whatever you want.

CSS. You bring your own solution. A lot of people really like Tailwind here because it is a nice way of encapsulating your CSS, doing scoped CSS to an individual component, but there's no limitations on how you write CSS here. I would like to do something using the scoped API and lightning CSS.

I've I've been exploring some things, to do that in my app that I'm working on. But Node there's no limitations on seasons. You could include your CSS with your JavaScript or with your HTML partials that you're sending along the wire. You can do that. It's cool.

Web components, they work just fine. Shadow dom does not work, but web components are cool for UI things here if you want to encapsulate UI logic.

Third party client side JS, HTMLX has some helpers like an on h t m HTMLX Node function that just calls when HTMLX is loaded, and then you can initialize a client side library if you need to.

WebSockets and server side events. Hey. HTMLX has an API for that, so you can work with real time data without writing that client side JavaScript to connect there, and I think that's pretty neat.

You can also extend the HTMLX. There's plugins. For instance, one thing that I had was, hey. When I want this change to happen, I want it to affect multiple sections of the DOM, not just one thing. Right? Because typically you're giving it a target.

So there's a multi Swap is an extension which allows you to swap things in multiple locations, which is great. And there's a whole host of other extensions, and logging and stuff like that. So it's a full featured thing. Can I ask,

a bit of a bomb question here? Bombing up.

How is HTMX different from React server components with server actions or Svelte with Form actions.

Oh, it's very different.

In a React context or a Svelte context, and you're sending information from the server to the client as HTML. Right? What then happens is that JavaScript Node, that JavaScript then kind of attaches to the existing DOM.

So that way, when you then update client side, all those updates

Then therefore, from that ESLint, happen via the client side. Right? I'm I'm just trying to, like, understand, like I I understand it, but, Like, what's the the benefit, over that type of thing? Like, yeah, it's it's less JavaScript, but it comes with all these, like, oh, but If you do wanna do some server JavaScript or you wanna do a drag and drop, then all of a sudden you're Totally.

You have components on the client and on On the thing, like, I understand it for a lot of applications.

Yeah. But

So I I think the one thing that you're swapping for In simplicity of execution, you're swapping that with simplicity of developer experience. Because with HTMX, You're having to use a bunch of different tools, to get the same kind of simple workflows that you're getting Scott of Svelte. Yeah. What you get in the output of HDMX is more simple. You're just swapping divs here and there. Right? And in Svelte world, so to say. You have to worry about the rendering system.

What Wes does the data go? The data comes in from JSON, Comes in from the server. I then have to worry about distributing that data throughout your application.

And that bit of JavaScript. And that bit of logic just goes away.

If an app is like React server components And Svelte, they're they're just sending HTML. I know it's the components, but you're not sending any data to the server if it's Server rendered. You're only Only on only on the initial load. Right? And then every subsequent load, you're dealing with data and hydration. React server components, though. React server components, you can keep it a 100% on the Vercel, and only when you want to Opt in to client JavaScript. That's when you do it. But React Vercel components

are sending virtual DOM.

They're sending React stuff. They're not sending HTML, and I do think that's an important distinction.

React wants to control everything. React is the apple of this format. Right? They they want to control the entirety of the the rendering cycle for your application.

And this is just so the whole lot. Straight for. With HD Max, you could you could write your back end in 8 different

things. You know? You could write Which is a strength in the curse of it, I think.

So I love that we hash that out because I think that's, like a really important conversation.

And and I do think I I don't wanna act like HTMLX is the the solution to everything because there's definitely things I like about it and I don't like about it. I'd like that you don't have to worry about client side components Vercel server side components. Basically, everything is a Server side component, the client side JavaScript you're doing is very obviously like client side JavaScript. It moves most of your logic to the server straight up. Almost all your logic moves to the server.

There's no sending data around. I don't have to grab my data, Send it across the the Internet and then distribute it through my application.

I have my data. I put it into the HTML.

I send the HTML. That to me feels nice in practice.

State lives on the server.

So again, your application state Lives mostly within, like, the request process on the server, and that's a a pro in my book. I think it makes working with state less messy.

Again, I'm not having to accept things and then distribute it via state or any of that stuff. I also like that you can use BUN in straight up TypeScript.

I I threw up to, a bun server with an HTMLX front end, quote unquote, and I'm writing TypeScript everywhere.

I'm feeling very nice about just the general workflow of not having a build tool in this regard.

Just writing a server sending HTML.

I don't have, like, a build process necessarily.

It's just very nice.

What does Scott not like about it? I don't like the occasional need for a client side. JS has a lot of people doing a bunch of different stuff.

You see people using Preact, React, Alpine, all sorts of stuff on top of HTMLX.

And to me, I don't think that's necessarily a pro. I'm gonna try to keep A bit vanilla, but who Node? You know, those are the types of things we'll see. But it I think another, like, thing I don't like about it is this sheer amount of variability in how people use this Tool makes finding relevant documentation.

Anything about it, difficult because you'll find influencer a being like, Hey. I used I use, like, Go and HTMLX JS the killer combo, and influencer b will say, oh, Bun and, JS, that's the killer combo.

And I think it's not mature enough in this space where there isn't like, Well, I I also think I think it's being used across communities, PHP and whatever.

It also requires a big brain shift, which isn't awful. But, if you've been writing client side JS apps for a long time, your brain's gonna hurt trying to understand that you're you're swapping out HTML all the time. I also feel like there probably will be rough edges Wes in certain situations I could have the framework bail me out with client side JavaScript.

And, also, a thing I don't like about it is their website only has a light Node. So that way, when I browse to it while we're recording this episode, I look like this, so I can't leave the docs open while we're recording.

So that's really it. I think there's plenty more that I do like about it than I don't like about it.

I think it's legit.

I think, I think people might have the wrong idea about what it is where you're thinking about JS this a true React replacement.

Requires a lot of buy in.

It does feel the most like working in PHP that I have ever felt on the web with JavaScript.

And I think the the one thing that thing. Right? Like, you're saying that in a positive manner? Yeah. Okay. I'm saying that in a positive manner because largely in the JS world, we've been kind of fighting for something that feels as streamlined as that. Right? Yeah. You grab your data, you throw in a template, that template just renders.

And this to me, Feels the closest to that given the tooling around it that you support yourself with.

And that's why I think people in Django, people in, you know, rails or wherever. People are liking the way this feels for that because of these reasons.

It's an area I'm going to continue to blower. So you might see some tutorials, you might see some more content. I'm sure we'll talk much more about HTMLX here in a practical sense. I just thought it was a good, Hey. What is this thing that you've been hearing so much about or you've been seeing memed online? Is it actually real? Are people using it? What do I need to know about it? Awesome. The, h g max.orgforward/examples

also has a bunch of, like, okay, but how would I do progress or or something like that. Some really good examples they're showing. Especially, I was I was curious how, like, the server sent events work Because, like, you think, oh, yeah. But my stuff's real time, you Node? Or like Yeah. Like, an example is I have my my video courses is Wes progress needs to happen, right, you can you can use server ESLint events to send that back and forth from the server just to update data.

Pretty cool. I remember I remember the pre JavaScript front end days when I first started working in backbone.

I remember thinking, Why does this, just simply loading this, have to be done in JavaScript? And it's almost like after using this, I'm like, wait a second. It only has to be done in JavaScript because the system's expecting me to do it in JavaScript.

Now if I free myself from those bounds, What do I really need client side JavaScript for in, like, an interactive sense? And I think in 2024, the answer is less than it was in 2015, right, or 2013.

Beautiful. I I like it. I, I'll have to give it a shot myself. I've been Kinda looking at it for years, ever ever since people keep, suggesting it. I I think the one thing that people are not going to like, and and you touched upon this, is that, like, People just want a opinionated meta framework, or just just tell me how to do it. You know? I wanna be able to tell me how to write my components, tell me where to put everything, me what the folder structure looks like. I don't wanna have to piece all these things together because we're certainly

burned out of that in JavaScript land. Well, let me tell you, I got something for you here.

I I've been cooking on a a meta framework. And then I'm gonna say this is 24 hours So, you know, by the time you listen to this episode, you know, who knows what the status of this project will be? But this thing rips, and I'm a tell you, I'll post a LinkedIn to it. I'm calling it hype right now. It has client side folder based routing. You have a routes directory. It works like Next. JS, and it uses HTMX, it uses BUN, it uses Elisa, and it uses Drizzle and SQLite to get you up and running. It is Are you are you using a very fun file system router? I'm using my own.

Okay. Because That's one really cool thing. I I know we're getting long here, but one cool thing about Bun is that it, like, has a file system router built in and JSX Built in. So, like, you you could go pretty far

Yeah. With, Bun. I I will say I will be using their APIs, but to do the file routing, yeah, I'm using Eliza as the the, server, the the express, if you will. And so I I need to do some stuff there. So I I will see if I can integrate their file system rather API with what I'm doing, in a way that makes sense. Cool. But right Node, I'm doing it all kind of bespoke. Beautiful. Alright. Thanks, everyone, for tuning in. We'll catch you later.

Peace.