It's a sad moment for me. I got into Dilbert at the tender age of eight years old. I don't know why I liked it so much when half the jokes went over my head, but I loved computers and comics, and I plowed through every book at my local library. It was my real introduction to software engineering, and it definitely influenced me in many ways that certainly shaped the man that I am today.
I never agreed with him politically, and I honestly think he said some pretty awful stuff. However, none of that changes the positive impact that his comics had on my life. Rest in peace.
> I got into Dilbert at the tender age of eight years old. I don't know why I liked it so much when half the jokes went over my head, but I loved computers and comics
Same! Or at least I got into them as a young kid I don’t remember the exact age, it was probably a few years older but definitely tweens max.
I’m also not sure why I liked them so much, other than that I loved computers and always knew I’d end up working in the industry, so maybe it was like a window into that world that I liked. I also loved the movie Office Space, so maybe I just had a thing for office satire.
very interesting to find other folks who jibed with this comic at a young age. My mom and aunt had cubicle jobs and the entire idea seemed very fun to me. I recall looking at my 4th grade classroom and thinking we could really benefit from some cubicles.
Sadly I'm doomed to work in an open floorplan.
I wasn't exactly a daily reader at the time, but I was sad to hear when dilbert was pulled, and why. I tried to send him some fan mail when I heard he had fallen ill, but the email of his that I found had been deleted.
My very first job in tech I had a cubicle, but that was the only time. I’m also not a fan of open floor plans, but seems like they’re standard now. Feels like a “careful what you wish for” situation since everyone hated the idea of “cubicle farms” and wanted them gone (like the famous scene in Office Space), but somehow open floor plan is actually worse.
Same! My dad worked in corporate HR and loved Dilbert (I guess it spoke to him), so we usually had a few of his books and/or a strip-a-day desk calendar around the house that I would read. I never considered it before, but maybe I'm the cynical software engineer I am today because of Scott Adams. The world is a funny place sometimes.
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 never agreed with him politically, and I honestly think he said some pretty awful stuff. However, none of that changes the positive impact that his comics had on my life. Rest in peace.
reply