5 ms·
I like the idea and applaud the effort. But surely it's just abstracting and implementing Javascript and thus obfuscating the knowledge of how that works. I se
by ourcat 6y ago
I like the idea and applaud the effort. But surely it's just abstracting and implementing Javascript and thus obfuscating the knowledge of how that works.
I see this happen too often.
But then, some people know how to fix a car. Others don't even know how to pop the hood. And this sort of thing is likely why.
- jhardy54 6y agoOn one hand: sure, anything you can express with an abstraction can be expressed without the abstraction. Some abstractions are unnecessary. On the other hand: this introduces constraints that let you solve a class of problems without giving you so much rope that you can get tangled in it. I'm very wary of adding unnecessary abstractions, but I'm very optimistic for solutions like HTMX. Lately I've been trying to build apps without any front-end JS, and there are pain points that make me want to allow JS sometimes. My hope is that HTMX/etc might solve these pain points without opening up Pandora's box and letting contributors write arbitrary JavaScript for managing the front-end.
- ourcat 6y agoI agree. I'm less worried about abstractions than I am about dependencies. Which is why I use the foundational core knowledge to build my own solutions/modules. If I can.
- jhardy54 6y agoWould you target the same API, or invent your own?
- ourcat 6y agoI've just learned over the years that it can be ultimately painful to rely on a third-party API. For all sorts of reasons. I used the words "If I can" on purpose. So yes, if I could, I would invent my own. And the peace of mind, and hopeful reliability that can provide, can go a long way in your creative mindset.
- recursivedoubts 6y agoThere's more to it than that. It's an attempt to complete HTML as a hypertext and allow more complete, modern UI programming within the hypertext & REST/HATEOAS paradigm. Yes, it uses javascript to achieve this, but that's what's available.