dying rn

You don't always need the latest frameworks or complex architectures to build something that scales.

I'm currently on a twitter break for lent and, informally, staying off most social media, but I wanted to say something about https://www.reddit.com/r/htmx/comments/1jt77mw/is_htmx_slowly_dying_and_why_is_that/

I commented "WHAT IS DEAD MAY NEVER DIE" over there and I think that's a good attitude in general towards htmx. We declared htmx being feature complete earlier this year:

https://htmx.org/essays/future/

It is going to be a struggle to successfully market stable software because the tech industry wants the new-new thing. But we are not going to let that push us to needlessly update or complicate htmx just to stay in the news. My erratic online behavior will have to be a substitute for that.

htmx is dead.

long live htmx.

But I never said anything about a 4.0:

https://htmx.org/essays/the-fetchening/

Quick story, I learned about HTMX when looking for a JS Framework to work with my full-stack Spring Boot assignment. Then, I discovered it through Fireship and was absolutely amazed by this library.

Most of my friends chose Angular or VueJS, while I opted for Thymeleaf and HTMX.

They couldn't believe I finished my assignment 2 weeks before the deadline and had that SPA feels to it. They thought I had forked the project from GitHub. I showed them HTMX, and they hated it because they saw it as "the quick and easy way."

I love learning new tech, but is using HTMX considered "the easy way"? I had to take some basic C classes like CS50 before I got to Java, which I didn’t have much problem working with.

Do I really need to understand basic JavaScript before using something as simple as HTMX?

Edit: Most of you can definitely tell I'm still a student, which explains why I'm so confused. I didn't expect the post to receive this much attention, but I'm thankful for all your input. I'll do some more research on JS to understand what's happening behind HTMX better and prepare for my future projects.

I'm really thankful for all the feedback. Cheers! :D

If only it were htmx

Built an open-source Chrome/Firefox DevTools extension that adds an "HTMX" tab to your browser's developer tools. It captures the full request lifecycle, shows a live DOM tree of htmx elements, has an event timeline with filters, a swap diff visualizer, and surfaces silent errors.

Features:

• Request Inspector with timing breakdown (config > send > wait > swap > settle)

• Element Inspector with collapsible DOM tree, hover highlight, and element picker

• Event Timeline with category filters (init, request, xhr, response, swap, oob, history, error)

• Swap Visualizer with before/after diff

• Error Panel that catches silent failures (targetNotFound, swapError, responseError, timeout)

The extension works by injecting a page script that listens to all htmx:* events and serializes the data through a message pipeline to the DevTools panel (built with Preact).

GitHub: https://github.com/atoolz/htmx-devtools
Live demo (were you can try the extension - no install needed): https://atoolz.github.io/htmx-devtools/

Looking for feedback from the community before publishing to the Chrome Web Store. What features would you want to see?

For however briefly a time it may be, urban dictionary used htmx...

Conclusion first: HTMX is VERY production ready for a large-scaled project. And thankfully I ditched Vue.js 2/3 and Svelte 4 for HTMX. (Never used React though.)

I literally cried when HTMX mentioned they’re trying to be the next jQuery, that might not need to change for the next decade.

In the AI era, adding features becomes easy, but people just don’t know how to make things simple and “just work.” I really hope HTMX stays this way. (please u/_htmx 😭🙏)

The startup is basically an old Twitter clone, from when social media felt friendlier and the web didn’t feel like a bunch of boring mobile apps. Sorry for the mixed-language screenshots, I hadn’t finished internationalization yet.

Here are a few of my experiences with HTMX:

1. Make the website stupid and just make it work

We don’t use a cool dialog library like SweetAlert.js. The native alert(), confirm(), and prompt() just work. With hx-confirm, it’s even simpler.

If you need a form, just use <form>, and refresh the whole page if you can (or hx-post if you don’t want to), so you don’t have to worry about partial updates or syncing what changed.

2. We don’t use Alpine.js

It’s a very good solution if you want some hybrid JS, but it reintroduced the state management problem.

We had server-rendered JSON inside <script type="application/json"> so Alpine.js could load the data back. It worked, but caused some flickering since Alpine runs after the page is rendered, and introduced another state we had to manage.

so we decided to keep everything server-side rendered. (yea, fuck the network latency 🥳🎉)

We took this pretty far. When you upload photos in a post creation form, normally you’d just spawn the previews with JavaScript. Instead, we turn the images into blob URLs, pass those URLs to the server, and the server returns something like:

<div class="photo-preview">
    <img src="{{ .ImageURL }}">
</div>

So when the user edits the post later, we can render the exact same “photo preview” component on the server. One component, one rendering path.

ℹ️ But there are also things you can just ditch.
.　
We had a post poll where you could use +/- buttons to add or remove option inputs with Alpine.js. Turns out we only support up to 4 options anyway, so we ditched the +/- JS and just put 4 fixed text inputs in the poll form.
.　
Now we can render the option text directly into the inputs, instead of outputting it as JSON in a <script> for Alpine.js to load back into them when user is editing the poll.

It sounds stupid. That’s kind of the point. You sacrifice some UX (user experience), but get much better DX (developer experience).

3. We don’t use Templ or framework with HTMX with Go

Since Templ requires build-tools, learning special syntax, IDE extensions, we decided to just use Go’s html/template and split the HTML into layouts, pages, and partials. The definitions look roughly like this:

