Live data from Hacker News

Htmx 2.0.4 Released

github.com

131–136 of 136 posts

Re: Htmx 2.0.4 Released

#131

Tried Htmx a while back... mixed feelings. Love how easy it is to get basic interactivity—honestly, adding a filter or an upvote button in a couple of lines of HTML feels like magic. No messing with a frontend framework, no bundlers - just works. But I hit walls when I needed more complex stuff. Like, if I want to keep state on the client (e.g., a live calculator or sliders updating a table), Htmx feels clunky. Sendi…

Wait, why do I need React for a live calculator or sliders updating a table? Does plain JavaScript and the Web APIs no longer exist? Don't Web Components/custom elements exist? I need to immediately jump to React/Vue/etc. at the slightest bit of client-side interactivity?

Also, do people just update and yeet their apps into prod without testing it? What happened to test environments? Test suites? Manual QA? Letting it soak? Where did quality control go?

Re: Htmx 2.0.4 Released

#132

Earlier quoted context omitted.

I tried HTMX but found it too restricting. It's great if you just want to load a portion of the page. Maybe if you have an up-vote, just send the request and replace the icon with a gold icon. But I want things like an on-site calculator. I load in products and prices, users can adjust sliders to change the quantity and relevant number is calculated. I don't want to use HTMX for this to call the server each time, I w…

> when the user has tweaked as necessary they can just check out. And what happens after the user spent all that time adjusting their order, submits it, and then is told at the very end that some items are out of stock? Do you think they're going to be happy about that? What if their browser crashes and the order they had built up carefully is lost? Will they bother to try again? Will you do price calculations proper…

Appreciate the concerns but they're non issues.

Stock doesn't matter for my case.

The browser has storage options to handle close and reopens.

Prices in each currency are all in ints (i.e. cents) to avoid float issues.

There are problems to address on either end that you have to be aware of.

Re: Htmx 2.0.4 Released

#133

Earlier quoted context omitted.

> when the user has tweaked as necessary they can just check out. And what happens after the user spent all that time adjusting their order, submits it, and then is told at the very end that some items are out of stock? Do you think they're going to be happy about that? What if their browser crashes and the order they had built up carefully is lost? Will they bother to try again? Will you do price calculations proper…

Appreciate the concerns but they're non issues. Stock doesn't matter for my case. The browser has storage options to handle close and reopens. Prices in each currency are all in ints (i.e. cents) to avoid float issues. There are problems to address on either end that you have to be aware of.

Good to know that it's not an issue in your case but just a reminder that your specific case is, by definition, not generalizable. These are problems that exist in general and have to be solved or prevented in some way. For example, you found some solutions that work for you but they won't for everyone.

Re: Htmx 2.0.4 Released

#134
post #70

Earlier quoted context omitted.

Is this supposed to be a joke? If it is... it isn't funny. If it isn't... Maybe it's time to face the fact that you're very wrong about this...

Tell me I have autism without....

Tell me I'm rude and that I don't understand what autism is without...

Re: Htmx 2.0.4 Released

#135
I have several problems with htmx, and none of them are love of React or the thousands of NPM modules that make up most modern frontends today. I'm also not a fan of JavaScript itself, and I don't write Node backends unless I can't avoid it.

The main problem I have with htmx is it requires my backend and frontend to be uncomfortably coupled. I write most of my backends in Go these days, but I've written a lot of Java and PHP in the past. I particularly hate PHP and the model of mixing backend logic and presentation markup. I'm not a fiend when it comes to separation of concerns; I try to keep relevant things together. With that said, constantly bundling markup with actions is annoying. For example, POSTing a comment would require the backend to send back the new comment's HTML, then possibly perform some action like bumping off comments that are too far down.

The other big problem I have with htmx is that it has no good solution for managing state and staying consistent with the backend. I used to work on a site written in PHP that, while not using htmx, used generally the same system of returning HTML from ajax calls. I was working on implementing comment replies, which required not only appending a new comment, but changing some of the markup on the original comment to indicate that it had replies and a button to collapse those replies. The solution I chose for this was to make those changes to the original comment dynamically with raw JS, then append the HTML for the new comment returned by the server. This worked fine, but it was annoying because I had to replicate rendering logic in both JS and PHP. This kind of thing can easily become death by a thousand papercuts as your site grows and you have more and more duplicated rendering code. This problem does not exist in the Vue/React/etc. world.

There is value in keeping all your rendering in one place, even if that place is the server and access to it requires enduring network latency. I understand why someone who uses a language other than JS for backend would enjoy htmx, but I think it's going to bite its users in the ass one day or another when their application becomes too big and rendering logic becomes hard to maintain.

I would say my favorite alternative to htmx for people who want statically rendered pages but don't want to go without niceties like components, JS type checking, reactivity and other things that speed up frontend development and make it more scalable is Inertia.js. It allows you to use a JS frontend framework like Vue or Svelte and the backend of your choice without having to write an API or (god forbid) GraphQL. https://inertiajs.com/

I've also found that petite-vue is great for adding progressive enhancement to otherwise static sites without using a bloated framework. I've used it in several contract projects and it works like a charm. https://github.com/vuejs/petite-vue

Re: Htmx 2.0.4 Released

#136
post #135

I have several problems with htmx, and none of them are love of React or the thousands of NPM modules that make up most modern frontends today. I'm also not a fan of JavaScript itself, and I don't write Node backends unless I can't avoid it. The main problem I have with htmx is it requires my backend and frontend to be uncomfortably coupled. I write most of my backends in Go these days, but I've written a lot of Java…

yes, hypermedia couples things at the application layer, but decouples at the network architecture level:

https://htmx.org/essays/two-approaches-to-decoupling/

htmx uses Hypermedia As The Engine of Application State:

https://htmx.org/essays/hateoas/

The problems you have had appear to be addressable using techniques outlined here (from least to most complicated):

https://htmx.org/examples/update-other-content/

Of course, there are going to be applications and features that the hypermedia approach are good or not appropriate for, I try to outline those situations here:

https://htmx.org/essays/when-to-use-hypermedia/

I think you could build an excellent comments system using htmx if you wished to.

Post reply on HN