Hacker News Reader

Comment by t8sr | Hacker News Reader

I'm confused about what value this adds. The introductory example is certainly not helpful, as it takes an `<a href="/blog">Blog</a>` and turns into 7 lines of markup to accomplish the same thing. (And then it says a bunch of things that are arguably not desirable, like "any element can now trigger requests".)

Like: what's the point of using this over HTML5+js? I've spent 15 minutes reading the website and I still don't understand why I should want this, especially if I already know HTML/CSS/JS. All it seems to do is add a SGML DSL into your HTML, so you can be all declarative about `onclick` attributes.

I am sure I'm missing something - what is it?

View on HN

The great thing about HTMX is it fits really nicely with templated server-rendered frameworks like Django.

You can have a page with a list of items. The page is one template, and it includes a sub-template which is just the <li> items. Then you have a separate view for "get list fragment" which just returns the updated/sorted/filtered <li>, rendered with that same sub-template. If you toggle the ordering, or filter the list, HTMX will automatically call the fragment renderer and replace just the <li> items, without reloading the page.

See this example: https://github.com/adamchainz/django-htmx/blob/8054f049f53f0...

This approach solves the common interactivity use-cases requiring JS in a server-rendered app, without having to write any JS, and without having to build a REST API. Instead you just render HTML, which your framework is excellent at.

But you can already do that. I was doing it in the 90s, Ruby on Rails supports it, etc. Just send the HTML if you want to and call `el.innerHTML = response.body`.

The false dichotomy here is that it's either htmx or React. Why not... neither?

yep, htmx isn't that complicated

but it does support history, collecting parameters from the DOM, an extensive event model and extension model, targeting other elements, listening for events in sophisticated ways, coordinating multiple elements that are making requests, etc.

so there's some additional stuff in there that makes building a proper hypermedia-driven application easier

I ask similar questions about React ecosystem for years and the most frequent answer is “you’ll know when you need it”. Made few dashboards, smartphone-servers control panel with live streams, svg-heavy fully interactive cashflow graph builder for inhouse accounting, a bunch of typical “react” sites (literally because “frontend dev is slow and we need something right now, they’ll catch up later”, how does that sound) and still waiting for that enlightenment to come.

People throw bs under their feet and then learn how to avoid stepping into it too much. It’s insane. I think that htmx, despite clearly being a breath of fresh air for them, is in the same category: it does all you that could just_do already, but looks nice.

Also an old head here - so glad I'm seeing you write this, I was beginning to wonder myself!

Consider the case of calling your backend with a POST call and then updating your app in response.

Typically, for a SPA: your backend would return some data, and your frontend would then figure out how to update your html in response to it.

For a multi-page-app: your backend will redirect the user to a whole new page with new HTML.

This is somewhere in between: Your backend will send just a little bit of HTML and you can update your existing HTML with it. It should feel like coding an MPA, but get the benefits of an SPA.

Yeah, that I understand. I am not a huge fan of sending JSON that's not backwards compatible. Sending HTML is probably a good choice for some applications, but that was already well supported 20 years ago. Why is htmx better than one line of javascript saying `onload = function() { e.innerHTML = response.body` } ?

Please see my answer above, but htmx has some swap attributes where you can declaratively update as many elements of the page as you want. You can grep this id and find all the updates easily.

In practice you don't want to just swap the content 100% of the time. Appending to the current content is quite common too, as is deleting from it. You sometimes need to touch other elements too, or maybe show a progress spinner. Or perhaps push a URL to the navigation history.

Htmx provides a batteries-included data-driven experience. It is a means to avoid having to write dozens of slightly different variants of the same 5-10 lines of Javascript.

But all of those things are trivial. Are we going to next get a library that lets you declaratively specify string operations and integer multiplication? Why not write a dozen variants of 5-10 lines of readable Javascript? What's the problem? It's maintainable, fast and every other developer will immediately understand it.

