Even though JS is ubiquitous and small, well written JS is harmless, I still try to avoid it like the plague. Maybe just to somewhat fight back against all the excessive JS that plagues every site.
htmx
71–80 of 291 posts
Re: htmx
#72I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well…
I write plenty of JS (12% of my biggest project, according to GitHub), but it's added onto HTML in such a way that the HTML still works for:
* a security-minded person who has it turned off in their browser,
* a user of a browser without JS support, such as Links, Lynx, w3m, Dillo,
* someone with an older device using NoScript for performance reasons,
* someone with a slow network connection who can't load the included library,
* a server operator who chooses to disable JS rendering/injection and serve plan HTML, such as the website for a Bitcoin conference,
* another scenario I haven't even thought of or imagined yet.
My conscience as a developer and enabler of information access just does not allow me to write off all these people as undeserving of accessing my websites. You may feel differently, and I think that is OK, too...
Re: htmx
#73My problem with this approach is the same one raised by Dijkstra against the goto statement. These update actions are too unrestricted and don't offer any way to analyze the program's progress systematically, based on the program source code.
On our most recent project we do the same with Django and HTMX. Organized endpoints by component. Composable, reusable server-side components with django-components [1]. And we’ve been orders of magnitude more productive, shipping more in 1-2 months than we did the previous 12-18 months working with React.
Re: htmx
#74My problem with this approach is the same one raised by Dijkstra against the goto statement. These update actions are too unrestricted and don't offer any way to analyze the program's progress systematically, based on the program source code.
Could you elaborate? Genuinely curious.
Upvote
Well where is this notification-bar? It could be anywhere on the page. Maybe it was introduced by another htmx action from another endpoint. Answering this simple question could take a lot of work. There is no way to work it out systematically short of auditing every interaction on the page.Re: htmx
#75Re: htmx
#76Are people driving the tools?
Or are the tools binding people?
Re: htmx
#77Re: htmx
#78Earlier quoted context omitted.
htmx isn't about avoiding JS, it's about removing arbitrary limitations from HTML that have elsewhere been circumvented with JS. Users write less JS as a side effect of having an actually useful, modern "HTML", and with any luck the core features of htmx will eventually make it into standard HTML
That makes no sense, HTML is by design not supposed to be dynamic, that's the point of JS. There's a nice, clean, separation of concerns with HTML, CSS, and JS. As an aside, htmx uses JS under the covers to make HTML dynamic.
HTMX effectively used js for a polyfill of potential html standards, very similar to using babel or postcss to prototype a proposed spec.
Re: htmx
#79Ah yes…the daily htmx post
Re: htmx
#80Earlier quoted context omitted.
htmx isn't about avoiding JS, it's about removing arbitrary limitations from HTML that have elsewhere been circumvented with JS. Users write less JS as a side effect of having an actually useful, modern "HTML", and with any luck the core features of htmx will eventually make it into standard HTML
That makes no sense, HTML is by design not supposed to be dynamic, that's the point of JS. There's a nice, clean, separation of concerns with HTML, CSS, and JS. As an aside, htmx uses JS under the covers to make HTML dynamic.