241–250 of 291 posts
Some discussion 5 months ago:
I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well…
Many people may disable js when browsing. So there's that.
I'd still pick Unpoly over it. Seems far more high level, feature rich and easier to use although less popular. And if I wanted a popular approach I'd pick Hotwire which can be used with any backend framework anyways. https://unpoly.com/ https://hotwired.dev/
I am also interested in why you like Unpoly more. Genuinely curious because I use and like HTMX and don’t really understand what you get with Unpoly that you don’t with HTMX.
I think you can achieve the same thing with both, but Unpoly is higher level, that means I have to write less attributes/code to achieve the same stuff I guess.
"Compilers" are also a nice way to attach custom code. All the helpers for form validations, the extremely easy way it provides to do modals, and layers in general. The navigation feedback (a'la turbolinks) when navigating across pages, the caching, the error handling. The up-keep for keeping a video player or anything else across pages transitions, and absolutely everything of this can be accessed from a JavaScript API in case you need to perform any of this from your own code and most of these APIs also trigger events.
Probably you can do all of this with HTMX too, but it is more work.
I'd still pick Unpoly over it. Seems far more high level, feature rich and easier to use although less popular. And if I wanted a popular approach I'd pick Hotwire which can be used with any backend framework anyways. https://unpoly.com/ https://hotwired.dev/
Can you expand a bit on why you prefer unpoly over htmx ? I like htmx but I'm genuinely interested in alternatives around the same concept.
Earlier quoted context omitted.
no differerence at all. jQuery functions like $('.foo').on('click', () => $.ajax(... $('.bar').html(result) )) become unmanageable just as quickly.
So your complaint is not about HTMX, but about using any kind of JS without using a framework like React.
For example the upvote could be implemented like this:
function renderUpvote(container, showNotification) {
$("").appendTo(container).on("click", () => $.ajax( ...
result => showNotification( result ))
}
Earlier quoted context omitted.
let's say that you have an upvote button Upvote Well where is this notification-bar? It could be anywhere on the page. Maybe it was introduced by another htmx action from another endpoint. Answering this simple question could take a lot of work. There is no way to work it out systematically short of auditing every interaction on the page.
Isn't this comparable to any other situation where you reference something outside a project, even in C with libraries? (I've never used HTMX or even looked beyond this page for it, so maybe what I'm about to say is logically wrong.) If I said that for an HTMX project you must define all components you use within the project, wouldn't this hx-target example be very easy to identify quickly in the project? You simply…
Earlier quoted context omitted.
let's say that you have an upvote button Upvote Well where is this notification-bar? It could be anywhere on the page. Maybe it was introduced by another htmx action from another endpoint. Answering this simple question could take a lot of work. There is no way to work it out systematically short of auditing every interaction on the page.
That's because this example is an anti-pattern, the swap should be local [1], the button changes itself (to an orange arrow, to disable itself, etc) and the notification tag (#notification-bar) should be responsible of its own behavior. An idea could be that the notification bar is polling a notification endpoint every Xsec or on a specific event [2], or if you want to be fancy with WebSockets [3] [1] They actually t…
Earlier quoted context omitted.
So your complaint is not about HTMX, but about using any kind of JS without using a framework like React.
You don't need a framework like React but you should try to implement modules that are explicit about their dependencies and use local state as much as possible. For example the upvote could be implemented like this: function renderUpvote(container, showNotification) { $(" ").appendTo(container).on("click", () => $.ajax( ... result => showNotification( result )) } Now the notification action is passed in from a paren…
And imagine if htmx became absorbed into the real html standard. It would take much longer for the standards body (and then browser makers) to respond and implement.
So the crucial flaw is that it will always be reacting instead of innovating. And more generally, this is likely why the “thick client” approach is more popular on the web these days. Nobody wanted to wait around for standards bodies and browser makers.