htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext

    htmx is small (~14k min.gz’d), dependency-free, extendable, IE11 compatible & has reduced code base sizes by 67% when compared with react

HTMX's platform is a resource for web developers, offering insights into building dynamic web applications with HTML, CSS, and JavaScript. Through articles, tutorials, and demos, HTMX offers insights into progressive enhancement techniques, AJAX-driven UIs, and server-side rendering. Readers can learn about using HTMX to add interactivity to their web applications, improve user experience, and simplify frontend development without relying heavily on JavaScript frameworks.

htmx

Gumroad's new project, Helper, initially considered using htmx for its lightweight front-end needs. However, the team found htmx lacking in several areas: developer experience, user experience, AI/tooling support, scalability, and community ecosystem. Despite htmx’s potential for simpler projects, they switched to React and Next.js to better handle complex interactions, state management, and real-time collaboration, enhancing their project's user experience and development efficiency.

> htmx ~ Why Gumroad Didn't Choose htmx

Bold of the HTMX team to host this article on their own website. It’s good to give voice to both fans and detractors of your product.
What I do wonder about is why Gumroad opted to go for React + NextJS instead of just plain React. It seems that NextJS sort of locks you into Vercel for hosting if you want all the bells and whistles that NextJS is famous for to work (e.g. incremental static generation, function splitting etc.).
NextJS is notoriously hard to self-host, although solutions like <a href="https://opennext.js.org/" target="_blank" rel="noopener nofollow">OpenNext </a> exist.

They should have tried HTMX+Stimulus.

For my oppinion HTMX is a terrible idea, especially for highload projects. It will highly increse server cost and complexity of backend. Lots of this logic should be on the client side, and servers should only work with raw data and transport it to the client in as small payload as possible.

the only reason I can think of is that:
<ol>
<li>the team doesn’t want to use htmx because their portfolio</li>
<li>Sahil is a Vercel investor</li>
</ol>

After reading approximately half of the article, my thought was: you’ve chosen the wrong tool for the job. Htmx is not a good choice for complex SPA. Also, the team was reluctant to adopt the new philosophy, which definitely didn’t help. The main reason behind htmx creation was to show that not every project requires a complex frontend stack setup to deliver a product with decent UX.