I'm a bit disappointed at the removal of SSE from core HTMX, mostly as I see SSE as being much more in-line with standard hypertext, and there does need to be some kind of server-push-long-polling-thingy.
Not very disappointed, but I do wonder why it doesn't ship with SSE as standard.
yeah, it was a hard decision pulling sse and web socket support out, but we've done that already in the 1.x line: the hx-ws and hx-sse attributes are deprecated in favor of extensions:
our feeling was that, to do those things right would require a fair bit of code and it wasn't fair to all htmx users to make them pay that freight, as these were more advanced features that many people would not be using
another feature we didn't include was idiomorph-based swapping out of the box:
that was really hard to not include because it's a neat algorithm that i came up w/ and it's going to be included in the next version of Rails, but, again didn't feel it was fair to make everyone pay for it
FWIW, since it is so easy to include extensions, I think you made the right choice. That said, for the project I want to try HTMX out on, I will definitely be trying out idiomorph swapping. Sounds novel and useful.
That's interesting, I assumed htmx already did morph the dom this way. The company I work for has a similar but custom system in place they built 10 years ago that morphs the dom for those reasons (came up in a meeting last week, it was made before I joined). Shame it wasn't open sourced back then, it's pretty neat solution with websocket signalling to do multi user screen updates.
I've been following HTMX for quite a while but never noticed the haiku in the footer before. It feels like it accurately reflects the spirit of HTMX. It is making me think I should add haikus to my projects' README.md.
javascript fatigue:
longing for a hypertext
already in hand
I'd be very interested in a comparison of htmx 2 vs Unpoly, since some of the issues Unpoly mentions seem in direct response to htmx, such as response code handling.
i didn't really look much at unpoly (which I admire), htmx is focused on generalizing hypermedia controls rather than competing w/ other libraries on features
I did try to make more things configurable, for example the response code handling is now declarative rather than requiring you to hook into an event & you can turn off attribute inheritance if you don't like that
unpoly is a great project and is absolutely best-in-class for progressive enhancement
htmx is lower level but has a bit more mechanical sympathy w/normal HTML: more work for some things, but less magic too. it's focused on generalizing hypermedia controls, as outlined here:
there is a terrible simplicity to htmx that I think many developers find attractive after a decade of heaping complexity on top of web development
my ability to market htmx has surprised me as well, i have been silly on twitter for a long time now, but for whatever reason it recently started working
You see unnecessary bloat, I see wheel reinventions. Unpoly gives me almost everything I need for any non trivial app. Same thinking about using Django/Rails/Laravel vs bare bone routers like express, Sinatra or flask.
Once you get past the simple landing page or hello world app all those things you call “bloat” come in super handy. Otherwise you end up with a custom undocumented untested unproven probably insecure rushed out implementation of what the “bloated” solution gives you. Same applies for Unpoly vs htmx. Unless you’re building just a hello world landing page, as I said.
Not very disappointed, but I do wonder why it doesn't ship with SSE as standard.