Let's make the worst Htmx • Hacker News Board

Re: Let's make the worst Htmx

#81

Post by AlexeyBelov » Tue, Aug 04, 2026, 7:05 AM UTC

ironmagma wrote: post #74

AlexeyBelov wrote: post #73

Earlier quoted context omitted.

How does this answer the question? I cannot imagine an internal monologue going like this: - Hm, maybe I should use react for this - ok, why react? - because the news of frontend's death has been overstated ???

- Why would you pick $backend technology? - Because someone told me frontend was dead.

But that's a different question and a different situation. Logically this is unsound.

Go back to the grandparent comment, it doesn't ask why you'd choose a backend tech, the whole subthread is about frontend tech.

Re: Let's make the worst Htmx

#82

Post by masfoobar » Tue, Aug 04, 2026, 10:05 AM UTC

cpburns2009 wrote: post #80

masfoobar wrote: post #79

Earlier quoted context omitted.

Sounds like you are going through similar struggles as a few backend developers I had trying out htmx. Years of muscle memory with returning JSON and letting the frontend (javascript/jquery) to handle the html. They were making a big deal with this change. In the end the change is rather minimal. The outcome is reduced javascript code and more server side html templates. Pretty much most of the code is now handled on…

By wiring up hooks I just mean binding a callback to a button that calls fetch() and processing the response (usually replacing HTML, but may modify content and classes on other elements). Basically what I'm looking for is being able to specify a callback (ideally just a global name set from HTML) that will be called with a response object when JSON is returned. I prefer most coding to happen server side, but sometim…

But you can do this with htmx by using the respected hx-* attributes.

For example, on button click to GET html. Again, you can specify what you want to do with the returned html with attributes such as hx-swap

Unless I am misunderstanding, of course.

I do remember triggers/hooks with things like Angular and Knockout. I don't miss this method of web development.

I recommend starting small and working up with htmx. Their examples section on the official website is pretty good.

Re: Let's make the worst Htmx

#83

Post by ironmagma » Tue, Aug 04, 2026, 7:26 PM UTC

AlexeyBelov wrote: post #81

ironmagma wrote: post #74

Earlier quoted context omitted.

- Why would you pick $backend technology? - Because someone told me frontend was dead.

But that's a different question and a different situation. Logically this is unsound. Go back to the grandparent comment, it doesn't ask why you'd choose a backend tech, the whole subthread is about frontend tech.

No it's not. HTMX is a backend tech; it hinges on moving your presentation logic from the frontend into the backend, hence the whole hype about it supposedly obviating React.

Re: Let's make the worst Htmx

#84

Post by masfoobar » Wed, Aug 05, 2026, 9:46 AM UTC

ironmagma wrote: post #74

AlexeyBelov wrote: post #73

Earlier quoted context omitted.

How does this answer the question? I cannot imagine an internal monologue going like this: - Hm, maybe I should use react for this - ok, why react? - because the news of frontend's death has been overstated ???

- Why would you pick $backend technology? - Because someone told me frontend was dead.

I am one of those 'htmx lovers' but I do not comment that is the be all to end all.

Every website you create, just like any form of application, is based on solving a particular problem. How you solve that problem can vary from dev to dev. Some devs may disagree you your solution just as you can disagree with theirs.

I do stand that htmx can be used to solve a good chunk of problems that otherwise would be done with React, or angular, and so on. Personally, I think htmx makes the problem easier to solve. Well, once you get over the learning curve of the htmx way.

To be able to build a website or SPA without writing much client code (JS, etc) is a win in my book. You don't need a dedicated front end team for larger sites. Also, the designer/UX team (if you have one) can focus on the server-side template system.

Regardless - frontend is not dead. htmx, afterwall, is written in Javascript. htmx doesn't stop you writing javascript code. It's just I hardly need it for business logic. If anything it might be used to compliment CSS.

Would I use htmx if writing a web-based game? probably not. I guess it would depend. I would assume I'd be writing a fair be of javascript for WebGL-based rendering and typical update logic (input, physics, health, etc)

Maybe WASM is a better choice in this domain. I don't know.

Re: Let's make the worst Htmx

#85

Post by masfoobar » Wed, Aug 05, 2026, 10:11 AM UTC

cyanregiment wrote: post #56

vb-8448 wrote: post #52

Earlier quoted context omitted.

If I have to build something that is basically logic on backend, forms, tables, some static pages, some interactivity here and there(btw is what most of the sites and web apps out there are) I don't need 3d or game engine capabilities ... And no way react is going to be faster for the above use case. You miss the point of tools like htmx/datastar/turbo/unpoly/alpine, they are not a react competitor in the rich and co…

HTMX makes it hard to build even basic things, because it swaps entire HTML forcing a full repaint. That's the foundation of how it works. Examples include user highlighting text - swap wipes that out. Or user mid scroll through a menu, the scroll is reset to the top. It's not enough in HTMX to just break it down into smaller components, the scrolling part is native to the browser, so is text selection. Some people f…

> HTMX makes it hard to build even basic things, because it swaps entire HTML forcing a full repaint. That's the foundation of how it works.

I 100% disagree with this comment.

Lets make this clear, htmx does not swap 'entire html' - you have control to refresh whatever section of the page. That is not a full repaint.

I am beginning to wonder what tests you have done in htmx before making such a verdict.

Yes - I break my Views into "small components" - I guess it's better to say I create a lot of Partial Views. I follow a simple 'where there's one, there's many' mindset. All Partial Views are designed to return an array, even if what I need is a single record.

> Examples include user highlighting text

I've written an Application (in htmx) that has a text area for sentences. There is 'compile' function that breaks down the sentence, colouring specific words/phrases. How does it do this? htmx! It sends it back to the server-side and builds the sentence.. returning back the html with coloured texts and other meaningful attributes. It overwrites that section of the screen. It is light and fast!

The great thing is all validation and html rendering is done of the server-side. No code duplications or anything.

Now, this is perfectly fine for what I am doing. However, the text is barely no more than 30 words. If I was trying to write a text editor the we have a different type of problem. If using htmx, would likely work it out to update a portion of the editing code, perhaps per line. This would move it away from using a text area.

> Or user mid scroll through a menu, the scroll is reset to the top

I believe, with the text solution I mentioned above, I also pass it the cursor position. As we are processing the text, any changes may move the cursor - so I let the server-side handle it. This is great because the functionality written is not designed for just the web - but any 'text area' in any GUI!

From memory, with some javascript, I managed to return to the caret position once the html section was refreshed. I cannot remember 100% how I did this as I do not have access to the source code.

> On game dev: I think it's good...

I've already commented about game dev and htmx. I will paste that section here:-

Would I use htmx if writing a web-based game? probably not. I guess it would depend. I would assume I'd be writing a fair be of javascript for WebGL-based rendering and typical update logic (input, physics, health, etc)

Maybe WASM is a better choice in this domain. I don't know.