5 ms·

That's a great hack and it shows how close the browser is to offering SPA natively. Just a few attributes and we could avoid the iframe. It's probably more us

That's a great hack and it shows how close the browser is to offering SPA natively. Just a few attributes and we could avoid the iframe. It's probably more useful to prove a point than an actual day to day tool. And the point seems to be: htmx is too much trouble for what it offers. We just need HTML native ajax.

larodi 3y ago
You know... we've been doing something very similar 20 years ago for a stats dashboard web app - reloading only DIVs that need with new content server-generated. We didn't even bother to recreate the DOM, but directly innerHTML = content loaded. Perl on the back-end and some very tiny JS on the front-end. Do I need to tell U that this worked as absolute charm and was blazing fast. The only considerable downside was that indeed lots of traffic was going back and forth. But then 20 years later latency is much lower, traffic much cheaper, CPUs also, and I am very happy to see more and more people realize this bare-bones approach was actually a good thing to consider (the author lists the downsides). To me such approach is much more web-native in comparison to abomination UI frameworks, that try to reinvent presentation marginalizing the browser to be nothing more than a drawing surface. But guess what - their primary goal is to save on this network latency, that is anyway going down down down down with every year. The htmlz/htmlx approach is indeed much simpler and easy to live with in a large project, it is really sad that we put so much logic in the front-end in recent years...
alexpetros 3y ago
"Just a few attributes and we could avoid the iframe" could be the htmx/z motto
Kalabasa 3y ago
Yes this was a response to htmx. It was a half-parody half-I wanna make it work project. Like https://github.com/vilgacx/aki https://github.com/vilgacx/aki I would fear if anyone wants to use this in production BUT I would love someone to get inspired and use the concepts rather than the actual code. Hmm maybe i should write a disclaimer...
- detritus 3y ago
  It sounds like 'probably, yes' to adding a disclaimer, if only because I rather took it at face-value seeing it posted here on QBN so bookmarked for investigation later... .
- briantakita 3y ago
  Love it! I think this idea has some legs in that a programmer can build their own f****k. Bundling only the pieces that they actually use. I don't see why it should not be used in a production environment...other than someone in the internet disapproves...a fear many of us suffer from. It's a simple idea & can be easily managed in a codebase. In he spirit of breaking apart HTMX piece by piece, I created hyop (Hypermedia/Hydration Operation). It weighs in at 61 B but uses the "hyop" attribute. I know, I know, I'm bad...but at least I save bytes. https://github.com/hyopjs/hyop https://github.com/hyopjs/hyop I'm going to use some of your concepts, with credit of course...like the snippetware idea among others.
  - bee_rider 3y ago
    What is f****k? Fuuuck? Or maybe framework but HN has eaten some of your stars?
    - zubairshaik 3y ago
      It's supposed to be framework, the same way it was censored in TFA
  - zestyping 3y ago
    What does single__hyop actually do? I read the whole README and couldn't find a definition of it. Is it essentially the same as onload="..." ?
    - naasking 3y ago
      It looks like it's used to register hooks to invoke custom behaviour on elements defined by the hyop attribute. The document load handler defines a central dispatch table for all of these hooks.
naasking 3y ago
HTML native ajax is the right approach, and what the htmx devs fully support if I understand correctly, but I don't think this demonstrates htmx is too much trouble for what it offers. It offers considerably more than what's possible here, eg. DOM morphing, animations, graceful degradation, rich event model, server side events, etc.
recursivedoubts 3y ago
I'm the creator of htmx and think this is a great library/snippet. Much closer to what htmx-like functionality in HTML would/should look like in that it is following existing norms (iframes, the target attribute) much more closely than htmx. From a practical perspective, a lot of the bulk of htmx is bound up in things like history support, collecting inputs, a lot of callbacks/events to allow people to plug into things, etc. I expect a lot of htmx-like libraries will come out now that it has some traction: it's not a super complicated idea, and many of them will pick smaller, more targeted subsets of functionality to implement. That's a good thing: the ideas of hypermedia are more important than my particular implementation.
- digitalsin 3y ago
  I'm just here to say how much I love htmx! Thank you so much for all the work put into it!
- tambourine_man 3y ago
  Sorry if I came across as dismissive, htmx is a much needed counterpoint to React's dominance and a great contribution to the industry. And I hope its core idea (Ajax from HTML with results loading inside a target element) will be adopted as a Web standard.
  - recursivedoubts 3y ago
    not at all, i understand there are going to be different takes on what the right balance of functionality & configuration are and htmx has been hamstrung to an extent by being IE compatible, which, coupled w/ my commitment to backwards compatibility, means some obvious things are off the table (e.g. using fetch()) i don't begrudge other people having differing opinions on this stuff and agree w/the spirit of your original comment: HTML should have a native mechanism for doing what htmx does. hopefully htmx (and other takes on the idea) contribute to that future.
