Let's make the worst Htmx • Hacker News Board

Re: Let's make the worst Htmx

#51

Post by cyanregiment » Sat, Aug 01, 2026, 2:15 PM UTC

vb-8448 wrote: post #50

cyanregiment wrote: post #43

HTMX is amazing on paper, not in real life. It loses things like scroll position and text highlighting on re-render - it’s not high performance like React. This is for server sided or static web pages not building rich UI. There is no robust state management or DOM performance improvements you get with React with larger components. HTMX team should build a game with it. Load some 3D in WebGL/WebGPU, showcase high per…

> HTMX team should build a game with it. Load some 3D in WebGL/WebGPU, showcase high performance UI. Why? Why you'd pick htmx (or even reactjs?!?) to build a game?

Because I would need to see a UI paradigm prove it can handle performance before considering using it for UI.

react-three-fiber solves a lot of problems. React state is also perfectly in line with game loop architecture, r3f unifying the Three.js/React render loop is incredibly good for game dev.

But even for SaaS or whatever, I need to know that it can handle complex states of the UI - HTMX can't.

They are overselling it. It's not really a competitor to React, it's more like a competitor to Jade templating or HAML which nobody already uses anymore.

Re: Let's make the worst Htmx

#52

Post by vb-8448 » Sat, Aug 01, 2026, 3:00 PM UTC

cyanregiment wrote: post #51

vb-8448 wrote: post #50

Earlier quoted context omitted.

> HTMX team should build a game with it. Load some 3D in WebGL/WebGPU, showcase high performance UI. Why? Why you'd pick htmx (or even reactjs?!?) to build a game?

Because I would need to see a UI paradigm prove it can handle performance before considering using it for UI. react-three-fiber solves a lot of problems. React state is also perfectly in line with game loop architecture, r3f unifying the Three.js/React render loop is incredibly good for game dev. But even for SaaS or whatever, I need to know that it can handle complex states of the UI - HTMX can't. They are overselli…

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 complex web apps space. They fill a gap between the native browser capabilities and tools like react/vue/svelte/ecc.

Re: Let's make the worst Htmx

#53

Post by andersmurphy » Sat, Aug 01, 2026, 3:24 PM UTC

JSR_FDED wrote: post #48

Aeolos wrote: post #32

I highly recommend everyone to give htmx or datastar a try, especially if your main experience is react or nextjs. We recently rewrote a half-million LOC codebase from react to datastar, with a detour through htmx first, and the results are staggering . First page load is 20KB down from a 750KB js bundle. 1 network request vs 40+. Total load time 0.1 seconds down from 2 seconds of spinners. Page refresh is so fast, t…

I’m getting about 800:1 compression with Brotli. I wonder if need to tune anything? Although tbh I have no performance issues at all. It took me a minute to change my mindset to Datastar’s way of doing things. But it’s been amazing. Firstly to keep 99% of the state and logic on the back end is just so nice - no more having to deal with two sources of state at the same time (front end and back end). Secondly the abili…

So compression ratios with streaming compression (brotli/zstd) come down to the regularity of the data, the size of the change, and the size of your window.

Basically, if your html fat morph frames are 65kb uncompressed and you make a small change like checkbox it will send 13bytes so that's 5000:1. Caveat is as long as your compression context window is big enough.

Re: Let's make the worst Htmx

#54

Post by Aeolos » Sat, Aug 01, 2026, 3:28 PM UTC

halfcat wrote: post #45

Aeolos wrote: post #32

I highly recommend everyone to give htmx or datastar a try, especially if your main experience is react or nextjs. We recently rewrote a half-million LOC codebase from react to datastar, with a detour through htmx first, and the results are staggering . First page load is 20KB down from a 750KB js bundle. 1 network request vs 40+. Total load time 0.1 seconds down from 2 seconds of spinners. Page refresh is so fast, t…

How do you debug SSE messages since they don’t show up in chrome dev tools with Datastar?

You either buy a datastar license to get their debug tools, or you spend a couple of hours to build your own. I'm sure you can find something on GitHub too.

One of the cool things is how extensible d* is. Everything is a plugin, and you are free to extend it to suite your needs. We've invested a few days building a few specific data-* attributes for our application and it's super convenient.

Re: Let's make the worst Htmx

#55

Post by Aeolos » Sat, Aug 01, 2026, 3:34 PM UTC

vb-8448 wrote: post #52

cyanregiment wrote: post #51

Earlier quoted context omitted.

