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

251–260 of 530 posts

Re: Please just try HTMX

#251

Post by lbreakjai »

azangru wrote: post #162
librasteve wrote: post #103

Earlier quoted context omitted.

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

> No Jobs > Another practical reason not to use htmx is that there are, rounding off, zero htmx jobs. > I just did a search for htmx jobs on indeed and found a grand total of two: one at Microsoft and one at Oak Ridge National Laboratory. > A search for “react”, on the other hand, gives 13,758 jobs. > Seriously, developer, which of these two technologies do you want to hitch your career to? I do not advocated for htm…

I appreciate the idealism but I appreciate being able to pay my mortgage more.

Re: Please just try HTMX

#252

Post by WorldMaker »

CooCooCaCha wrote: post #85
mikepurvis wrote: post #69

Earlier quoted context omitted.

To put a bit more colour on this, I think the fear of most devs with an ultra-simple framework like this is that eventually you hit a wall where you need it to do something it doesn't natively do, and because the only thing you know is these magical declarative hx-whatever attributes, there's no way forward. I appreciate the basic demos, but I think what would really sell me is showing the extensibility story. Show m…

What I don’t get is why I’d use it if I can’t write a reasonable complex SPA with it. React is easy for small websites so why would I use a separate framework when I can use one framework for everything?

What's your decision tree for when you feel you need a SPA in 2025?

At least some of what you may not be getting in this space is how many developers right now seem to be hugely deprioritizing or just dropping SPA from their decision trees lately. Recent advances in CSS and ESM and Web Components such as View Transitions and vanilla/small-framework JS (ESM) tree-shaking/"unbundling"/importmaps give MPAs more of the benefits of a complex SPA with fewer of the downsides (less of a "mandatory" build process, smaller initial bundle load). It is easy to feel less of a need for "complex SPA" to be on your architecture options board.

Re: Please just try HTMX

#253

Post by yawaramin »

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…

Invokers don't give you what htmx gives you out of the box. If you want to, for example, have an invoker command to fetch a resource and swap it in to the page, you have to write custom JS for that. That's the thing that htmx gives you out of the box, along with error handling, progress indicator support, history support, animated transitions, and a host of other features.

If you don't need or want all these and are happy with the worse UX, then of course you don't need htmx.

Re your suggestion: datalist makes you select an option, then fills in an input with the value of the option. Then you have to submit the form to actually get the resource you just searched for. Active search gives you the links to the resources directly in the search results, so you can load them with one click. There's a big UX difference.

Re: Please just try HTMX

#254

Post by yawaramin »

catapart wrote: post #113
lunar_mycroft wrote: post #34

Earlier quoted context omitted.

> We're very close to invokers being baseline, and that will take care of plenty of what htmx was designed to do. From what I've seen, invokers without extra code are designed for client side interactivity (e.g. showing a modal), which is orthogonal to the (correct, IMO) use case of HTMX. You shouldn't use HTMX to turn every custom user interaction into a network round trip, you should use it instead of fetching JSON…

> You can add custom commands with invokes and custom JS, but at that point you're basically re-implementing HTMX yourself[...] Exactly. So why use a library? If it's that simple, the suggestion is akin to using a library for a toggle, when a checkbox would do. Yes, there are reasons to do it, but no, it's not what I'm going to do most of the time. ETA: sorry; I should have mentioned, I'm ignoring server stuff becaus…

Why use any library, ever? Why not just reimplement the wheel yourself every time then?

Re: Please just try HTMX

#255

Post by yawaramin »

rdtsc wrote: post #64

> The ecosystem is why your node_modules folder is 2GB. The And every months a few of those modules try to exfiltrate your credentials…

And execute commands remotely on your server, for example to install crypto miners...

Re: Please just try HTMX

#256

Post by adamzwasserman »

djeastm wrote: post #237
adamzwasserman wrote: post #181

Earlier quoted context omitted.

I was able to find architectural patters that work smooth as glass. Here is what my htmx apps have: - Single-purpose endpoints: Each endpoint returns ONE thing (a card list, a tag cloud, a form fragment) - Optimistic UI: Preferences like font/theme update the DOM immediately; the save is fire-and-forget with no response needed - Simple error handling: Most endpoints either succeed (return HTML) or fail (HTTP error co…

Please do a write up of the best practices you've found. I tried htmx a few years ago for a side project and while I appreciated the simplicity of a lot of it, I had trouble understanding how/when to use it and in what ways. I think I was trying to contort it too much into my understanding of api/spa. That or my interactivity needs were too complex for it, I can't tell. These days, I admit, though, the ship has saile…

That is what DATAOS.software is all about. It is a manifesto of my proposed best practices somewhat like Hypermedia Systems, but more hands on, more of a cookbook.

Re: Please just try HTMX

#257

Post by ErroneousBosh »

leoedin wrote: post #197
ErroneousBosh wrote: post #123

Earlier quoted context omitted.

Okay, so what do you your servers actually serve stuff to? I kind of don't get why if you want to display something in a web browser you'd generate anything other than HTML.

I think the parent's point is that when you have a react front-end, your back-end basically just deals in structs of data. There's no HTML or templating to think about. It's just JSON-serialisable structs. That makes the code on the back end much simpler, which makes it easier to run in a resource-constrained environment. The only exposure the back-end has to HTML is streaming the static files to the browser. Which c…

Okay, so how do you actually show the stuff to the end user?

Just raw structs of data? Or do you turn that back into HTML?

Now you've got two sets of templates to cope with...

Why would I care about how much effort it is for the server to generate? It's already generating HTML from templates, and it's more-or-less infinitely capable of doing so.

Re: Please just try HTMX

#258

Post by puppy_lips »

nrclark wrote: post #120
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…

fwiw I'm the CEO of htmx, and I am a huge fan of these types of hyperbolic articles.

I am starting to understand htmx.

Re: Please just try HTMX

#259

Post by yawaramin »

mvdtnz wrote: post #222

I haven't used HTMX but the author doesn't make a very convincing case. On the one hand they say, > "But what about complex client-side state management?" > You probably don't have complex client-side state. You have forms. You have lists. You have things that show up when you click other things. HTMX handles all of that. On the other hand, > I'm not a zealot. HTMX isn't for everything. > Genuinely complex UI state (…

Nope, in that case all you need is an htmx out-of-band swap to update two different parts of the page.
Post reply on HN