Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
OK, good, so I think we agree I am using the term "hypermedia control" correctly then?
> None of them existed in the "basic idea of HTML".
Well, the form tag was introduced in HTML 2, which was in some ways the first "standard" for it, so relatively early in the game:
After the HTML and HTML+ drafts expired in early 1994, the IETF created an HTML Working Group. In 1995, this working group completed "HTML 2.0", the first HTML specification intended to be treated as a standard against which future implementations should be based.
But I can see what you mean and arguing over the meaning of "basic" isn't a hill I'm particularly interested in dying on.
> No, you're appropriating the definition, contorting it to pretend that it only means HTML as extended by HTMX, e.g. this
That's my definition of a Hypermedia-Driven Application, a term I made up to contrast with SPAs. I agree with you that a hypermedia can be imposed on top of JSON, which does not have native hypermedia controls, but I hope you can agree that this is not the way it is typically used today, and I also hope that most readers would understand that. I think the level of detail is appropriate for a high-level introduction to a concept that I created, but I see your point.
XML is another example of something that is not a natural hypermedia, but I included https://hyperview.org in the https://hypermedia.systems book, so I hope that demonstrates that I'm not wedded to the idea of HTML being the only hypermedia in the world.
I also agree entirely that a proper hypermedia client is crucial for a properly functioning hypermedia system:
https://htmx.org/essays/hypermedia-clients/
> I'm just getting tired of people hijacking specific terms to suit their own narrow definitions (however many hoops they have to jump through to get there), and present these narrow contorted definitions as the only true way.
I don't know, I think we agree I am using the term "hypermedia controls" properly, and I don't know if you have different feelings around my idea of generalizing them in HTML, given that fact. Does that change anything for you?
I certainly don't feel htmx is the only true way. I have never said that, and I try to be explicit when the hypermedia-based approach will be effective and when it won't here:
https://htmx.org/essays/when-to-use-hypermedia/
https://primatejs.com has supported htmx from day one.
https://react.dev/
https://medium.com/@Angie.O/why-react-is-a-library-and-not-a...
https://www.oreilly.com/library/view/what-react-is/978149199...
Hypermedia based web applications are a great fit for developing internal and operational tools. I have been building https://github.com/claceio/clace for making development and deployment easier for such web apps.
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
to target a section of the page that isn't an has been argued about and hashed out for years.<p>Why is that? Well, for example, here's the form you have to fill out to start standardizing a front-end feature. <a href="https://github.com/whatwg/html/issues/new?assignees=&labels=addition%2Fproposal%2Cneeds+implementer+interest&projects=&template=1-new-feature.yml">https://github.com/whatwg/html/issues/new?assignees=&labels=...</a><p>It asks three main questions:<p>* What problem are you trying to solve?
htmx 2.0 will be 99% compatible w/ htmx 1.0, and we'll provide a backwards compatibility extension:
https://github.com/bigskysoftware/htmx/blob/v2.0v2.0/www/con...
we will also continue to support htmx 1.0 for the forseeable future for people who need IE support or don't want to upgrade
There are underpowered languages / tools, that can only solve a problem for which they are intended poorly. But not all limited tools are like that.
Say, eBPF is prominently not Turing-complete, which allows to guarantee that a eBPF program terminates, and even how soon. Still eBPF is hugely useful in its area.
Or, say, regular expressions are limited to regular languages; in particular, they famously [1] cannot process recursive structures, like trees. Still tools like grep / ag / rg are mightily useful.
Yes, I agree that YAML is underpowered for proper k8s configuration! But it's also too powerful for its own good in other aspects [2]. I wish Google used Dhall [3] or their own purely functional config language (FCL? I already forgot the name) instead of YAML; sadly, they did not.
[1]: https://stackoverflow.com/a/1732454/223424
[2]: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...
[3]: https://dhall-lang.org/