Look at each of the distinct things that htmx lets you do, and tell me what would be required to do it in vanilla JavaScript. Notwithstanding that even in your example `onload = function() { e.innerHTML = response.body` } [sic{ doesn’t even tell the whole story, HTMX does more than just this and this is blindingly obvious from its documentation. If you need those things more than, say, a couple of times in your project, the natural thing to do is to factor them out to what essentially becomes a framework. This is what that is. HTML element attributes is used as the interface because there are a whole lot of people that don’t like switching to writing JavaScript. You can argue all you like that you’re not a fan of this, but plenty of people are. You can also argue all you like that one will eventually need to write some JS which will make the whole thing confusing to follow. The reality is that there are a whole load of projects where this isn’t the case. If you’ve spent this long going back and forth with people about the merits of this project, and still don’t see it’s value, then it legitimately isn’t addressing a problem you have, or, more likely, it isn’t to your personal style/taste, or for whatever reason you are unable to relate it to any personal circumstances you’ve ever been in. The documentation gives tonnes of practical examples of how the framework can be useful, and there’s mountains of third party examples. Beyond that, your arguments seem to revolve around a lot of technical, performance, and DX hypotheticals that you could test yourself by experimenting with the project. Part of its selling point after all is the lack of a need for complex build tooling. If you still legitimately can’t see the value then it doesn’t seem worth the discussion.

The reality is that there are a whole load of projects where this isn’t the case

The reality also is you don’t know that until the project is archived. Their questions and doubts are valid, why not just say “yeah, it’s just a nice looking sugar for that with manageable caveats”.

I can see how reiterating on what can be done with it as if that couldn’t be done with AJAX in the same amount of code could make discussion a little confusing.

One of the stated goals is to make html a true hypermedia language right? That's really pretty much it.

A lot of these objections sound like "why bring these functions into JavaScript if JQuery already exists? Why do we need CSS Grid if bootstrap already exists?" Because those are arguably add-ons meant to deal with the deficiencies of the original technology. Fixing that technology is a better place to be.

Except that it doesn’t fix the technology, it gives the appearance of augmentation via a bunch of JavaScript. Seems more like the jQuery and Bootstrap of your examples.

Sure, you don’t have to look at it, you just program against the interface. Just like you don’t have to look at the internals of jQuery - you just program against its interface.

Hmm so like how Wicket Ajax works, but as something you can bolt on to any framework? That's cool, although I'm not sure how well it would work if the framework isn't component-oriented in the first place.

It's just a JS library that attaches behavior to HTML elements based on attributes where you'd otherwise have to write a bunch of JS yourself. It's just a framework where all the metadata is just embedded in the HTML.

Yeah, but why? Why is it better to remember a bunch of attributes than to remember 3-4 javascript functions?

While I am just now discovering it so have not used it, I personally love this approach because it keeps the HTML syntax. It is like programming in two different languages when you only need one. Normally, you would add an onclick event handler to the element to call a function. Then, you scroll up to the function and back down to the anchor. Back up to the function. Back down to the anchor. This puts everything in one place with cleaner syntax.

It's pretty clear that TFA means that this is better because that's how HTML should have been, in their opinion.

Is it better? Well, I think so. Practically speaking, for example, if you use NoScript or something like that, it kind of would be if you could block scripts but not HTMX. Also practically speaking the cognitive load of HTMX should be lower than the cognitive load of JS (especially for beginners). More generally speaking, I think it's quite right to say that HTML should have had a lot more of this early on, but the pressure for HTML to evolve clearly dropped once JS came along since JS provided a way to work around the limitations of HTML.

IMO it is a good idea to standardize a bunch of behaviors as HTML attributes for these reasons.

But if you disable JavaScript, then htmx won't work either, right?

And how is it lower cognitive load? You have to learn JavaScript, but now you also have to learn htmx. I don't call that a win. Code is read by a lot more people than wrote it. It's not great if you constantly have to be learning some flavor-of-the-week framework. (No problem learning new things where it's warranted, but this isn't even interesting, it's just a DSL.)

> But if you disable JavaScript, then htmx won't work either, right?

It would work if either HTMX became standardized and implemented by the browser, or if I could allow HTMX (the JS) and not other scripts [selectively].

See… that would be interesting and useful. But it’s not what’s on the table here.

It's called baby steps. Implement the HTML extensions you want using JS, then get them standardized. You could do it w/o the PoC first, but then it might be harder to get the mindshare and traction you need to get the W3C to go with it.

Even if the W3C rejects this, it would still be useful for many who want to write declarative scripts rather than actual JS.

Why does CSS exist anyways? Because it's a declarative language, and declarative languages are clearly better for certain tasks. HTML itself is declarative.

https://htmx.org/examples

I've looked at a few of those and I still don't understand. Also, hilariously, several of them are already broken. (Like the table one that's not updating.)

EDIT: Sorry, nevermind. The Bulk Edit example does work, I think it either does not like Safari, or something failed to load before, but it works in Chrome.

which table one? all of them seem to work for me.

no problem

if you can, try to give the idea some time: it's a bit different than other approaches, but it's at least an interesting alternative to other front end libraries, even if it isn't right for everything

Replying to myself: I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON. I can see the benefit of doing that, although I have a bone to pick with the condemnation of all data APIs because JSON is awful. Protocol buffers, for example, are trivially forward and backward compatible and mostly self-describing.

Also if you build stuff on top of hypermedia APIs then bye bye performance. It's probably fine for web pages, because you're competing with JS+JSON/REST frameworks that are written by people who have never heard the term "L2 cache", but I strongly suspect the right move is to drop the framework completely, not replace it with a new flavour-of-the-week thing.

Just write HTML5. It's fine. Add javascript for the 2-3 bits of interactivity you actually need. If you hate JSON, use protobufs. Your web page will work forever, because it'll sit on the actual API provided by the browser, and it won't make my laptop overheat when I load your site.

You can use the swap data attribute to update several fragments (imagine a saved icon) in several places declaratively.Then you can get rid of almost all your js code.

The price to pay for this is it does not work offline. For quickly prototyping and app it is very fast.

> You can use the swap data attribute to update several fragments (imagine a saved icon) in several places declaratively.

Yeah, but why? The javascript snippet to accomplish the same is absolutely trivial and avoids a dependency.

> The price to pay for this is it does not work offline. For quickly prototyping and app it is very fast.

The true price is that you've now rewritten your HTML code in a non-standard DSL and are forever dependent on a third party library, and all that to accomplish a goal that seems entirely aesthetic to me.

> absolutely trivial and avoids a dependency.

I disagree with this other than in a simple example. Updating something that depends on sth is far from trivial. It looks trivial.

> The true price is that you've now rewritten your HTML code in a non-standard DSL and are forever dependent on a third party library

So, like React. Prob also a build and scaffolding tool, and a linter were added in that case.

Regarding arsthetic I actually find htmx kind of ugly but it works so well I cannot ignore it. It simplifies everything a lot, but I am just discussing here.

> So, like React.

heh, that's exactly what went through my head when I read the other posters comment, how is that different from the current SPA frameworks?

> Also if you build stuff on top of hypermedia APIs then bye bye performance.

This is not obvious to me.

This idea used to be called microformats. The premise was that you send an HTML snippet, and all the semantic attributes plus a protocol definition will let you parse it as either data or a part of the UX. It's self-documenting in the sense that, if you do it right, the snippet has clear semantic meaning.

However, it's not backward and forward compatible as either UI or data, because that was never an explicit goal of HTML. It's also much slower to process because:

1) Network IO is CPU intensive, so sending more data is worse

2) HTML is not optimized for data interchange. Parsing a protobuf is probably at least 10x faster than parsing the same data out of an HTML microformat.

Um, 'parsing...data out of an HTML microformat' sounds like a fancy way and obscure way of saying 'the browser renders HTML, something it has been optimized to the gills for'.

> Parsing a protobuf is probably at least 10x faster

Faster than a browser rendering HTML? That would be quite a feat.

Yes, I am implicitly assuming that eventually someone will connect to it as an API, not just to directly render the HTML but to machine-process it.

> I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON

HTTP is named Hypertext Transfer Protocol after all. Exchanging schema-less JSONs is conceptually pretty lame. It's plain old RPC architecture. That's why we end up needing to write API docs to line up the frontend and backend, or otherwise inspect backend code to figure out what's being handed over.

Browsers are built to understand HTML. Whereas in the modern world we largely ignore that and write double the code we'd have to write otherwise passing arbitrary messages and it introduces a whole new set of problems making sure those codebases line up properly. Whereas HTML produced by the backend (properly) contains all the information someone could need.

This hits the nail on the head so hard that reading it feels like waking up from a bad dream.

> Browsers are built to understand HTML. Whereas in the modern world we largely ignore that and write double the code we'd have to write otherwise passing arbitrary messages and it introduces a whole new set of problems making sure those codebases line up properly.

This belongs in a manifesto. Put it on a shirt and I'll gladly wear it

yep, perfect example is the history API. People created the problem that the history API fixes by doing things they shouldn't have been doing in the first place.

You see it all the time in software dev.

This answer is exactly correct. You must really think about how this dramatically makes developing these types of applications simpler by a magnitude. You are literally killing significant complexity that causes time, effort, and bugs. And, no, this is not merely shifting the problems back to the server-side. This is how HTML should have evolved in the first place.

This is the philosophy I had when I coded Zedtopia.

Clean Html5 and css3 should achieve everything. Only use JS for specific interactivity.

> Just write HTML5. It's fine. Add javascript for the 2-3 bits of interactivity you actually need.

Why write any JS at all if you don't have to? Htmx extends HTML to replace the need for a lot of the JS that's out there. It gives you client/server interaction and dynamic page behaviours without a single line of code.

Sure you can do without it. You could always do it all in vanilla JS or jQuery, at the cost of debugging it yourself.

this lib can offer tremendous taste for those looking for an html soup recipe.

Reply on news.ycombinator.com