Hacker News new | ask | show | jobs
by dfabulich 894 days ago
I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML.

In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get <form> to target a section of the page that isn't an <iframe> has been argued about and hashed out for years.

Why is that? Well, for example, here's the form you have to fill out to start standardizing a front-end feature. https://github.com/whatwg/html/issues/new?assignees=&labels=...

It asks three main questions:

* What problem are you trying to solve?

* What solutions exist today?

* How would you solve it?

The goal of these questions is to focus primarily on the problem, and only secondarily on the solution.

For comparison, generally standards folks think we don't want to add programming-language features to HTML, e.g. adding <if> <while> and <set-variable> elements. If you want that sort of thing, you want a full programming language; you want JavaScript, actually.

So, when people propose features that don't perfectly address their problem, we want to ask: what do you want that for? How could we solve those problems better?

HTMX doesn't have really great answers to the "what problem?" question. Look at the home page:

* Why should only <a> and <form> be able to make HTTP requests?

* Why should only click & submit events trigger them?

* Why should only GET & POST methods be available?

* Why should you only be able to replace the entire screen?

Those questions are all solution-oriented, not problem-oriented.

Instead, let's look at the examples. https://htmx.org/examples/

Each of those examples are important problems that HTMX can solve. But it doesn't solve them very well from the perspective of screen-reader accessibility.

For example, there's a bunch of stuff there around managing editable data tables (click to edit, bulk update, click to load rows, delete row, edit row). But none of them work well with screen readers. How would a screen reader describe updates to these data tables? (Go on and try those examples in a screen reader, e.g. iOS VoiceOver. It's not great.)

Of course, editable data tables are a very widely requested HTML feature; it seems quite likely that a feature like that will be added to HTML. When it is, a screen reader will announce the feature as a data table, describing it to the user clearly, including live updates.

Some of the HTMX examples already have recent new HTML features that support them directly, like <dialog>, declarative form validation, using <details> as an accordion (which you can use to support tabs).

In the future, I expect to see HTML features landing like these:

* Editable data tables

* Infinite scroll / lazy loading

* Combobox

* Skeleton UI / Loading

If/when those features get done, it's not totally clear which problems remain that would be a good fit for HTMX's approach to declarative AJAX. Like adding <if> <while> or <set-variable> elements, the problems it solves seem to all have better solutions at a different level.

And yet, we'll probably be waiting 5-10 years for those features to be standardized, at a minimum. So it's a bummer that HTMX probably won't be standardized any time soon, and that the standards committee has consistently let the "best" solution become the enemy of a "good enough" solution.

But, that's what happened, and I expect it to continue to happen, so I wouldn't hold your breath for HTMX standardization. (If you'd been holding your breath ten years ago, you'd be long dead now.)

3 comments

> I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML.

I don't think the point is for HTMX to get standardised, but rather for HTMX to drive conversation and evolutions in the spec.

After all jQuery did not get standardised. Rather the issues solved by subsets of jquery were looked at, and considered for solving in the standard.

HTMX breaks the "separation of concerns" paradigm. It's not going to help anyone doing anything complex, and it's going to be a crutch for anyone getting started. It breaks down quickly when the problem is anything more complex than clicking a button to load some content, and then what - rewrite everything in a more capable framework?
That's like preventing HTML5 to include a native date picker. Because if you want anything more complex than a basic date picker, then what? Rewrite everything in JavaScript?

Simple answer: yes.

> Those questions are all solution-oriented, not problem-oriented.

I think the problem is at it's core, "how do I add rich interactivity and dynamism to an HTML document without scripting?"

A general event-driven document model where document events can automatically issue server requests whose replies then trigger more document events and/or updates makes sense. htmx is one way to do this, but probably not the only or best way, but it has the core idea right: generalize hypermedia and extend the event model.