Live data from Hacker News

htmx

htmx.org

71–80 of 291 posts

Re: htmx

#71
I personally don't see the utility in this too much, but then I'm old fashioned and go out of my way to use as little JS as possible, doing everything via CSS as much as I can.

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.

Re: htmx

#72

I 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…

It's not that I avoid JavaScript, it's that I want my work to be accessible to someone without JS as a requirement, for whatever reason they may be in that state and configuration, whether by choice or not.

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

#73
post #15

My 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.

The same can be said of a React frontend that talks to a JSON API. There is some structure, organization, and convention to the API endpoints, one-way data flow, and so on. Otherwise it’s chaos.

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.

[1] https://github.com/EmilStenstrom/django-components

Re: htmx

#74
post #42
post #15

My 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.

let's say that you have an upvote button

   
     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

#75
I love htmx and have used it to build internal tools quite successfully. It allows me to work in my preferred language on the backend, write some basic ass html and spinkle in a few attributes and get some frontend reactivity that I otherwise wouldn’t have because I hate Javascript.

Re: htmx

#76
Learning to use any new tool comes at a time cost, and if I learn this and then a newer, more convenient tool emerges that can replace it, I get stuck in the question.

Are people driving the tools?

Or are the tools binding people?

Re: htmx

#78
post #14

Earlier 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.

Where in the spec for html did it specify that it's isn't meant to be 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

#80
post #14

Earlier 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.

A lot of htmx is just a smoother version of what people used to do with forms and iframes.
Post reply on HN