I understand the appeal of what they are laying out here. I'm just wondering why the htmx approach has more benefits over the HATEOAS approach of something like API Platform that I linked to, which doesn't have any opinion on something being an MPA, SPA, or something in between
Also to clarify: I mean proprietary as in proprietary to htmx, this is a poor word choice on my part, no different to how Vue has its Single File Components which are "proprietary" to Vue. I'm specifically trying to understand the advantage of something that ties your APIs to markup rather than using an interchange format such as JSON, as such when building scalable systems it not uncommon to need some form of interchange functionality. Even at a smallish company I work for we need to make sure it is digestible on web, and mobile applications.
I'm just trying to apply some intellectual rigor to the model, as something I do think about is scaling, not say, Instagram Scale, even just something like a company with a 100+ million ARR may bubble these concerns
We can easily create endpoints that will respond with JSONs for mobile apps and with partial HTML for our hypermedia-driven application. The code is the same, just in the end check headers and render a template if we need to.
My understanding is that HTMX is based on the HATEOAS approach: https://htmx.org/essays/hateoas/
About API Platform you linked to, the homepage is not very clear (full of buzzwords but little info) but it appears to be a Backend+Frontend framework/distro based on PHP+JavaScript. Compared to that, HTMX is an HTML extension (just additional fields in the markup) which any backend/frontend can implement: even web browsers which don't have a JS runtime could implement HTMX and that's pretty cool.
> I mean proprietary as in proprietary to htmx
I believe HTMX is free software and i don't see a reason the specification can't be implemented by other projects. It's therefore not proprietary in my definition of the word.
> something that ties your APIs to markup rather than using an interchange format such as JSON
HTML/XML isn't that different from JSON. Just like your markup can evolve with your data structures and use-cases, so can your JSON. If you want interoperability, you should probably be using XML/JSON schemas and API versioning.
With something like htmx + hyperscript, the logic is tied to the components that are actually using them.
I am trying to popularize the term "Locality of Behavior" (LoB) to describe this property in software: