Hacker News Reader

Comment by myaccountonhn | Hacker News Reader

Recently gave htmx a spin. It is absolutely bananas how much complexity it removes and how much more productive you become as a result. The fact that you can use whatever stack you want is also such a blessing. I tried it with ocaml + web components and it’s a 10/10 super productive experience. Only need one build tool that compiles faster than I can blink, no wiring needed between frontend and backend to map json, it is just insanely productive.

View on HN

I took a close look at htmx, and my impression is that the problems it addresses can be resolved with even fewer than its 4000 lines of JS [1], and without having to familiarize myself with its many opinionated approaches. The crux of the matter is to generate HTML on the server, as much as possible. I know how to achieve that without htmx.

The marketing materials for htmx are also a bit off-putting to me, and the authors seem to be enjoying fueling the flames of old and useless holy wars about what REST and hypermedia "actually" are, and how we all need to get back to basics, and remember to thank Ted Nelson before every meal, etc. Their online book spends something like 30 pages explaining what hypermedia is... [2]. I prefer not to sign up for a religion when I choose a JS framework (honestly, that's a bit hard these days :-/).

1: https://github.com/bigskysoftware/htmx/blob/master/dist/htmx...

2: https://hypermedia.systems/hypermedia-reintroduction/

From where I sit, I welcome the opinionated approach. I don't need my presentation layer to be industry defining. Htmx allows me to quickly make pages in a way that has never been simple for me using other frameworks. I am primarily a backend engineer though. Maybe there is some glaring weakness that I am missing, but I have yet to find something simpler for my needs.

i don't think htmx is very opinionated: it generalizes hypermedia controls in HTML and that's about it. No strong opinions on how you use it beyond that, can work reasonably well w/ any back-end that produces HTML. The goal is to expand the set of UI use cases that can be cleanly expressed in HTML w/o resorting to (user) scripting.

Yeah, htmx is 3800 LoC, and you could do an 80/20 version of it for a lot less, but there are a lot of details to get right: history, collecting inputs, etc. plus, since it's a general purpose library, it has an extensive event system, extension mechanism, etc. There isn't a ton of dead weight to drop, although 2.0 should be smaller as we drop some bad ideas in 1.x.

I don't care too much about the holy wars around REST, I found them off-putting back in the day before I really understood the concept, but I am passionate about the uniform interface and communicating to developers why that was interesting and different. I do go a bit hot at times, especially at twitter, but, on the other hand, if I didn't, would you have ever heard of htmx? I try to balance that all out w/ reasonable essays and the book, which, I think, is worthwhile for most web developers to read (it's free online.)

My tone was a bit strong—my bad! I appreciate your thoughtful response. I must add I realize running an OSS project and writing a book is a massive effort. Big respect for not just sharing ideas but actually implementing them.

no problem at all, i get that htmx isn't for everyone and certainly that the shitposting can be a bit much at times. i appreciate your comment!

Reply on news.ycombinator.com