undefined | Better HN

0 pointstomhallett3y ago0 comments

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.....

0 comments

2 comments · 2 top-level

_heimdall3y ago

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.

recursivedoubts3y ago

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

j / k navigate · click thread line to collapse