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.
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.
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.
> 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"
Happy to see this popping up here, I watched the Linux Tage talk last week. The demo just kept getting better and better, to a point where the audience just interruptively cheers and claps away. I know nothing about the contents, but this warmed my heart. True hacker project!
In IT school back in 2008 (with 14). I had absolutely no idea about the school or programming, I was just knowing my way around computers, so I signed up for it. We started with C and I remember the first couple of weeks and exercises just doing stuff with printf. Then reading user input with scanf. It clicked pretty early for me, and I loved it.
From there on I was always learning faster and more at home as a hobby, I was mostly ahead in school. A friend and classmate and I coded so many different projects during that time (2D terminal game, PHP forum, PHP CMS that was actually productive for a few years, thereby also learning how the internet worked).
It's just crazy how lucky I got to be interested in this thing at the right time. "Back then" I feel you got so much more time to learn something well, mostly because things weren't changing at crazy speed.
I'm trying to make localhosting (https://thelocalhostinger.dev/localhosting) a thing. It's about finding ways to strip away unnecessary complexity of selfhosting in very specific edge use cases.
I like to think of test coverage as a negative indicator, i.e. if coverage falls below some defined percentage, it's a bad sign. But it doesn't make sense to optimize for that metric, because, as you said, you can have 100% test coverage but every single test can be bad.
I've always wanted to spend some more time on mutation testing, which can be used to improve test quality instead of just focussing on quantity. But I found it to be completely irrelevant in the industry so far.
Interesting! It's nice to see people are experimenting with these, and I wonder if this kind of junk data generators will become its own product. Or maybe at least a feature/integration in existing software. I could see it going there.
I too was shocked when I saw the $1.7billion bill, instead of the usual $1.5billion.