Hacker News Reader

Comment by localhostinger | Hacker News Reader

HTMX is great for a lot of things, but if you're working in a team, and your colleagues are not on board, it's tough. Lots of "this is not a serious technology" kind of arguments. All kinds of bugs simply initially blamed on the choice of using HTMX. Even if proven wrong afterwards, the damage is already done. And this was in the most excellent team I have worked in so far.

I'm happy that I got to experience this and I learned from it. Gotta choose your battles or something.

As for Go's html/template: I think it has one of the weirdest / most unnatural interfaces. I recently reread "A Philosophy of Software Design" and one of its key points is to keep interfaces simple and push complexity downwards, making it easier for others to use. Now why do I have to care about "cloning templates" every time I render some html template? Love the Go stdlib, but this thing feels unnecessary complex to me.

View on HN

As much as I really like htmx -- this is a sad truth!

I tried to pitch htmx to my team last year and found an opportunity to create a simple webapp. One of the devs really struggled with htmx after years of muscle memory returning json and rendering in JS/JQuery. It was a lot of "I now have to do this.. how do I solve this problem?"

I think he would have struggled with any different approach whether we changed to angular, react, etc. htmx didn't really stand a chance.

The other dev, on the other hand, didn't even bother to try it.

All I heard from the team was Blazor this, blazor that.

Personally I think it's a shame. We are a small team and would be good to avoid javascript 95% of the time. We could just generate server side code/html which, imo, would create organised code base. Easy to test as well.

Any personal web projects I still use htmx and reached a decent flow with it. Completely simplifies web dev, imo.

Exactly the same thing happen to me: https://www.reddit.com/r/htmx/s/DuXyGgsCWK

I'm in an advisor position, and I tried very hard to mentor the team, explaining that learning this technology deepens your understanding of the browser. Whereas React etc isolates you from the actual environment you're working in - the browser.

On html/template, I like the security by default, and obviously it's built-in. But the dynamicness leaves too many open-ended questions unanswered. Templ is great, but the ergonomics leaves many things to be desired. After writing a few large production applications in it. I decided to create gsx: https://github.com/gsxhq/gsx

I've worked with developers that don't even understand that the "form" tag exists and browser can send a request without any javascript. At some point in the early 2010's, perhaps even before, fundamental understanding disappeared. This makes it difficult to introduce alternative technologies like HTMX into a larger project.

yeah with tools like HTMX - your environment shapes you.

if your teams is less than 3 people - you've less politics to fight. & chances are people are already capable - no resume padding. so you choose what's pragmatic & that choice ends up being HTMX.

for big teams - politics takes over. even though HTMX will be beneficial - might as well go with the 'safer' political choice which doesn't cause much contention ie one of the big JS frameworks.

I have also noticed teams don't seem to "get" htmx.

It is an unbelievably good tool though, and LLM's understand it very well (given some encouragement).

> Now why do I have to care about "cloning templates" every time I render some html template?

You do not have to. It's a self-sustained injury by the author. You can compile the templates once and just execute them.

The issue is that author wants to specify page titles in the main templates. If you pass titles as a context, you can split base.tmpl into BASE_BEGIN, BASE_END and use them in the final templates.

Yes, you will have to pass the title depending on the page template during the But his tactics will break anyway when you try to support different languages.

That's not the reason I use Clone() in this pattern. The main reason for the clone operation is convenience. The clone operation is on the already-parsed set of shared templates (base+partials in this example code). It provides the convenience of not having to specify the path to the base template and any paths to the partial templates needed by that page in the call to render().

There may also be a performance benefit too - I suspect that the Clone() operation is cheaper than re-parsing the base and any necessary partial templates in each render() call, but I've never benchmarked it, so I can't assert that with certainty.

I had the same thing but in reverse, it's impossible to convince my company that the React SPA simply doesn't scale despite all the problems we have with it.

They can see each problems one by one but can't put it in the same picture as it's "proven technology"

Reply on news.ycombinator.com