I've been writing a ton of ts/js at work, so using htmx for a quick weekend project was a nice change of pace.
I really appreciated the library of examples; they cover a lot of common use cases. Between that and the docs I had no trouble figuring out how things worked.
I still have no idea what benefits having your API serve markup is supposed to confer, but people tell me it's "great".
also, I find your headline misleading. htmx uses javascript, there's no accessing anything "directly from html". you could say that about any framework with directives, ie vue, but we all know better.
you mean via SSE? is any part of that an inherent "htmx only" thing, or even a "markup API only" thing?
a framework using a neat piece of technology isn't really a boon for the framework -- the technology of streaming itself is great, sure, but you can do that with any stack.
Sure, but the browser is fast and rendering HTML so why stream anything else? Why stream javascript + json to build html. You're adding a bunch of marshalling that doesn't need to be there.
Yeah, as I understand it the idea is that instead of making the server-side complex and the frontend code complex, you retain as much complexity server-side as possible and treat the browser as just a hypermedia renderer.
If a part of the page needs to change, the server figures out what it should change to and sends that page fragment.
Right. But, hypermedia systems doesn't go far enough. It can be even simpler then that.
In a video game the "server" doesn't figure out what's changed (that's too much work) it just redraws the frame. So rather than the complexity of working out what has changed you can just send down the whole page again whenever something changes.
This gives you view = f(state) over the wire and has great DX. It's called immediate mode in games.
The main point of hypermedia is the browser, not a gaming platform. Not even the mobile platform. HTMX is not purposed nor it advertises that it should be used outside of the browser scope.
I use Unpoly that replies on the same principles (HTML over the wire) and both of them are very clear about their intentions.
In my mind collaborative apps are a core feature of the web. Streaming hypermedia is a great way to keep all your state on the server and have a solid multiplayer/realtime experience, especially with large datasets.
Here's a basic google sheets clone that does just that:
I do really appreciate that HTMX has a curated list of criticisms on their blog: https://htmx.org/essays/#on-the-other-hand
And they have fun with it:
HTMX Sucks mug: https://swag.htmx.org/products/htmx-sucks-mug
I've been writing a ton of ts/js at work, so using htmx for a quick weekend project was a nice change of pace.
I really appreciated the library of examples; they cover a lot of common use cases. Between that and the docs I had no trouble figuring out how things worked.
I still have no idea what benefits having your API serve markup is supposed to confer, but people tell me it's "great".
also, I find your headline misleading. htmx uses javascript, there's no accessing anything "directly from html". you could say that about any framework with directives, ie vue, but we all know better.
It's really good for streaming view updates to your users in realtime.
you mean via SSE? is any part of that an inherent "htmx only" thing, or even a "markup API only" thing?
a framework using a neat piece of technology isn't really a boon for the framework -- the technology of streaming itself is great, sure, but you can do that with any stack.
Sure, but the browser is fast and rendering HTML so why stream anything else? Why stream javascript + json to build html. You're adding a bunch of marshalling that doesn't need to be there.
Yeah, as I understand it the idea is that instead of making the server-side complex and the frontend code complex, you retain as much complexity server-side as possible and treat the browser as just a hypermedia renderer.
If a part of the page needs to change, the server figures out what it should change to and sends that page fragment.
At least, that's my cursory understanding from reading https://hypermedia.systems
Right. But, hypermedia systems doesn't go far enough. It can be even simpler then that.
In a video game the "server" doesn't figure out what's changed (that's too much work) it just redraws the frame. So rather than the complexity of working out what has changed you can just send down the whole page again whenever something changes.
This gives you view = f(state) over the wire and has great DX. It's called immediate mode in games.
The main point of hypermedia is the browser, not a gaming platform. Not even the mobile platform. HTMX is not purposed nor it advertises that it should be used outside of the browser scope. I use Unpoly that replies on the same principles (HTML over the wire) and both of them are very clear about their intentions.
In my mind collaborative apps are a core feature of the web. Streaming hypermedia is a great way to keep all your state on the server and have a solid multiplayer/realtime experience, especially with large datasets.
Here's a basic google sheets clone that does just that:
https://cells.andersmurphy.com/