7 ms·

What we need is for HTML to get going as a hypermedia again, to make the hypermedia architecture viable for a larger set of web applications. It's been stalled

What we need is for HTML to get going as a hypermedia again, to make the hypermedia architecture viable for a larger set of web applications. It's been stalled at anchors and forms (with only GET and POST!) for decades now. It's astounding how much we got built with just that. I'm trying to show where it could go with htmx: https://htmx.org https://htmx.org Hypermedia (in particular the uniform interface) is what made the web special and there's no reason HTML can't be improved as a hypermedia along the lines of htmx/unpoly/etc. We don't need something new. We need to take the original concepts of the web (REST/HATEOAS/Hypermedia) seriously and push the folks in charge of HTML to do the same. Sure, browsers as install-free RPC client hosts works and is occasionally called for, but there is a huge gray area between "applications" and "documents", just waiting for a more expressive hypermedia.

pphysch 4y ago
HTMX is fantastic. Today I built a proof of concept in Django+HTMX+D3.js. Fully reactive, interactive, HTML-first widgets with no npm nor "build" stage. Do anything with good ole HTML templates and just HTMX and D3!
- tachyon6 4y ago
  I’d love to see the demo! I’m in the process of building something similar
acabal 4y ago
I've always been shocked that HTML forms only support GET and POST and there's zero interest in supporting more HTTP methods in forms even in 2022. If forms supported the whole range of HTTP methods we could have a user facing web that's identical to a REST API, with different Accept and Content-type headers. Imagine how much development time we could save if forms supported DELETE and PUT!
- recursivedoubts 4y ago
  it's incredible that we got WebGL, Web Assembly and a million other things that are neat, but not really crucial to a proper hypermedia implementation, but they can't give us DELETE, PUT and PATCH in HTML, even though they are sitting there in HTTP just staring us in the face! the irony is that DELETE, PUT and PATCH are used today almost exclusively in non-hypermedia JSON data APIs crazy world!
- majormajor 4y ago
  Does that save us much time? In the systems I've worked on, the problems of deletions and edits aren't HTTP verbs, they're wild, complex business rules around authentication, authorization, auditing, etc.
- bawolff 4y ago
  That's pretty silly. This is like claiming the world would be fundamentally different if we used <em> instead of <b>. Anyone who thinks this is remotely useful is already doing it by either using ajax or by just overloading POST. We do not save development time by renaming a concept.
- Devasta 4y ago
  The W3C attempted to improve HTML forms with xForms, but the browser vendors are deathly afraid of anything XML based so it never got implemented. These days HTML is really only viewed as a payload carrier for your JS application so doubt that'll ever change either.
- DeathArrow 4y ago
  You know you can update or delete a resource by using GET or POST?
  - zzo38computer 4y ago
    You can, but it is not the proper way to work HTTP.
- dragonwriter 4y ago
  > Imagine how much development time we could save if forms supported DELETE and PUT! not much; while you need a little (easily reusable) JS code to use and handle responses to other methods, it's such a tiny fraction of the dev effort that goes into web apps that it makes no meaningful difference. It would be nice if HTML forms supported other methods for completeness, but it wouldn't save all that much real-world development effort.
arbenpurben 4y ago
This. This gets us 98% of the way. The people that have to worry about the 2% are not you, because your web app almost certainly doesn’t need offline-first of FPS-like user interaction, so in 98% of cases, hypermedia + tech like htmx gets you 100% of the way. For pete’s sake, just let your server serve html. Replace only the parts of the page that need to update… with html. From your server. The poor thing is just sitting there, idling, bored, borderline depressed because it doesn’t get much of chance to do what it is meant to do, which is, you know… serve. “But it serves JSON” … is like buying a Bugatti Veyron, just to park it in your garage and use its exhaust fumes to dry your clothes 6 days of the week, with a 2 minute drive around the block on Sundays.
- nsonha 4y ago
  > For pete’s sake, just let your server serve html You do realize this means all the user data has to be sent to the cloud? Which is what we want to escape? Hypermedia was created for bots for discoverability, I don't know why anyone would think this is an user-centric concept.
