Arguments Against HTMX

[00:00:00]
>> All right, so before we go on though, let's go over a couple common arguments you will hear against HTMX. Aren't servers supposed to respond with JSON? What if I need a different view? Why would my server ever want to understand the representation of the client? Well, even before I go to part one, your server does understand the representation of your client because it is responding with JSON, it already has some understanding of how you are communicating between the two.

[00:00:23]
You've agreed upon names of keys, you've agreed upon types of values, you've already made a lot of agreements that are implicitly there. Second, you can use accept headers. I accept HTML or I accept JSON, and your server can be the one that has all the smarts to say, this is a request for data in the format of JSON, here is the JSON view of the same data.

[00:00:43]
You are requesting HTML, here's the HTML view for that same data. So, don't sleep on headers, headers have a lot of control. A second important thing about state, right now the current approach is this, the server knows the state and produces a view into it, JSON being the most popular transfer.

[00:01:01]
The view is then transferred across the turtles after being created into a set of zeros and ones. The client decodes those zeros and ones and turns it into some sort of object or representation it can understand, usually JSON pars. It then reconciles the JavaScript state, and then it produces HTML from that reconciliation to be updated somewhere within the application.

[00:01:21]
So, I mean, there's a lot of things that can go wrong there. HTMX is more that your server produces a view, HTML. The view is transferred across the turtles via some sort of encoding. Usually strings are already ones and zeros, so it's pretty easy to do. The view is then decoded and turned into HTML and placed according to the rules on the originating element or the server overrides.

[00:01:40]
I said this is a slight lie, that's because I just mentioned right now, the server can override a couple things, all right, you get that. Isn't producing HTML slow? No, it's not slow. What is slower? Crawling an object in which you are discovering all the keys, concating all the strings, going through every single value and slowly crawling everything, or is just doing string interpolation with rope strings slower, faster.

[00:02:04]
I don't think you're going to see, if anything, I think you'll see probably a better performance with HTML than you will with Jason. I can't 100% confirm this, it's just that I've never tested everything fully myself, but at the end of the day, producing JSON is not fast.

[00:02:19]
There was an Intel paper in 2012 or 13 that claimed that over 60% of all server time is spent copying data, and that is it. And if you think about what JSON does, it is literally the ultimate copying of data from one format into another format. All right, seems like HTMX is for back-end divs, no serious UI/UX engineer would use HTMX, right?

[00:02:43]
I mean, I made a nice little pretty application with it. I mean, there is no indication into whether the client is interactive or not interactive with JavaScript. There is no indication into how much styles you do or don't use, it's up to the person who implements it. So, can someone use it?

[00:03:03]
Absolutely, do you have to use it? You don't have to, you can write a web 1.0 styled website if you want to, or you can make it really pretty. Just don't go web three, once you go web three, if you've jumped the shark, now you have a whole different website you're creating.

[00:03:16]
And so one more time, just in case you forget, if we make this element, HTMX will bind an onclick handler because the default action is a click. We can override what the action is, but the default is an onclick handler on the div. When the div gets clicked, it sends a get request to some resource.

[00:03:31]
When the server responds, the contents of the div will be swapped out with whatever the server responds with. With HTMX, aren't you going against your own advice, making statements about performance without testing? With the HTML production, that's why I said I don't know. I just know that adding strings together in a rope data structure is exceedingly cheap.

[00:03:52]
Crawling an object and all of its properties in a dynamic or reflection-based way is expensive. That's just long standing intuition, probably plays a pretty good role here. I would still test it though, I would always test it. Never just assume you're right on how things are performance, based because almost always you're wrong.

[00:04:13]
Typically, your gut dev or your gut feel is usually wrong when it comes to performance. Just always test, always measure, very simple. What Node.js templating engine do you recommend? I am not really a big fan of Node.js for server stuff. If I were to use one, I have no strong feelings.

[00:04:35]
I mean, there's plenty of little templating libraries I've played around with, they've all been fun. I've in general not enjoyed using React like or JSX. I should probably say JSX styled templating. I find that I tend to over complicate it with a bunch of logic piece I can.

[00:04:52]
Once you have that available path, I tend to take that available path, and then I find that I'm very upset about JSX. So, it's not a React problem, it's definitely a JSX problem. Yeah, people really like a Bun, Elysian and HTMX and React and Turso, right? The BETH stack, right, that's Bun, Elysian, Turso and HTMX.

[00:05:13]
People really like that stack, that's by Ethan. A super cool stack. How is HTMX lighter on resources than React? So, now we're talking about dynamic fetching of data and all that stuff, I would love to talk about that. I think DAX, if you know who DAX is, and I will be having a podcast on this.

[00:05:31]
I've spent a lot of time thinking about JavaScript data fetching and how to do it optimally, how to have components to find their own data that they need, and to be able to aggregate that into something that can like batch and dedupe requests. Request duplication is very, very difficult to do.

[00:05:48]
We have a full working thing that we used to have at Netflix and we're moving over to a GraphQL. But it's a very complicated process and it's 100% not a soft process, and I don't think it is actually a soft process. I would like to talk about that more, but I think that it's gonna be a different thing, because that's a whole realm onto itself.