3 ms·
It is clear that htmx has a growing community, but it still feels a bit too backend-minded to convince frontend developers to adopt it. I tried it in a prototyp
by mtrovo 2y ago
It is clear that htmx has a growing community, but it still feels a bit too backend-minded to convince frontend developers to adopt it. I tried it in a prototype, and it was quite pleasant until I realised I needed to account for additional state management and backend wrangling to be able to provide some dynamic features. That was the moment I realised htmx is not a fully fledged product but rather a core feature that sits neatly atop a traditional server-driven setup.
That's why I think their roadmap looks right. I believe the way to broader adoption is to improve tooling, encourage standardisation, and integrate htmx more closely with well-known frameworks. That's the only way I can see dev teams buying into the paradigm change and htmx jumping into mainstream usage.
- rednafi 2y agoThe idea is to have fat backends and dumb clients. It’s definitely a different way of building things and not everyone’s cup of tea. For me, the biggest selling point is getting to write less JS. Writing the bulk of the logic in Go, Python, Kotlin, Rust, or Zig is a huge plus, as I consider them better-designed languages with easier maintainability.