This article started out interesting and then there were a series of baffling claims that... didn't quite make sense to me and feels like they are just trying to set up a straw man.
1. The author complains that React devs don't understand addEventListener when it is used and required reasonably often as far as I have seen?
Also, "Again: the web had this. The browser’s event system is fast, flexible, and well-understood. But it wasn’t controlled enough for the FP ideal of a closed system."
The stated purpose of the synthetic event system was to normalize differences in browser behavior back when React was created. It's not as necessary these days because browsers have gotten better, but saying it's about "FP Idealism" seems off.
2. The author complains about re-inventing the <dialog> element. This is valid, and new code should obviously use it. That said, it only became available across all major browsers in March of 2022, and still isn't supported by some minor browsers.
All of the popular component libraries were made before that, and thus ought to keep their JS implementation for backwards compat.
As far as tutorials, when I search "React dialog tutorial" the first result regrettably does show how to build your own, but the next two focus on using the built in element.
3. Then the author turns to customized select, and complains that JS frameworks don't support them. This would be valid but the very MDN article they link literally starts with:
> This article explains how to create fully-customized <select> elements using *experimental browser features*
> That said, it only because available across all major browsers in March of 2022, and still isn't supported by some minor browsers.
`<dialog>` only got full compatibility with Firefox about two months ago with Firefox 141. Safari still doesn't support `closedby`.
Given that, I still regard `<dialog>` as experimental, and that'll remain the case as long as the "Baseline Widely available" label comes with an asterisk.
> That said, it only became available across all major browsers in March of 2022, and still isn't supported by some minor browsers.
And the only reason it suddenly reappeared in 2022 was because browsers want to get rid of alert/prompt dialogs.
The spec was (and probably still is) so riddled with issues that it never went anywhere for 10 or so years, and Chrome at one point argued it should be removed.
> This would be valid but the very MDN article they link literally starts with
People involved with HTMX play really fast and lose with anything that doesn't fit their conclusions hoping no one will call them out.
Do other libraries talk as much about when they are and when they aren't appropriate to use? Do they link to alternatives? Do they link to bad experiences with their own software?
Edit Even the links to "When you should use hypermedia" and "Alternatives" you provided literally work backwards from that predefined conclusion, and there's no time in the world to go through each of them to dissect them, but the post I linked to should provide enough context
"HTML is the only true hypermedia" would be a funny conclusion for me to come to when i included another hypermedia, hyperview, in the book that I wrote on hypermedia:
EDIT: did you take this statement on twitter seriously: "yes, I believe HTML is the Only True Hypermvedia"? I was being sarcastic (making the same point I made above) so maybe this is a language issue? I'll read your blog and respond in a bit...
I think that a large part of the disagreement we seem to have is language related. I do NOT believe that HTML is the only hypertext: my inclusion of HXML as a mobile hypermedia format confirms that I do not believe this. In the tweet linked in your essay I am being sarcastic and pointing out HXML as the counter argument to it, I apologize if that was not clear to you.
Your essay is, as you say, meandering & at times incoherent, so I will try to clarify and address specific issues in it as best I can.
You mention that clients can interpret non-hypermedia files (such as Java classes) contextually and provide actions related to the content. This is of course true and I don't disagree with it. I do NOT believe that a hypermedia system is defined solely due to a hypermedia format (and, again, I do not believe that HTML is the only hypermedia format). Markdown, for example, is a (limited) hypermedia format imposed on top of plain text. When combined with a client that understand Markdown it forms a hypermedia system.
> If your custom non-standard XML DSL is hypermedia, then everything is
This section is very difficult to parse. I did not create HXML, however I do think it qualifies as a hypermedia format due to the presence of hypermedia controls. And I agree that the hypermedia client for HXML is just as important as the format itself in creating a mobile hypermedia system.
I also want to stress that I think you can impose a hypermedia format on top of JSON. You offer some examples and another one I'm familiar with is Siren (https://github.com/kevinswiber/siren). This is analogous to how HTML imposes a hypermedia format on top of SGML, or HXML imposes a hypermedia format on top of XML. As you rightly note, that isn't enough however: you also need a hypermedia client that understands that format and can present non-linear actions to a user.
You seem very focused on the idea that I think only HTML is a hypertext. I want to stress again that do not believe this to be the case, that appears to be a language misunderstanding.
Finally, we have this:
> Hypermedia, as Roy Fielding himself says, is the property of a machine talking to another machine using a media type both understand. The media type aka format itself doesn't matter as long as both machines understand it. Even presentation of controls to the user is a secondary concern and can be performed by the machine as it sees fit. Because, once you've unwrapped the contortionist back into their human shape, hypermedia is a property of the client.
This conclusion is contradictory.
"A machine talking to another machine using a media type both understand" makes the effective use of hypermedia a property of both the client and the server (both machines).
I agree strongly with that conclusion, drawn directly from your own words, which is why I titled my book Hypermedia Systems rather than, say, "HTML is the only hypermedia format".
I can see from a new developer point of view, their frustration. Why aren’t things standard? Why not use builtin tags? Why this or that?
Valid questions we should all be asking. Sometimes, just because “that’s the way it was” doesn’t mean that’s the way it should be. Often times I find myself deleting code that is now more readily available as either part of the platform I’m on or part of the framework I’m using.
Your points are valid too, that they don’t know about the history that got us here and why it is the way it is but nevertheless we should all be asking ourselves daily, “do we still need this?” and trim the fat.
That's not what the article was about though. It wasn't only a complaint about not using built in niceties of the platform. It was an assertion that the reason we aren't is because of some kind of functional bro boogeyman.
It only became obvious at the end that the whole (WAY too long) article was just a giant troll to promote the author's personal pet technology (HTMLX). But it was a highly disingenuous one, because (as the poster above noted) it was giant straw man, not a legit critique.
I felt cheated just by having read the article: I'm all for a long and winding article that has something to say, but this one was telling a bad joke for WAY, WAY too many paragraphs.
The article does not go into the disadvantages of server-side rendering (or more specifically, fetching html from server). I am sure the author is well aware of the choice between client- and server-side rendering but skipped it and seems to present technology like htmlx as “solutions" to all the problems the article mentioned which is quite a stretch.
1. The author complains that React devs don't understand addEventListener when it is used and required reasonably often as far as I have seen?
Also, "Again: the web had this. The browser’s event system is fast, flexible, and well-understood. But it wasn’t controlled enough for the FP ideal of a closed system."
The stated purpose of the synthetic event system was to normalize differences in browser behavior back when React was created. It's not as necessary these days because browsers have gotten better, but saying it's about "FP Idealism" seems off.
2. The author complains about re-inventing the <dialog> element. This is valid, and new code should obviously use it. That said, it only became available across all major browsers in March of 2022, and still isn't supported by some minor browsers.
All of the popular component libraries were made before that, and thus ought to keep their JS implementation for backwards compat.
As far as tutorials, when I search "React dialog tutorial" the first result regrettably does show how to build your own, but the next two focus on using the built in element.
3. Then the author turns to customized select, and complains that JS frameworks don't support them. This would be valid but the very MDN article they link literally starts with:
> This article explains how to create fully-customized <select> elements using *experimental browser features*
(emphasis mine)