Have you been working on the frontend with Javascript? Have you ever noticed what used to be simple <script>
has become a full build system? Frontend development has involved more tools than needed just to feel "modern," "reactive," and "interactive."
It's time to pause and see why we chose a path we never had to in the first place.
What Backend Can Do?
The backend has always been capable of full interactivity. It can render and persist state, handle routes, validate input, and return partial HTML—everything a frontend framework does, but faster and more predictably.
Any backend framework doesn't need a frontend babysitter. It already knows how to build reactive, server-driven interfaces—we just forgot to let it.
How Backend Used to Work
The backend always gave reactivity on two simple tags.
Take a look at below snippet.
<a href="/blog">Blog</a>
This anchor tag tells a browser:
When a user clicks on this link, issue an HTTP GET request to ‘/blog’ and load the response content into the browser window
Here's with <form>
tag.
<form method="post" action="./save-post" >
<button type="submit" >Save</button>
</form>
The form tag tells the browser:
When form is submitted, issue a post request, process data in the server and let server issue an HTTP Get request in response to form and load the response content into the browser window.
HTMX: HTML That Fights Back
Then comes HTMX, the library that makes HTML behave like it remembers how the web works. No build step. No bundler. No JavaScript build tools. Just attributes that turn your markup alive.
Now consider the following HTML snippet.
<button hx-post="/clicked"
hx-trigger="click"
hx-target="#parent-div"
hx-swap="outerHTML">
Click Me!
</button>
This tells HTMX:
When a user clicks on this button, issue an HTTP POST request to ‘/clicked’ and use the content from the response to replace the element with the id
parent-div
in the DOM.
HTMX has gone a step further and implemented this idea to other HTML elements so that they can be interactive as well.
And here's the summary taken from HTMX docs.
- Now any element, not just anchors and forms, can issue an HTTP request
- Now any event, not just clicks or form submissions, can trigger requests
- Now any HTTP verb, not just
GET
andPOST
, can be used - Now any element, not just the entire window, can be the target for update by the request
And guess what? What are we receiving from the backend in response?
HTML, not JSON.
Receiving a response in HTML format is deliberate. This gives rendering/hydration responsibility back to the backend, which Javascript snatched in the name of interactivity.
What About Reactivity?
But yes — you’ll sometimes want UI state that reacts instantly without hitting the server. HTMX handles interactivity, not reactivity.
That’s where most people add Alpine.js. It’s light and works fine. I wanted to go one step further, though—something that truly treats the DOM as the source of truth. So I built JSRibbon.
JSRibbon: Reactivity From the DOM Outward
JSRibbon is my ongoing experiment in DOM-first reactivity—a small, component-based library that learns from the last decade of frontend chaos without copying it.
Here’s the heart of it:
The DOM is The State: No virtual layers or hydration. The HTML itself defines current data.
The DOM is the Markup: No additional markup on Javascript end. DOM is the actual markup to render more nodes when needed.
Event Delegation is Core: Inspired by jQuery’s .on(), events bubble to component roots, so handlers never die when the DOM changes.
Component Composition and Context: Each component has its own scope, but can pass state to children — React’s good ideas, minus the ceremony.
Mutation Awareness: A built-in MutationObserver means that if new HTML arrives from HTMX, JSRibbon
automatically detects and wires it. Nothing to reinitialize, nothing to refresh manually.
The Quiet Revolution
The mix of Backend + HTMX + JSRibbon doesn’t look flashy — and that’s the point. It gives you reactivity, partial page updates, and component logic without a single build step. You deploy PHP, Blade, and two small JS files. That’s it.
No npm. No transpiler. No “dev mode.” Just clean, reactive, server-first HTML.
Why It Matters
The industry has over-engineered frontends into exhaustion. We ship megabytes of JavaScript to re-render what the server already produced perfectly. HTMX and JSRibbon offer an alternative path: HTML as the API, the DOM as the framework, and the server as the brain.
If this approach catches on — and it should — we may finally get to build interactive web apps that age gracefully instead of breaking every six months.
Top comments (0)