- hutzlibu 4y ago
  "“But it serves JSON” … is like buying a Bugatti Veyron, just to park it in your garage and use its exhaust fumes to dry your clothes 6 days of the week, with a 2 minute drive around the block on Sundays." That is a very creative analogy, but not one I agree with. My servers should do as little as possible. They should not serve files just for the sake of it, because they have all these shiny serving features. And I like JSON as it is not as verbose as html and I can directly work with it in javascript. And then update my html where I need it locally. If you prefer it differently, than this is fine. The web supports many ways.
  - brtkdotse 4y ago
    > My servers should do as little as possible. Why? It’s not like they wear and tear?
    - _448 4y ago
anoy8888 4y ago
Am I the only one who is not excited by this new web idea ? As a web developer, we have to deal with framework and library major reinventions every couple of years and now you are telling me that you are going to reinvent browser rendering engines that we need to develop and test and then also your crappy reinventions . Thanks but no thanks . Please just build on top of giants . Not reinvent everything all the time .
- fredrikholm 4y ago
  New idea? Hypermedia is from 1965, and has been a thing since 1991; HTML. recursivedoubts HTMX library is cutting edge 2005 technology. To add to both of your arguments, "JS-routers" like SvelteKit/NuxtJS/NextJS are literally reinventing server side rendering for the client to then call the actual server to get data ... to render HTML. HTMX, LiveView, Livewire, Hotwire etc are escape hatches back to sanity.
  - Tade0 4y ago
    > SvelteKit/NuxtJS/NextJS are literally reinventing server side rendering for the client to then call the actual server to get data ... to render HTML. It's all done in one call - at least in Svelte. You can even render all this into a fully static site. Meanwhile htmx and the like is the same idea that was popular 15-ish years ago, which died for good reasons.
    - cassepipe 4y ago
      Curious about those good reasons. Care to elaborate ?
      - malloryerik 4y ago
        Maybe what was a "good reason" 15 years ago isn't anymore, namely the lack in those days of WebSockets and, if I'm correct, widespread Server Sent Events?
      - Tade0 4y ago
jacobr 4y ago
Instead we get Web Components, where HTML is an afterthought. Only years later are we getting things like Declarative Shadow DOM. You’re always expected to write custom JS for every single component on your page, instead of doing something like “add this functionality whenever you see the `foo` attribute on any HTML element”
thestepafter 4y ago
I have been reading a lot about HTMX and planning to develop an app in it on top of a JSON API. With that being said do you know if any open source apps that do authentication on top of a JSON API using HTMX? I’m having trouble conceptualizing the structure and flow of data from just reading the docs. Primarily around maintaining state between pages. (Looking to use JWT for authentication.)
- egeozcan 4y ago
  htmx is designed to work with a HTML API. Everyone here seems to love it, I found it forces terribly complicated routing and templating and IMHO projects grow towards unmaintainable very quickly. I'm saying this as a person who really tried hard to like it. You can perhaps use Alpine.js plus sprinkle htmx here and there, to have the best of both worlds, at least on paper. Didn't try this myself.
  - recursivedoubts 4y ago
    i'm old enough to remember when everyone here hated it ;)
    - egeozcan 4y ago
      I used intercooler.js (the predecessor of htmlx) a lot to sprinkle interactivity on top of static pages. Back then I remember the attidute was positive for it too. Not for building proper web apps though...
dgb23 4y ago
Htmx is very well designed library and I‘ve been using it more and more. It’s great to have it in my toolbox. The reason it, and the many other cool libraries can exist is borne out of the strength of the web, namely a solid, accessible foundation of protocols and formats with extensibility via JavaScript. This last part is incredibly important, because it gives us enough power to create and explore new things, while the web standards can conservatively adopt new capabilities. The web is working as intended, and while there are many issues and lacking areas (which htmx illustrates beautifully), we can take a step back and appreciate how amazing and empowering a platform it is.
- recursivedoubts 4y ago
  agreed, fielding specifically mentions scripting as an optional constraint in section 5.1.5 of his dissertation, "Code on Demand": https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7 https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... and it has proven to be an incredibly flexible aspect of the web however, I would note, currently that scripting ability is being used mainly to replace the original hypermedia model of the web (with RPC-style JSON-based applications) rather than enhance it as a hypermedia we'll see if we can change that
