4 ms·
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 appr
by tbatchelli 2y ago
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 2y agoWhy is the added complexity of running HTMX better than the complexity of an SPA?
- rednafi 2y agoBecause 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 2y agoNone of those languages can do anything in the browser.
- preisschild 2y agoWith HTMX they can, because they make server rendered pages more viable.
- robertoandred 2y agoWhen someone swipes a carousel, how will C# update the dom attributes and labels on the fly?
- preisschild 2y agoFor stuff like this you can always complement HTMX with stuff like Hyperscript [1], also from the htmx authors or AlpineJS [1]: https://hyperscript.org https://hyperscript.org
- recursivedoubts 2y agoit is sometimes much lower, if it fits your use case: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/