So, instead of using one JavaScript library with an entire ecosystem of tools that work together, you use two separate uncoordinated JavaScript libraries? Why do you think that's better?
Different libraries composing well together is the default assumption in most of software development. Only in Javascript have people given up on that and accepted that libraries don't work together unless they've been specifically designed, or at least given a compatibility layer, for the framework they're being used in.
Qt widgets don't work together with GTK widgets, and nobody considers this a crisis. I'm pretty sure you can't use Unreal engine stuff in Unity. GUIs require a lot of stuff to compose together seamlessly, and it's hard to do that in a universal way.
HTMX achieves its composability by declining to have opinions about the hard parts. React's ecosystem exists because it abstracts client-side state synchronization, and that inherent complexity doesn't just disappear. When you still have to handle the impedance mismatch between "replace this HTML fragment" and "keep track of what the user is doing", you haven't escaped the complexity. You've just moved it to your server, and you've traded a proven, opinionated framework's solution for a bespoke one that you have to maintain yourself.
If anything, the DOM being a shared substrate means JS frameworks are closer to interoperable than native GUI toolkits ever were. At least you can mount a React component and a Vue component in the same document. They're incompatible with each other because they're each managing local state, event handling, and rendering in an integrated way. However, you can still communicate between them using DOM events. An HTMX date picker may compose better, but that's just because it punts the integration to you.
Ecosystems have their downsides too. Just a small example, no htmx users were impacted by the React Flight Protocol vulnerabilities. Many htmx users have no-build setups: no npm, no package.json, nothing. We don't have to worry about the security vulnerability treadmill and packages and tools arbitrarily breaking and no longer building after some time passes. We just drive the entire webapp from the backend, and it just works.
One never uses just one JS lib :) The JS ecosystem always comes with lost of tools, and libs, and bells, and whistles.
I like Elm for this reason. Less choices. Zero runtime errors (I know it is possible in contrived examples, but I've seen and many teams have said the promise holds true after many years of using in production).
I mean, there's a reason people made client-side frameworks in the first place. Distributed state synchronization is really, really hard to do manually.
I think HTMX is really well designed for what it is, but I struggle to think of an occasion when it would be the best option. If you have any amount of interactivity, you'll get better DX with a full client side framework. If you don't have much interactivity, then you don't even need a JavaScript library in the first place. Just write a static website.
For the vast majority of web apps (including the ones that are built with SPA frameworks now), "how do I do distributed state synchronization" is an example of the XY problem. Most of the time, you don't actually need to write an entire separate app that understands your domain and synchronizes state with the backend, you need something that allows your users to trigger network requests and for the HTML displayed to them to be updated based on the response. Hypermedia is fully capable of solving that problem, completely sidestepping the need to solve the sort of state synchronization problem you mention.
> If you display mutable derivations of the server-side state in more than one place on the client, you're synchronizing it.
Again, this is the XY problem. Your actual requirement isn't "display mutable derivations of the server-side state in more than one place on the client", it's "update two parts of the DOM in response to user action". You can usually accomplish this with HTMX just fine by either using out of band swaps or swapping out a mutual parent element, depending on your actual needs. You can think of this as state synchronization if you really want to, but it's meaningfully different and significantly easier. Your frontend state isn't a synchronized partial copy of the backend state requiring custom software to manage, it's a projection from that state with embedded possible transitions/mutations.
> If you're not displaying mutable derivations of server-side state in more than one place on the client, then you don't need HTMX.
Even if you think HTMX isn't a good solution and limiting ourselves to swapping out a single element, it very clearly enables a lot of behavior that just isn't possible with standard HTML hypermedia controls (links and forms). Things like active search, infinite scroll, etc. cannot be done with vanila HTML, because you can only trigger HTTP requests with a small subset of events, and if you do trigger one you must replace the entire page.
OOB swaps are exactly what I'm talking about. That's imperative state management that would be easier with a client side framework. You shouldn't have to manually write out every single part of the app that relies on a single state transition. Do you really think that's scalable? Why would you choose to do that instead of using a tool that completely negates that concern?
You have to manually write that out either way. In the SPA/reactive paradigm, you have to specify that multiple parts of the UI depend on the same part of the state, vs sending down those multiple parts of the UI from the backend.
I'd also argue that if you look at the interactions on web apps, you'll find the number of cases where you would actually need an OOB swap is more limited than you might be thinking.
This isn't just a hypothetical. I have written apps both ways, including porting a few from a SPA framework to a hypermedia based solution. It allowed me to sidestep several major sources of complexity.
The reasons however are not so valid anymore in 2026.
Plain HTML has lots of extra features that did not exist in 2010 (form-validation and input-types, canvas, fetch, history-API), and some shortcomings have disappeared (like 'Flash of Unstyled Content'.)
Endless scrolling (made popular by Facebook/react) used to be heavy on the browser and sometimes made mobile devices unresponsive. That is not an issue anymore.
Tbh, I can't name a single issue we have today that requires large client-side frameworks for a fix.
I use it in one place, where it makes sense: i want the server to template something that works interactively/asyncly. The rest of my current app is, thank God, oldskool SSR HTML request-response over an SQL db.
It doesn't help that self closing/void tags are actually a thing in HTML. input, image, meta, br-- these can be misleading to a naive developer. You can try to say something about how a div requires text content, but empty divs get used structurally by design teams all the time in practice...
Yeah, but these are self-closing. Writing "<br/>" is actually wrong and just corrected to "<br>" in HTML. HTML does not have that syntax, that would be XML. And that is why "<div/>" is corrected to "<div>" and the closing "</div>" is inserted somewhere.
Oops, yeah. My bad, you're right. It makes sense that any flight server that is capable of interpreting server functions would be vulnerable whether the codebase used them or not. It's an issue in the transport mechanism and not the actual RPC implementation.
It's an RPC. They're half a century old. Java had RMI within a year of existence. [0]
> In remote procedure call systems, client-side stub code must be generated and linked into a client before a remote procedure call can be done. This code may be either statically linked into the client or linked in at run-time via dynamic linking with libraries available locally or over a network file system. In either the case of static or dynamic linking, the specific code to
handle an RPC must be available to the client machine in compiled form... Dynamic stub loading is used only when code for a
needed stub is not already available. The argument and return types specified in the remote interfaces are made available using the same mechanism. Loading arbitrary classes into clients or servers presents a potential security problem;
I’d like your opinion on something. What do you make of these allegations?
1) Romania: On September 28, 2015, Vice President Biden welcomed Romanian President Klaus Iohannis to the White House. Within five weeks of this meeting, a Romanian businessman involved with a high-profile corruption prosecution in Romania, Gabriel Popoviciu, began depositing a Biden associate’s bank account, which ultimately made their way into Biden family accounts. Popoviciu made sixteen of the seventeen payments, totaling over $3 million, to the Biden associate account while Joe Biden was Vice President. Biden family accounts ultimately received approximately $1.038 million. The total amount from Romania to the Biden family and their associates is over $3 million.
2) China- CEFC: On March 1, 2017—less than two months after Vice President Joe Biden left public office—State Energy HK Limited, a Chinese company, wired $3 million to a Biden associate’s account. This is the same bank account used in the above “Romania” section. After the Chinese company wired the Biden associate account the $3 million, the Biden family received approximately $1,065,692 over a three-month period in different bank accounts. Additionally, the CEFC Chairman gives Hunter Biden a diamond worth $80,000. Lastly, CEFC creates a joint venture with the Bidens in the summer of 2017. The timeline lays out the “WhatsApp” messages and subsequent wires from the Chinese to the Bidens of $100,000 and $5 million. The total amount from China, specifically with CEFC and their related entities, to the Biden family and their associates is over $8 million.
3) Kazakhstan: On April 22, 2014, Kenes Rakishev, a Kazakhstani oligarch used his Singaporean entity, Novatus Holdings, to wire one of Hunter Biden’s Rosemont Seneca entities $142,300. The very next day—April 23, 2014—the Rosemont Seneca entity transferred the exact same amount of money to a car dealership for a car for Hunter Biden. Hunter Biden and Devon Archer would represent Burisma in Kazakhstan in May/June of 2014 as the company attempted to broker a three-way deal among Burisma, the Kazakhstan government, and a Chinese state-owned energy company.
4) Ukraine: Devon Archer joined the Burisma board of directors in spring of 2014 and was joined by Hunter Biden shortly thereafter. Hunter Biden joined the company as counsel, but after a meeting with Burisma owner Mykola Zlochevsky in Lake Como, Italy, was elevated to the board of directors in the spring of 2014. Both Biden and Archer were each paid $1 million per year ( note: I am quoting a source here. I’ve always seen this number at 500k, not 1M ) for their positions on the board of directors. In December 2015, after a Burisma board of directors meeting, Zlochevsky and Hunter Biden “called D.C.” in the wake of mounting pressures the company was facing. Zlochevsky was later charged with bribing Ukrainian officials with $6 million in an attempt to delay or drop the investigation into his company. The total amount from Ukraine to the Biden family and their associates is $6.5 million.
Are people that ignore these ‘feckless traitors’? Why or why not?
Why do you think that I'm going to defend Biden? Politics are not sports, and I don't have a "favorite team". Your silly gotcha questions won't work on me because I don't reflexively defend people just because they are supported by corrupt political organizations.
Two wrongs don't make a right, and one person's crimes do not excuse another's. Arrest them all.
We need fundamental changes in our political system, and we're not going to be able to achieve anything if you keep pretending like these whataboutisms are worth anyone's time. Wake up.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
reply