agumonkey 4y ago
There's also ergonomics voids in the document approach. Humans don't just use documents, they do higher order things.
knighthack 4y ago
HTMX has been one of the best libraries I've used to date. Love it to bits.
- recursivedoubts 4y ago
  :) glad to hear you are finding it useful

pphysch 4y ago

HTMX is fantastic. Today I built a proof of concept in Django+HTMX+D3.js. Fully reactive, interactive, HTML-first widgets with no npm nor "build" stage. Do anything with good ole HTML templates and just HTMX and D3!

tachyon6 4y ago
I’d love to see the demo! I’m in the process of building something similar

acabal 4y ago

I've always been shocked that HTML forms only support GET and POST and there's zero interest in supporting more HTTP methods in forms even in 2022. If forms supported the whole range of HTTP methods we could have a user facing web that's identical to a REST API, with different Accept and Content-type headers. Imagine how much development time we could save if forms supported DELETE and PUT!

recursivedoubts 4y ago
it's incredible that we got WebGL, Web Assembly and a million other things that are neat, but not really crucial to a proper hypermedia implementation, but they can't give us DELETE, PUT and PATCH in HTML, even though they are sitting there in HTTP just staring us in the face! the irony is that DELETE, PUT and PATCH are used today almost exclusively in non-hypermedia JSON data APIs crazy world!
majormajor 4y ago
Does that save us much time? In the systems I've worked on, the problems of deletions and edits aren't HTTP verbs, they're wild, complex business rules around authentication, authorization, auditing, etc.
bawolff 4y ago
That's pretty silly. This is like claiming the world would be fundamentally different if we used <em> instead of <b>. Anyone who thinks this is remotely useful is already doing it by either using ajax or by just overloading POST. We do not save development time by renaming a concept.
Devasta 4y ago
The W3C attempted to improve HTML forms with xForms, but the browser vendors are deathly afraid of anything XML based so it never got implemented. These days HTML is really only viewed as a payload carrier for your JS application so doubt that'll ever change either.
DeathArrow 4y ago
You know you can update or delete a resource by using GET or POST?
- zzo38computer 4y ago
  You can, but it is not the proper way to work HTTP.
dragonwriter 4y ago
> Imagine how much development time we could save if forms supported DELETE and PUT! not much; while you need a little (easily reusable) JS code to use and handle responses to other methods, it's such a tiny fraction of the dev effort that goes into web apps that it makes no meaningful difference. It would be nice if HTML forms supported other methods for completeness, but it wouldn't save all that much real-world development effort.

arbenpurben 4y ago

This. This gets us 98% of the way. The people that have to worry about the 2% are not you, because your web app almost certainly doesn’t need offline-first of FPS-like user interaction, so in 98% of cases, hypermedia + tech like htmx gets you 100% of the way. For pete’s sake, just let your server serve html. Replace only the parts of the page that need to update… with html. From your server. The poor thing is just sitting there, idling, bored, borderline depressed because it doesn’t get much of chance to do what it is meant to do, which is, you know… serve. “But it serves JSON” … is like buying a Bugatti Veyron, just to park it in your garage and use its exhaust fumes to dry your clothes 6 days of the week, with a 2 minute drive around the block on Sundays.

nsonha 4y ago
> For pete’s sake, just let your server serve html You do realize this means all the user data has to be sent to the cloud? Which is what we want to escape? Hypermedia was created for bots for discoverability, I don't know why anyone would think this is an user-centric concept.
hutzlibu 4y ago
"“But it serves JSON” … is like buying a Bugatti Veyron, just to park it in your garage and use its exhaust fumes to dry your clothes 6 days of the week, with a 2 minute drive around the block on Sundays." That is a very creative analogy, but not one I agree with. My servers should do as little as possible. They should not serve files just for the sake of it, because they have all these shiny serving features. And I like JSON as it is not as verbose as html and I can directly work with it in javascript. And then update my html where I need it locally. If you prefer it differently, than this is fine. The web supports many ways.
- brtkdotse 4y ago
  > My servers should do as little as possible. Why? It’s not like they wear and tear?
  - _448 4y ago

