Reading up on htmx

I really respect @antirez so I'd like to share my slightly different take on frontend development in 2026 (and especially in a coding agents world). First, on his point around libraries/frameworks and company size: > "We have things like Angular and React that are big-company-design stuff that became normal programming. It's like if every site runs on Kubernetes." It's true that frontend frameworks had to uniquely solve for the design constraints of BigCos. How do you build a system where thousands of engineers need to ship components independently without muddying the rest of the app? Composition! And if you take composition to its logical extreme and try to build a framework which works for both small *and* very large JavaScript apps, you end up with things like streaming, Suspense, and many of the other niceties of React and metaframeworks. Often, you do want many of these things to build high quality products. But sometimes you don't, and you don't have to ditch React's composition model and all the libraries, ecosystem, bundlers, et al to get there. Personally, I think Bun is one of the best realizations of this vision, where you can write React apps with a single toolchain. The layers of abstraction can fit in your head. > "There was, in big companies, an extreme desire to do two things: totally isolate frontend from backend, because the internal organization of big companies has such a split, and to make applications so standardized that hiring new people, firing old people, is something possible and easy." This might get into the HTMX holy war, but IMO this client/server debate has always been a thing. I'd also argue that, in many cases and now increasingly with AI, the client/server split is helpful for humans and agents to compartmentalize the codebase. I'm personally very supportive of open-source libraries like React and friends that get battle-tested at scale and get security patches (while painful sometimes). Models can learn this abstraction, and for many many cases, stop reinventing the wheel. Similar feelings about Tailwind. > "We later created a generation of programmers that can't even understand a single language very well in its internals, that is: Javascript, they often know the framework, not the language, nor even CSS well enough." It's true that a lot of frontend devs end up focusing on the app layer code concerns like React/Tailwind and maybe aren't as proficient at debugging heap snapshots. But I don't think the solution is to throw out the abstractions entirely, but instead to keep teaching the next generation of devs how to go up and down the stack as needed. This is now massively accelerated by AI and coding agents. Just like you can ask an agent to generate lots of frontend code for you, you can also ask it to deeply explain how every abstraction layer works. There's no forgoing competence to be a great frontend engineer. > "The irony is that front-end developers highly suffer from all that, for a number of reasons: they are forced to continue learning new ways to do the same button, form, pagination, and so forth. And, also, if they are smart they understand they don't really know what programming really is in most cases, and are not happy about it." Throughout my entire career doing frontend and product engineering, I've seen opinions like this over and over again. Back in the day, it was framing frontend as "just the HTML and CSS" / web developer, somehow less than"the great backend engineers. The reality is that there are many many incredibly talented frontend engineers who do lots of *extremely technical* work. It's time for a lot of backend engineers to give the frontend peeps their flowers, acknowledge some of this frontend stuff is Very Hard, and begrudgingly accept that React has some good ideas. And if you made it this far and still want to complain, I bet you can make an incredible frontend with Svelte/Tailwind and your coding agent of choice, taking 80-90% of the upside of the last decade of frontend dev

@leerob