I like htmx too for its simplicity but it’s actually antithetical to another key HN trope: responsiveness. Round-tripping to the server is much slower than client-side JS. It should be terrible for fast keyboard navigation, for instance. You might not notice on a server on localhost or on fast internet (which is very user-hostile to assume).

That said, this is me speaking about htmx based on what I know about it. They may have some tricks up their sleeves these days to account for those issues. But those tricks would need JS.

That's a common argument, but how often are you navigating around in a web app and you don't need data from the server? IME you do like 80+% of the time so "responsiveness" is false anyway, and when you don't you could get pretty far with basic http caching. And assuming high bandwidth is just as bad if not worse than assuming high latency, where typical web app dev platforms perform abysmially not to mention multiple extra round trips and device speed/power. And you could get into the hydration and SSR mess, but then you could just render on the server in the first place and simplify the entire system, reduce your LOC by 5x, opt out of the entire js ecosystem shitshow (or keep it for select high interactivity components, I won't judge), and eliminate an entire api that doesn't need to exist.

If you are building the next google maps, maybe htmx isn't for you. But if you're building another LOB app with mainly forms and data views, or an ecommerce site, or another CMS, there's a 99% chance that htmx is plenty.

Personally, I'm betting that you can make a whole interactive site on top of Go's html/template library + htmx, using a pattern I'm developing here: https://github.com/infogulch/caddy-xtemplate I'm currently co-developing this with an rss reader webapp to work out the kinks.

This…

    <ul>
    {{range .Query `SELECT id,name FROM contacts`}}
        <li><a href="/contact/{{.id}}">{{.name}}</a></li>
    {{end}}
    </ul>

…reminds me of what we used to do in php3 days. That was convenient, performant and… unmaintainable. Am I missing something ?

Who knows if it will be maintainable or not. Can you articulate why the php3 projects became unmaintainable?

I almost have ptsd from these dark days, I won’t go into details ;-) but there’s plenty of literature about separation of concerns. Having the templates doing the data access takes me back 20 years ago, but I can see why this idea comes back in a web component era.

Check out: https://htmx.org/essays/locality-of-behaviour/

The proposal is that Locality of Behavior > Separation of Concerns. Maybe its true! We'll see. :)

I actually like htmx (I find Unpoly superior so that’s what I use, but it’s the same general idea) and the example given makes sense, but one should not extend locality of behaviour to the point of sprinkling SQL in templates. I don’t think that’s what the htmx folks had in mind in this essay either, their canonical example being the html/css/js trio. But hey… there’s no better experience than first-hand experience, you will find soon enough if it works for you.

I agree that it's taking the idea of LoB to an extreme that wasn't intended (at least not explicitly) in the essay. But I still don't see why it's a bad idea considering that SQL-level abstractions (views, procedures, etc) are available. What value does adding a layer of application-level abstraction provide? So I have to name and call a function that calls the sql; to what end?

There’s plenty of literature (and debate !) about mvc/mvt (and its numerous variants and interpretations) in the context of web apps. It’s interesting that you challenge the consensus though.

You make good points. And these are different use cases, where one is simple client behavior where JS is suitable, whereas the other needs a round trip anyway.

I wouldn’t go as far as 99%. There are a lot of web apps where you toggle between panes, expand certain things, and so on. But I think you are still right in the sense that htmx is a very fruitful starter kit that can cover many if not most “boring” standard use cases.

One thing is for sure, this SSR hydration shit show is not a good state of affairs. It’s way too much complexity for what it does. And now you have to worry about reaching the same logical state from two different starting points.

> I'm betting that you can make a whole interactive site on top of Go's html/template library + htmx, using a pattern I'm developing

This is cool, and indeed reminiscent of PHP. Cycle of life!

If I had to architect a front end today, I'd start with HTMX. Very curious how far a HTMX+Deno stack could get you.

I also like htmx. But one day someone pointed me to unpoly, which I find better. So I’ll spread the word here: https://unpoly.com/