anoy8888 4y ago

Am I the only one who is not excited by this new web idea ? As a web developer, we have to deal with framework and library major reinventions every couple of years and now you are telling me that you are going to reinvent browser rendering engines that we need to develop and test and then also your crappy reinventions . Thanks but no thanks . Please just build on top of giants . Not reinvent everything all the time .

fredrikholm 4y ago
New idea? Hypermedia is from 1965, and has been a thing since 1991; HTML. recursivedoubts HTMX library is cutting edge 2005 technology. To add to both of your arguments, "JS-routers" like SvelteKit/NuxtJS/NextJS are literally reinventing server side rendering for the client to then call the actual server to get data ... to render HTML. HTMX, LiveView, Livewire, Hotwire etc are escape hatches back to sanity.
- Tade0 4y ago
  > SvelteKit/NuxtJS/NextJS are literally reinventing server side rendering for the client to then call the actual server to get data ... to render HTML. It's all done in one call - at least in Svelte. You can even render all this into a fully static site. Meanwhile htmx and the like is the same idea that was popular 15-ish years ago, which died for good reasons.
  - cassepipe 4y ago
    Curious about those good reasons. Care to elaborate ?
    - malloryerik 4y ago
      Maybe what was a "good reason" 15 years ago isn't anymore, namely the lack in those days of WebSockets and, if I'm correct, widespread Server Sent Events?
    - Tade0 4y ago

jacobr 4y ago

Instead we get Web Components, where HTML is an afterthought. Only years later are we getting things like Declarative Shadow DOM. You’re always expected to write custom JS for every single component on your page, instead of doing something like “add this functionality whenever you see the `foo` attribute on any HTML element”

thestepafter 4y ago

I have been reading a lot about HTMX and planning to develop an app in it on top of a JSON API. With that being said do you know if any open source apps that do authentication on top of a JSON API using HTMX? I’m having trouble conceptualizing the structure and flow of data from just reading the docs. Primarily around maintaining state between pages. (Looking to use JWT for authentication.)

egeozcan 4y ago
htmx is designed to work with a HTML API. Everyone here seems to love it, I found it forces terribly complicated routing and templating and IMHO projects grow towards unmaintainable very quickly. I'm saying this as a person who really tried hard to like it. You can perhaps use Alpine.js plus sprinkle htmx here and there, to have the best of both worlds, at least on paper. Didn't try this myself.
- recursivedoubts 4y ago
  i'm old enough to remember when everyone here hated it ;)
  - egeozcan 4y ago
    I used intercooler.js (the predecessor of htmlx) a lot to sprinkle interactivity on top of static pages. Back then I remember the attidute was positive for it too. Not for building proper web apps though...

dgb23 4y ago

Htmx is very well designed library and I‘ve been using it more and more. It’s great to have it in my toolbox. The reason it, and the many other cool libraries can exist is borne out of the strength of the web, namely a solid, accessible foundation of protocols and formats with extensibility via JavaScript. This last part is incredibly important, because it gives us enough power to create and explore new things, while the web standards can conservatively adopt new capabilities. The web is working as intended, and while there are many issues and lacking areas (which htmx illustrates beautifully), we can take a step back and appreciate how amazing and empowering a platform it is.

recursivedoubts 4y ago
agreed, fielding specifically mentions scripting as an optional constraint in section 5.1.5 of his dissertation, "Code on Demand": https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7 https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... and it has proven to be an incredibly flexible aspect of the web however, I would note, currently that scripting ability is being used mainly to replace the original hypermedia model of the web (with RPC-style JSON-based applications) rather than enhance it as a hypermedia we'll see if we can change that

agumonkey 4y ago

There's also ergonomics voids in the document approach. Humans don't just use documents, they do higher order things.

knighthack 4y ago

HTMX has been one of the best libraries I've used to date. Love it to bits.

recursivedoubts 4y ago
:) glad to hear you are finding it useful