The No-Build, 20KB Frontend Pitch
Two script tags. That is the whole setup for a reactive web app with no build step and nothing to compile. The pitch is a whole front end in about 20 kilobytes. Two small libraries, HTMX and Alpine. No NPM install, no webpack config, no node modules folder eating a gigabyte of disk. You just add a script tag. Let me introduce both because they solve two very different problems.
HTMX is around 16 kilobytes gzipped and it ships with zero dependencies. Alpine is about 15. Its creator calls it jQuery for the modern web. For contrast, React DOM alone is roughly 50 kilobytes gzipped before you write a single line of your own app.
HTMX owns the server round trips. Alpine owns what happens on the page. Together, that is your front end. And here's the strange part. All of it lives inside your HTML as attributes. There are no separate wiring files. I will show you how each one works, who actually built them, and the exact point where this whole stack breaks.
How HTMX Replaces the JSON Layer
Start with HTMX and start with the question it was built around. Why is it that only links and forms are allowed to make HTTP requests? Why does a click always have to fetch a brand new page? HTMX looks at those limits and just deletes them. With HTMX, any element can talk to the server. A div, a span, a button, anything you like. Any event can trigger it, not only clicks. And you get all four verbs, get, post, put, and delete, driven by plain attributes like HX get and HX post.
Here's the example straight off the HTMX home page. A button with HX post pointing at /clicked. When you press it, HTMX fires a request in the background, takes the response, and swaps it into the page. That is the entire feature in one line of markup. But this is the part that makes framework people uncomfortable. The server does not answer with JSON. It answers with plain HTML. HTMX takes that HTML and drops it straight into the page. No client-side rendering, no virtual DOM, no reconciliation pass. The server already did the work.
And notice what just disappeared. Because the server sends HTML, the entire JSON layer goes with it. No serializers on the back end. No fetch calls, no data mapping, no client cache to keep in sync on the front end. That whole tier, the part that tends to cause the most bugs, is simply not there anymore.
Built-in Features of HTMX
You stay in control of the details. HX-Target says which element receives the response. HX-Swap says how, whether you replace it, append to it, or slot content before and after. Replace one table row, repaint one panel, and leave the rest of the page completely untouched.
HTMX also ships the boring parts you would normally hand build. Loading spinners come from a single HX-Indicator attribute. CSS transitions are baked in, so a swap can fade instead of flashing. An HX-Trigger lets you debounce, so a search box waits until the user stops typing before it hits the server.
And this covers far more than you would expect. Live search that filters as you type, infinite scroll, inline editing, lazy-loaded content, forms that validate against the server. In a classic single-page app, each of those is a small pile of JavaScript. In HTMX, they are a handful of attributes on the element. There is even a one-line upgrade called HX-Boost. Add it to a link or a form, and HTMX turns a normal full-page navigation into a background swap. A plain multi-page site suddenly feels like a single-page app.
Introducing Alpine.js for Client-Side State
The back button still works, the URL still changes, and if JavaScript ever fails to load, the ordinary links keep working.
Now, Alpine, and the reason you want both. HTMX is wonderful when the source of truth lives on the server, but a lot of interface never needs the server at all. A drop-down opening, a tab switching, a password field toggling visible. That is Alpine territory. You mark an element with X-Data and give it a little state object. Then X-On handles events. X-Show and X-If decide what renders. X-model binds an input to your data.
It is basically the mental model of Vue, shrunk down and dropped directly into your markup. The payoff is that none of it touches the network. No round trip, no reload, no spinner. A menu opens the instant you click because the state is sitting right there in the element. HTMX goes out to the server. Alpine stays home and handles the page.
Synergy: How HTMX and Alpine Work Together
Alpine has the same batteries included streak. X-transition animates things in and out with no CSS gymnastics. Official plugins add state that persists across reloads, intersection triggers, input masking, and focus control. There is even Alpine Ajax for HTMX style server fetch without pulling in HTMX.
So, the division of labor is clean. Reach for HTMX when the real answer has to come from the database. Reach for Alpine when the page is just reacting to itself. Most real screens are a blend of both, and the two libraries were designed from the start to sit side by side.
Philosophy, Creators, and Community Adoption
There is a genuine idea holding all of this together. Carson Gross, who created HTMX, wrote an essay for it called Locality of Behavior. The principle is simple. The behavior of a piece of code should be obvious from looking at that one piece of code. In practice, that means you look at a button, and the tag itself tells you what it does. You are not jumping across five files, a component, a hook, a reducer, an API client, a route, just to trace one click. The behavior is right there in the markup, where you are already looking.
It is also, honestly, a throwback, and its fans are proud of that. HTMX argues the web already had this power. Hypertext, links, and forms were a hypermedia system, the thing Roy Fielding described in the original REST paper. We just wandered off and rebuilt all of it in JavaScript.
Neither tool appeared out of nowhere. HTMX is the grown-up version of an older library Carson shipped years earlier called Intercooler. He rewrote it with no jQuery dependency, gave it a much sharper name, and it caught fire on developer social media. Alpine came from Caleb Porzio, deep in the Laravel community. He had built Livewire, a way to drive dynamic pages straight from the server, and he wanted something tiny for the little client-side moments. That something turned into Alpine.
So, think about what these actually are. Two independent developers, no mega corp, no venture money steering the road map. They are funded mostly through GitHub sponsors, and in Carson's case, a book he wrote about the whole approach. And developers voted with their stars. HTMX sits near 48,000 on GitHub. Alpine is past 31,000. The sponsor list is not hobbyist, either. JetBrains and GitHub both put real money behind HTMX.
Benefits and a Compelling Case Study
One more thing you get for free, because the real content is server-rendered HTML. Search engines see it instantly, with nothing to execute. The first paint is fast, because the browser is handed finished markup instead of a blank div and a promise. And plenty of it still works with JavaScript switched off.
Now, the number that made me actually stop and pay attention. A team took a real production React application and rebuilt its front end using HTMX instead. Same product, same features, nothing removed to make the demo look good. The code base came out 67% smaller. Two-thirds of the front end JavaScript gone for the exact same application. And this is not a cherry-picked demo. HTMX links the full write-up straight from its own home page.
Think about everything that number drags along with it. No build pipeline to baby-sit, no dependency upgrades breaking on a Friday afternoon, no hydration mismatches. The server renders HTML. The browser displays HTML, which is the one job browsers were actually built to do. If you want the full argument, Carson wrote it down. The book is called Hypermedia Systems, and it lays out how to build serious applications this way, not just toy demos.
Knowing the Limits: When to AVOID This Stack
Whether you end up agreeing or not, it is a real position argued properly and in public.
Now, the part most of these videos skip. This stack has a real ceiling and pretending otherwise would be dishonest. HTMX and Alpine are not a universal answer to everything. If you are building something like Figma or a live collaborative editor where a huge amount of state lives on the client and changes every few milliseconds, HTMX will fight you the entire way. That is exactly the job a heavy client framework exists to do and Alpine has its own edge. It is lovely for small pieces of state, but once your client logic grows into something genuinely complex, all those attributes start to sprawl across the markup. Past a certain point, a full framework earns every kilobyte it costs.
Who It's For & The Final Takeaway
Both projects are very much alive. HTMX has a version 4 in active beta aimed at this summer and it is careful about not breaking your existing pages. Alpine ships steady point releases. The latest one landed this spring.
So, who is this actually for? Server rendered apps, first of all. Django, Rails, Laravel, Go, any stack that already returns HTML. And solo developers and small teams who would rather ship features than spend a week wiring up a bundler.
Here is my honest take. This is not React is dead and anyone selling you that headline is selling something. It is a reminder that for a large class of websites, you never actually needed all of that machinery in the first place. Two script tags, somewhere around 30 kilobytes over the wire. No build, no bundler, no node modules. For the right project, that covers the whole job from first paint to the last click and a surprising number of projects are exactly that project. If this rewired how you think about front end weight, you know where the subscribe button is.
