Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please just try HTMX

pleasejusttryhtmx.com

Post reply on HN
Print view View original

101–110 of 530 posts

Re: Please just try HTMX

#101

Post by liampulles »

I like HTMX, I use it on my blog. But I will say, in the niche where I need some dynamic DOM changes without needing a full-blown SPA, raw JavaScript with some basic utilities like jQuery is not so bad.

The issue with htmx is that it is fairly prescriptive of how one should go about building dynamic interactions, and it becomes complex quickly if the dynamic interaction is more than trivial. I don't disagree with its philosophy at all (as I say, I use it for my own site) but it becomes an issue when my product owner tells me that I need to do some funny dynamic thing because it will make the business or clients happy (for some reason), and then it becomes a mission to wrangle it with htmx attributes. And I have to follow that, because as much as it pains me to say it, making stuff pretty and dynamic on the UI is an easy way to score points. It is one of those areas of enterprise software development which seems like a huge upgrade to non-technical people whilst not requiring too much effort.

The one thing raw JavaScript is quite well suited for is hacking together some DOM manipulation. I dislike JavaScript in every other domain except this - its in this arena where its leniency is very useful.

Re: Please just try HTMX

#102

Post by 0x3f »

ajross wrote: post #68
0x3f wrote: post #16

The thing is React is usually fine, and even if you don't have to build _this_ thing in React due to simplicity, why bother learning two paradigms when you can just use the heavier one for everything and most likely never encounter any real practical showstopping issue?

> you can just use the heavier one for everything Because people don't like using heavyweight solutions needlessly. That's the logic that begat C++ and Ada and Multics and ASN.1 and CORBA. All of which were good solutions useful for "everything" in their domain. But people hate them, mostly. Historically big "everything" solutuions end up losing in the market to lighter weight paradigms with more agility and flexibil…

The thing is most of us have jobs where we can't unilaterally switch to the 'cooler' solution, and I value my own context-switching overhead much more than I value a slightly smaller bundle or dep tree. I'll much sooner optimize the former than the latter and so the general purpose solution that will solve both my own projects and the work ones typically wins.

Re: Please just try HTMX

#103

Post by librasteve »

recursivedoubts wrote: post #29

Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…

HTMX Sucks

https://htmx.org/essays/htmx-sucks/

Re: Please just try HTMX

#104

Post by nicolaslem »

furyofantares wrote: post #61

> "I'm not a fucking saint" You're not a fucking person, this is LLM output. It starts with the overdone sweary thing then mentions it's overdone and says it's not gonna do it, and it's almost enough to make me think the article is going to offer someone's point of view. But once again the LLM has erased any point of view the author may have had going in (or prevented them from developing it) and replaced it with a m…

I don't think this is straight LLM, it's probably an homage to a line of websites like https://thebestmotherfucking.website

Re: Please just try HTMX

#105

Post by jacobsenscott »

I haven't used htmx, but I've given turbo a fair shake. I've only worked on server side rendered apps for my whole career, and they are generally they way to go. But just like react, or anything else, you throw enough engineers at it and it becomes a mess. But also you'll only find a handful of engineers who understand it compared to react, so that makes it worse. I think the bottom line is creating web UI is just as unsolved today as it was 20+ years ago, and nobody can make any headway - it suggests the fundamentals are totally wrong - after all - this isn't what http and html were even built for.

Given sufficient time and money (20+ years, and billions (trillions?) of dollars - which is what we've thrown at web apps) you could build GUI apps using the IRC protocol, but it will never work well.

LLM generated code probably tips the scales toward using react though. You can have the bots churn through all that boiler plate, it won't be any worse than what human react devs write, and keep the bots away from your mission critical code because it isn't all munged together like in a SSR app.

Re: Please just try HTMX

#106

Post by catapart »

purerandomness wrote: post #23
catapart wrote: post #7

Sorry, but it's a no from me. htmx is a great idea, but it's not necessary anymore. We're very close to invokers being baseline (and even that is just an extension of the "composedPath includes -> invoke" pattern), and that will take care of plenty of what htmx was designed to do. Between features like that, and web components, I'm very happy to stick with "plain HTML" (no frameworks; my web components do not draw fr…

> We're very close to invokers being baseline Well why not have the benefits of invokers, but today - with HTMX? HTMX could eventually switch its implementation to use invokers under the hood in the future, and you'd have the convenience of using declarative behaviors on your buttons, today. > autocomplete can actually be fulfilled with a datalist element I wish that the spec would cover more use cases, but last time…

> Well why not have the benefits of invokers, but today - with HTMX?

Because I already have the benefit of invokers, today, using the composedPath method. And a map to some functions is usually less, in my experience, than 14kb of js.

Re: Please just try HTMX

#107

Post by dubcanada »

perardi wrote: post #60

I did. My startup did. And now we’re going to rip it all out and move to a React front-end. HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads. And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a…

Just to be completely clear... you do not need React just so you can turn JSON into HTML. HTMX can 100% can do that.

You're argument is fine assuming you wish to become another react frontend in a sea of react frontends.

But the documentation example is a terrible argument, the benefit of HTMX is it is easy to understand what is actually happening. There is no magic, you don't need to dive through millions of lines of code to figure out what this is doing like react. It's very basic javascript. Just read the library, frankly you don't even need any documentation. Just take 15 mins and read the entire library.

Re: Please just try HTMX

#108

Post by recursivedoubts »

librasteve wrote: post #103
recursivedoubts wrote: post #29

Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…

HTMX Sucks https://htmx.org/essays/htmx-sucks/

so true

Re: Please just try HTMX

#109

Post by stefan_ »

ErroneousBosh wrote: post #88
stefan_ wrote: post #80

Earlier quoted context omitted.

It's terrible, why would I want my endpoints to return random HTML fragments? I realize thats how you did it in the JQuery times, but I was never in those - at that time we simply had template engines in the backend so this HTML slop wouldn't contaminate everywhere.. Most of the frontend stuff I do is for internal pages on embedded devices, and I'm very happy with a structure where I have the frontend being a full Re…

> It's terrible, why would I want my endpoints to return random HTML fragments? What would you return instead? It's easy to generate HTML, because that's what your server is already generating (and that's about all it should generate).

HTML is the last thing I would ever want to generate on my embedded device, it's a terribly verbose string-based mess invariably coupled with stylistic choices. Which is why my servers don't generate any of that, they serve static files - and any interactive information in something that looks a lot more like an interface definition.

Re: Please just try HTMX

#110

Post by elevation »

asim wrote: post #6

Man I did try htmx, and I was hopeful, right until I saw how it polluted my codebase. I can't say I have the answers, but writing a pure Go app, I'm currently using one giant css file, custom styling and inline html. And now I'm at the breaking point. So I'm planning to move to tailwind and Go templates, but honestly, i was hopeful for htmx, so I need to properly see the usecase. Which i don't know is this. It remind…

> it polluted my codebase

HTMX is less noisy if you integrate it into your backend framework.

A contact of mine build a python/flask app. To simplify coding, he wrote a file to extend the flask framework to support the HTMX patterns he needed with just a single line of boilerplate. Took him about a day, his team is happy with the results.

Post reply on HN