I’ve attempted to use HTMX a few times (as a React-hater, its hype lures me in) and every time I’ve come away feeling like I’ve wasted my time implementing a subpar solution.

From reading this, I’ve decided I will never attempt to use it again. All I could think was, just use Go’s HTML templating. What is HTMX adding, really?

▲

bananapub 2 days ago | parent | next [-]

(out of interest: did you ever write web apps before ~2010 or so? the answer to your question seems so obvious to me I'm not even sure where the confusion could come from, unless you've only ever written web apps that are "JS frontend, JS backend, magic communication between them, it's often not clear where some bit of code is running").

HTMX here is making it so the page works without doing a full HTTP form submission + page load for each stage of the "wizard". instead, you write some HTMX stuff in the page that submits the form asynchronously, then the server sends back the HTML to replace part of the page to move to you to the next step in the "wizard", and then HTMX replaces the relevant DOM nodes to make that so.

Go's templating is completely unrelated to any of this happening on the front end - it's just generating some HTML, both the "whole page loaded by the browser normally" and the "here's the new widget state code", and so obviously:

> just use Go’s HTML templating.

is incorrect.

▲

jmull 2 days ago | parent | next [-]

HTMX is the same approach as old-school server-side templating, except you can replace parts of the page with HTML returned from the server, rather than always the whole page.

This allows for some nicely responsive interactions, but introduces complexity.

I'm not the previous poster, but it's a fair question whether the maybe faster responses justify the complexity. In many cases it probably would not.

(Actually, I suspect it's rare; if you know how to make partial page responses fast for HTMX, you know how to make full page responses fast and don't necessarily need HTMX, up until your page just gets too large overall.)

The general problem with HTMX is that, by default, the page state, as a function of the initial page plus the accumulated user's interactions with the page, live only in the user's browser tab. This can seem fine for a while, but opens up some fairly fat edge cases (this article covers some of them). There are ways to handle this, but it's additional complexity and work. Maybe someone has or will create an HTMX-friendly server-side templating framework to take the grunt work out of it, but you still have to wonder if one of the numerous existing full page templating mechanisms might not still be superior, overall.

	▲	hirvi74 2 days ago \| parent [-]
		> HTMX is the same approach as old-school server-side templating, except you can replace parts of the page with HTML returned from the server, rather than always the whole page. Hasn't jQuery been able to do this since the early 2000s? Even vanilla JS has this functionality for decades too.

▲

the_sleaze_ 2 days ago | parent | prev [-]

I believe what he's saying is either embrace the full power and maintenance of a JS client side framework, or just use ssr'd templates. I agree with them, that HTMX isn't attractive because it doesn't solve any issues I find important. I largest of which is I don't "hate" react and I don't attach emotionally to any arguments about "frontend"

▲

hirvi74 2 days ago | parent | prev [-]

I have had similar experiences too. To me, HTMX felt like a wrapper around vanilla JS's .fetch() or jQuery's AJAX calls except one just litters the HTML with specific custom HTML attributes.

.fetch() has no issues returning server-side rendered HTML and has a lot more options and freedom than what HTMX provides.

I do not think HTMX is a bad library by any means. I just can't see what it buys over vanilla JS.