[tbatchelli]

I value the hard stance on stability and backwards compatibility over the constant churn that some JS libraries/frameworks have. I understand the need both approaches, but this is a breath of fresh air.

I also happen to think that most web apps have no business being so complex, and that too much work goes into dealing with the added complexity of running SPAs where an SPA is not needed.

[robertoandred]

Why is the added complexity of running HTMX better than the complexity of an SPA?

[rednafi]

Because then I can keep the bulk of the logic in a language that’s better designed than JS. Not having to write JS is a huge feature. The added complexity of HTMX is abstracted behind a single library, and the bulk of the logic stays in a better-designed language—Go, Python, Java, Kotlin, Rust, Zig, C#, anything.

[robertoandred]

None of those languages can do anything in the browser.

[preisschild]

With HTMX they can, because they make server rendered pages more viable.

[robertoandred]

When someone swipes a carousel, how will C# update the dom attributes and labels on the fly?

[preisschild]

For stuff like this you can always complement HTMX with stuff like Hyperscript [1], also from the htmx authors or AlpineJS

[1]: https://hyperscript.org

[recursivedoubts]

it is sometimes much lower, if it fits your use case:

https://htmx.org/essays/a-real-world-react-to-htmx-port/