Hacker News Reader

Comment by benatkin | Hacker News Reader

It doesn't feel like hypermedia to me. It just feels like a vue-like language that is an internal DSL for HTML instead of an external DSL for HTML like svelte and handlebars.

Hypermedia advances would be microformats and RDF and the like. http://microformats.org/wiki/faqs-for-rdf

View on HN

it absolutely is hypermedia

we generalize HTML's hypermedia controls in the following way:

- any HTML element can become a hypermedia control

- any event can drive a hypermedia interaction

- any element can be the target of a hypermedia interaction (transclusion, a concept in hypermedia not implemented by HTML)

all server interactions are done in terms of hypermedia, just like w/links and forms

it also makes PUT, PATCH and DELETE available, which allows HTML to take advantage of the full range of HTTP actions

htmx is a completion of HTML as a hypermedia, this is its design goal

Links and forms are the bread and butter of many frameworks.

Like with HTMX, SvelteKit and Remix forms won't function properly without the framework.

if you read the article, you will see that you can use htmx as progressive enhancement quite easily since it is consonant with the vanilla HTML approach.

what makes htmx a hypermedia framework is the exchange of hypermedia with the server, this satisfies the hypermedia constraint (HATEOAS) of REST. there are other libraries that are also hypermedia oriented, such as unpoly.

it is a different approach to building web applications than the JSON/RPC style that is popular today

i encourage you to read the linked article, and, if it is interesting to you, the essays at https://htmx.org/essays, and then potentially https://hypermedia.systems

I don't really see how progressive enhancement works if every element is a hypermedia control. Without JS/HTMX you just have a page that does nothing:

    <div hx-get="/example">Get Some HTML</div>

This will never do anything without HTMX because the semantic of that markup is wrong. You'd really have to write everything in a vanilla HTML approach to begin with, and never make use of the idea of adding hypermedia to other elements.

you do have to structure things properly to make progressive enhancement work with htmx

for your example, you wouldn't have a div, you'd use an anchor:

      <a hx-get="/example" href="/example">Get Some HTML</a>

or, more likely, just boost it:

      <a hx-boost="true" href="/example">Get Some HTML</a>

and then on the server side you'd need to check the `HX-Request` header to determine if you were going to render an entire page or just some partial bit of HTML

if you go down the progressive enhancement route you need to think carefully about each feature you implement and how to make it compatible w/ no-js. Some patterns (e.g. active search) work well. Others (drag and drop) don't and you'll have to forgo them in the name of supporting noJS

nb: unpoly is a more seamless progressive enhancement experience due to its design goals

You’ve mentioned unpoly in a couple of your comments. I’m a beginner dev and have used HTMX successfully and quite easily, so thank you for making it. What does it offer that Unpoly doesn’t and vice-versa? Or do they basically do the same things?

HTML forms absolutely do function without htmx since it's a part of browser standard. By default, htmx sends forms using same content type as browser does (application/x-www-form-urlencoded). The server will receive same requests, as if the browser sent them and can differentiate by presence of HX-Request HTTP header.

That's the properly part. If you make a form and the output is supposed to go in a particular place and it doesn't (hx-swap), then it isn't functioning properly. The degree to which it is improperly functioning depends on the UI and the user. In many cases it's improperly enough that it may as well either work or not work.

As mentioned, htmx will attach a `HX-Request: true` header to the request[1]. The server can check this header and either return a partial for swapping, or a full page/redirect like in good old days. Same with any request. This is one way of how htmx provides "progressive enhancement". Sure, this may not be as transparent, as other JS-first frameworks implement it, but it's not complex at all.

The only thing that might cause trouble is non-standard (as in HTML standard) HTTP methods, which basically means any method other than GET and POST, I admit that. However, the fact that these methods are not supported even in HTML5 is a huge miss.

[1]: https://htmx.org/reference/#request_headers

SvelteKit forms work fine with Javascript disabled -- Rich Harris is a big proponent of progressive enhancement.

I know they work at some level. That's why I'm comparing them to HTMX.

They don't work fine if the users/stakeholders don't find it acceptable to render the result to the full window instead of the hx-swap style area, or to spend extra time on the backend making it render the whole thing.

Actually, this is one area were SvelteKit has it beat, because the backend is done by SvelteKit, and you don't have to manually deal with hx-swap not taking effect.

have you seen any interest by the browsers to build htmx features as experimental browser features, with the goal of htmx features becoming browser standards?

When looking at the various options, I always enjoyed your architectural choice of htmx being an extension of html, for that very reason. Similar to "phonegap" hoping that the phonegap code base would get smaller and smaller as mobile browsers built more of those features natively. :)

i haven't heard of any browsers implementing these features, but that's the right thing: they would be far more effectively implemented by the hypermedia client and it wouldn't be too much work technically

my sense is that HTML is constrained by social/organizational issues rather than technical ones at this point

hopefully someone on the chrome team notices htmx at some point and HTML starts making progress again

question - which parts of htmx would be better from an end-user-perspective if they were built into the browser? i assume "all features" might be a bit faster, but is there anything which would be night and day better if it wasn't a js library?

the browser vendors have been more than happy to use experimental features to chart their own course, which I think can be a good thing to spawn innovation and healthy competition. (given the standards bodies will be slower and more prudent - similar to how python doesn't want "pedantic" to be part of python core, because that would hurt pedantic's innovation, not improve it)

Maybe the way someone from the chrome team could tap into "business value" of "let's build these htmx features in chrome" would be that it allows developers to write "internal/developer/crud apps" where a "only supported in chrome" is acceptable.....

maybe I'm too close to it, but htmx feels like a hack to address things that really should be part of the HTML spec

if browsers got into the game I would assume they could do things much faster and integrate things like preload (https://htmx.org/extensions/preload/) and idiomorph (https://github.com/bigskysoftware/idiomorph/) much more cleanly w/ the rest of the browser infrastructure

HTMX makes heavy use of replacing branches of the DOM with HTML partials fetch wit get/post requests

There a ton of additional features builtin to HTMX, but I'd love to see just this basic primitive built into browsers. It's related to the element transitions API that has been working it's way into browsers, but approaches it from the angle of HTML partials instead of diffing two full pages durn SPA navigation.

Reply on news.ycombinator.com