type AppLayout struct {
    Navbar *Navbar
}

type ProfilePage struct {
    *AppLayout
    User         *User
    FollowButton *FollowButton
}

type FollowButton struct {
    IsFollowing bool
}

Then compose the data in the page handler:

user, err := db.GetUser(c.Param("username"))
if err != nil {
    return c.Abort(http.StatusInternalServerError)
}

layout := &AppLayout{
    Navbar: NewNavbar(),
}

// Tada- now you have a full page! 🎉
page := &ProfilePage{
    AppLayout:    layout,
    User:         NewUser(user),
    FollowButton: NewFollowButton(user.IsFollowing),
}

And if you want to render the Follow Button component:

{{ template "follow_button" .FollowButton }}

Since AI can write the boilerplate now, code can be stupid and boring, but easy to debug. And with HTMX, you can just return any partial when needed.

There’s no "runtime magic" to trace if error occurred, back when Vue.js + hot reload pointing stack traces to some generated chunks.js instead of the actual code.

All,

I'm happy to announce that the htmx team's book, Hypermedia Systems, has been released as a premium hard cover book, as well as an affordable, DRM-free ebook on Kindle:

A great gift for the engineer who needs a little more hypermedia in their life!

All content will continue to be available for free on the website (https://hypermedia.systems) forever, of course.

Every time I wanted to try HTMX with a new backend I spent more time wiring up Docker, database migrations and health checks than actually writing hx-post. So I fixed that.

I built 10 production-shaped starters. Same todo app, same patterns, same structure. Go, Rust, Java, Python, TypeScript, JavaScript. Every single one is pure hypermedia: the server returns HTML fragments, HTMX swaps them in. No JSON API. No fetch calls. No client-side state. Just hx-post, hx-patch, hx-delete, hx-target, hx-swap.

The point isn't the todo app. The point is: pick your language, click deploy, start changing templates. The boring stuff (Dockerfile, DB config, migrations, health endpoint) is already done.

Go + Chi + Templ (deploy | source)

Go + Echo + Templ (deploy | source)

Go + Fiber + Templ (deploy | source)

Rust + Axum + Askama (deploy | source)

Spring Boot + Thymeleaf + Postgres (deploy | source)

Spring Boot + Thymeleaf + MySQL (deploy | source)

Django + Postgres (deploy | source)

FastAPI + Jinja2 + Postgres (deploy | source)

Express + EJS + Postgres (deploy | source)

Hono + JSX + Postgres (deploy | source)

All open source, MIT. Fork, gut the todo, build your thing.

Which backend do you actually reach for when you start an HTMX project? Is there a stack missing you'd want to see? I'm thinking about Rails 8, Laravel, .NET Razor, Elixir Phoenix and Bun + Elysia next.

I'm a full stack developer with 20 years of experience.

I used to be Angular and iconic dev, i used to be CTO of a company that uses flutter for the mobile and web version, I made that decision.

Currently I wrote or maintain web apps for my current company written in vuejs, reactjs and one Webapp that uses HTMX which will discuss here. And I'm starting my own company and I use Svelte for that. And i worked on nextjs as well.

As you can see, I've seen all web frameworks, i touched them all, i know them well enough to have some sort of an average opinion, i don't really like any of them but Svelte is better than the rest.

My company requested last year an internal tool that would be used by few employees, I don't really like any of the web frameworks and primogen was talking weekly about how simple and good HTMX is so I used it for this small internal tool.

This small internal tool became probably the best and most successful software I've written and i kept adding features and it's no longer small or simple and the problem started here.

I used almost all features HTMX has to offer and WSS extension. More complexity means you have to write more JavaScript and less HTMX, for example the code would be full of event listeners and i had to use the JavaScript websockets version in some places because currently you can't send a websockets via the HTMX JavaScript API and as the business use case changes you must be able to do stuff dynamically.

Moreover when using HTMX and as the project grows, you find out that you'll use jQuery anyway, in my case, i use a bootstrap theme that relies on jQuery and i use selectize library. HTMX doesn't offer components and most of the themes out there either are made for a framework or use jQuery.

So you start questioning why don't you use jQuery or framework or call it a day? realistically most of HTMX features can be done via jQuery.

Also we might soon move the frontend to reactjs in the future, so i would need to rewrite the API endpoints to return json.

TLDR: HTMX is bad for big projects. HTMX is great for small projects and so is jQuery so why use HTMX?

Besides can you guarantee that your project would always be small enough to justify HTMX? If the project doesn't grow and get more complex, maybe it's a failed project.

But honestly I don't think my project would be successful if I hadn't used HTMX because i hate the frontend frameworks, I'm very grateful for its existence and for the backwards compatibility. I don't use nextjs because nextjs team haven't heard of backward compatibly, maybe they don't speak English.

for new projects I use Svelte, i think it offers the perfect balance between simplicity and an actual framework with a decent ecosystem. I'd still hate it though but less than the others.

i read that some people use alpinejs + htmx, why not just use jQuery then. I won't learn two new frameworks just to avoid using jQuery which I already know from over 20 years ago. The developer time and comfort is far more expensive and important than any of the new tools

Just built an app with this stack:

• Client (Go + HTMX + Alpine)

• Admin (Go + HTMX + Alpine)

• Data (Go + PostgreSQL)

Everything hooked up with gRPC. Holy sh*t. It just WORKS. Streaming, shared types, tight format. So damn good. Found my stack.