As someone who has been developing websites for 15+ years and who stumbled across HTMX a year or two ago, I want to add a couple things here:

One really really nice thing about HTMX is how easy it is to "spruce up" a UI. You say "this part of my website could really do with some active content" and you start thinking about xmlHttpRequest and callbacks and and JSON and all that and you think "does it really need sprucing?". But with HTMX it's usually just adding a couple hx- attributes and maybe a couple serverside lines and you're done.

Another really really nice thing about HTMX is how easy it makes it to make things degrade gracefully. Javascript enabled? Get your beautiful ajax. No Javascript? Get a good experience in the "traditional" model. In anything else I've ever seen, if you want that experience, you need to write your UI twice (and usually in two different languages / models).

So basically it drastically lowers the bar for making nicer experiences on top of a solid MPA. Especially if you're a solo developer, this basically means that you end up producing better UIs "for free".

I think React with SSR gives you that experience with the added bonus that you can use nice isolated and reusable UI components. The downside is you are forced to use JavaScript/Typescript for basically everything. Fortunately Typescript is a pretty decent language overall.

Also there are some systems trying to do the same thing but using Wasm (e.g. Percy).

I don't think a lot of the points in the article hit home for me.

On one hand you suggest the culture of complexity is overwhelming, when just a few paragraphs earlier you suggest that sql-tuning and redis caching are how to deal with some of htmlx's problems with latency. That seems highly complex. You have to make deep changes to the back-end and data persistence systems to solve a front end issue.

It feels like the article is trying to say you shouldn't use javascript frameworks in a lot of cases, but then it advocates for using htmx, which is a javascript framework, in those cases?

In my experience the issues people have in front-end come from using tools and frameworks incorrectly, because they don't understand the tradeoffs being made -- so they don't account for those tradeoffs in a reasonable way that eventually comes back to bite the team. Handing people a new JS library that is seeming to intend we completely avoid javascript and therefore the library itself, creating an incentive not to learn how it works.

> It feels like the article is trying to say you shouldn't use javascript frameworks in a lot of cases, but then it advocates for using htmx, which is a javascript framework, in those cases?

Htmx isn't a JavaScript framework, it's a hypermedia framework, and they're encouraging taking hypermedia as far as possible before dropping to scripting.

I've changed the title above to try to say what the article is about, using your wording here (but edited to fit HN's 80-char limit). In cases like this we try to avoid references to personalities. (We also try to avoid acronyms where possible, which is why I said 'multi-page apps' instead of 'MPAs'.) If there's a better title, i.e. a more accurate and neutral one, we can change it again.

It seems like there are broadly 2 concerns: having rich interaction inside of a single "page", and smooth transitions between "pages". You seem to dismiss the latter in your article, but HTMX seems to support Turbolinks style functionality, correct? Can animations be layered onto that?

I did some experiments around on how to do animated shared element transitions (as well as reactive functionality) within a REST mindset here, if anyone's curious: https://dev.to/eshan/toward-the-postmodern-web-38h (you can just scroll to the embeds)

Ultimately, maybe the browser vendors will do something here, like Google's portal elements, for example. A lot of effort is being spent on that flash during page loads.

Good luck with your effort! I started making web pages in 1998, in high school. Then years later finally got a job and worked for 7 years as web developer full-time, but after I saw Angular and React and tried making a project with them, I quit.

But even without SPA frameworks, a boilerplate for a simple project was insane: linters, assemblers, template frameworks, etc.

With React it was one notch more boilerplate, and yet after all that you had to write pretty much all the interactive UI still on your own.

Can you help clarify the difference between htmx and turbolinks (now just “turbo”) which has shipped with rails for years?

turbolinks takes over anchor navigation and "automagically" makes it use ajax

htmx (and intercooler.js, its predecessor which is 8 years old) is a lower level extension to HTML, allowing for targeting specific regions for replacement, using different events for triggering requests, etc.

htmx is closer to hotwire.dev, which 37signals recently released, but again is lower level and a more straight-ahead extension of HTML