Because I would need to see a UI paradigm prove it can handle performance before considering using it for UI. react-three-fiber solves a lot of problems. React state is also perfectly in line with game loop architecture, r3f unifying the Three.js/React render loop is incredibly good for game dev. But even for SaaS or whatever, I need to know that it can handle complex states of the UI - HTMX can't. They are overselli…

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…

Having used both in anger, I find d* has a lot of very real advantages over react if you care about performance and application stability.

It's simple enough that you don't need training or lengthy guides about "the rules of books etc".

It's small enough that an LLM can store the entire thing in context and answer your questions.

And it doesn't npm or a build step.

Re: Let's make the worst Htmx

#56

Post by cyanregiment » Sat, Aug 01, 2026, 3:38 PM UTC

vb-8448 wrote: post #52

cyanregiment wrote: post #51

Earlier quoted context omitted.

Because I would need to see a UI paradigm prove it can handle performance before considering using it for UI. react-three-fiber solves a lot of problems. React state is also perfectly in line with game loop architecture, r3f unifying the Three.js/React render loop is incredibly good for game dev. But even for SaaS or whatever, I need to know that it can handle complex states of the UI - HTMX can't. They are overselli…

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 forget or don't know how much an SPA library like React is doing to prepare the SPA before you get into any of the organizational framework usage. Beyond that, clever engineering went into React DOM reconciliation in particular that I rarely see challenged in other libraries.

On game dev: I think it's good for a showcase because it shows the limits of what it could do at 60+ fps in a performance intensive environment. But yeah, even a complex SaaS demo would do.

> They fill a gap between the native browser capabilities and tools like react/vue/svelte/ecc.

Have not heard that yet, since a big part of HTMX is manipulating the DOM and binding events. I'm pretty sure this is not correct

Re: Let's make the worst Htmx

#57

Post by Rohansi » Sat, Aug 01, 2026, 4:09 PM UTC

cpburns2009 wrote: post #47

deadbabe wrote: post #15

Earlier quoted context omitted.

Who is worrying? If JavaScript is on the front end the supply chain attacks are really not your problem.

The supply chain attacks you need to worry about come from using npm.

No, it's not specifically npm. All package managers enable remote code execution by design - you tell it to download code and then you run that code, likely without sandboxing, by using it. Most people are not inspecting the code before they download and run it. You will still see compromised packages making their way through npm even though they disabled install scripts.

Re: Let's make the worst Htmx

#58

Post by vb-8448 » Sat, Aug 01, 2026, 4:40 PM 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…

> Have not heard that yet, since a big part of HTMX is manipulating the DOM and binding events. I'm pretty sure this is not correct

Did you ever open the htmx home page? Because it's at the very top in the "motivation" section!

I'm starting to wonder whether you're trolling or you have no idea what HTMX and similar tools actually do.

Re: Let's make the worst Htmx

#59

Post by cpburns2009 » Sat, Aug 01, 2026, 4:49 PM UTC

Rohansi wrote: post #57

cpburns2009 wrote: post #47

Earlier quoted context omitted.

The supply chain attacks you need to worry about come from using npm.

No, it's not specifically npm. All package managers enable remote code execution by design - you tell it to download code and then you run that code, likely without sandboxing, by using it. Most people are not inspecting the code before they download and run it. You will still see compromised packages making their way through npm even though they disabled install scripts.

I agree. I just pointed out npm because it's the most prominent javascript one.

Re: Let's make the worst Htmx

#60

Post by cyanregiment » Sat, Aug 01, 2026, 4:50 PM UTC

vb-8448 wrote: post #58

cyanregiment wrote: post #56

Earlier quoted context omitted.

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…

> Have not heard that yet, since a big part of HTMX is manipulating the DOM and binding events. I'm pretty sure this is not correct Did you ever open the htmx home page? Because it's at the very top in the "motivation" section! I'm starting to wonder whether you're trolling or you have no idea what HTMX and similar tools actually do.

Google result for "htmx with react"

"HTMX and React represent fundamentally different web development architectures, but they can be compared or even used together in a hybrid setup."

I see tutorials on how you can mix it with React for Next.js which might make sense at the page level because it's SSR.

Definitely possible, sure. But it would be about like mixing Angular with React where two libraries are competing for the truth of what's in the DOM.

There was a time Three.js "couldn't work" with React because they each had their own separate render lifecycles - but r3f happened with enough demand (and useFrame bridged the two beautifully).

Maybe the same will be true of HTMX, maybe people are actually trying to do that now for some reason, but yeah a lot would have to change with either React or HTMX to get value out of both simultaneously for UI.