- DoesntMatter22 3y ago
  Love the fact that you care more about the tech than HTMX winning. I like htmx a lot though

larodi 3y ago

You know... we've been doing something very similar 20 years ago for a stats dashboard web app - reloading only DIVs that need with new content server-generated. We didn't even bother to recreate the DOM, but directly innerHTML = content loaded. Perl on the back-end and some very tiny JS on the front-end. Do I need to tell U that this worked as absolute charm and was blazing fast. The only considerable downside was that indeed lots of traffic was going back and forth. But then 20 years later latency is much lower, traffic much cheaper, CPUs also, and I am very happy to see more and more people realize this bare-bones approach was actually a good thing to consider (the author lists the downsides). To me such approach is much more web-native in comparison to abomination UI frameworks, that try to reinvent presentation marginalizing the browser to be nothing more than a drawing surface. But guess what - their primary goal is to save on this network latency, that is anyway going down down down down with every year. The htmlz/htmlx approach is indeed much simpler and easy to live with in a large project, it is really sad that we put so much logic in the front-end in recent years...

alexpetros 3y ago

"Just a few attributes and we could avoid the iframe" could be the htmx/z motto

Kalabasa 3y ago

Yes this was a response to htmx. It was a half-parody half-I wanna make it work project. Like https://github.com/vilgacx/aki https://github.com/vilgacx/aki I would fear if anyone wants to use this in production BUT I would love someone to get inspired and use the concepts rather than the actual code. Hmm maybe i should write a disclaimer...

detritus 3y ago
It sounds like 'probably, yes' to adding a disclaimer, if only because I rather took it at face-value seeing it posted here on QBN so bookmarked for investigation later... .
briantakita 3y ago
Love it! I think this idea has some legs in that a programmer can build their own f****k. Bundling only the pieces that they actually use. I don't see why it should not be used in a production environment...other than someone in the internet disapproves...a fear many of us suffer from. It's a simple idea & can be easily managed in a codebase. In he spirit of breaking apart HTMX piece by piece, I created hyop (Hypermedia/Hydration Operation). It weighs in at 61 B but uses the "hyop" attribute. I know, I know, I'm bad...but at least I save bytes. https://github.com/hyopjs/hyop https://github.com/hyopjs/hyop I'm going to use some of your concepts, with credit of course...like the snippetware idea among others.
- bee_rider 3y ago
  What is f****k? Fuuuck? Or maybe framework but HN has eaten some of your stars?
  - zubairshaik 3y ago
    It's supposed to be framework, the same way it was censored in TFA
- zestyping 3y ago
  What does single__hyop actually do? I read the whole README and couldn't find a definition of it. Is it essentially the same as onload="..." ?
  - naasking 3y ago
    It looks like it's used to register hooks to invoke custom behaviour on elements defined by the hyop attribute. The document load handler defines a central dispatch table for all of these hooks.

naasking 3y ago

HTML native ajax is the right approach, and what the htmx devs fully support if I understand correctly, but I don't think this demonstrates htmx is too much trouble for what it offers. It offers considerably more than what's possible here, eg. DOM morphing, animations, graceful degradation, rich event model, server side events, etc.

recursivedoubts 3y ago

I'm the creator of htmx and think this is a great library/snippet. Much closer to what htmx-like functionality in HTML would/should look like in that it is following existing norms (iframes, the target attribute) much more closely than htmx. From a practical perspective, a lot of the bulk of htmx is bound up in things like history support, collecting inputs, a lot of callbacks/events to allow people to plug into things, etc. I expect a lot of htmx-like libraries will come out now that it has some traction: it's not a super complicated idea, and many of them will pick smaller, more targeted subsets of functionality to implement. That's a good thing: the ideas of hypermedia are more important than my particular implementation.

digitalsin 3y ago
I'm just here to say how much I love htmx! Thank you so much for all the work put into it!
tambourine_man 3y ago
Sorry if I came across as dismissive, htmx is a much needed counterpoint to React's dominance and a great contribution to the industry. And I hope its core idea (Ajax from HTML with results loading inside a target element) will be adopted as a Web standard.
- recursivedoubts 3y ago
  not at all, i understand there are going to be different takes on what the right balance of functionality & configuration are and htmx has been hamstrung to an extent by being IE compatible, which, coupled w/ my commitment to backwards compatibility, means some obvious things are off the table (e.g. using fetch()) i don't begrudge other people having differing opinions on this stuff and agree w/the spirit of your original comment: HTML should have a native mechanism for doing what htmx does. hopefully htmx (and other takes on the idea) contribute to that future.
DoesntMatter22 3y ago
Love the fact that you care more about the tech than HTMX winning. I like htmx a lot though