While the software development industry has been gorging on large language models (LLMs), the front-end ecosystem has quietly fractured into three competing but interrelated architectural paradigms. Between the dominance of reactive frameworks, the hypermedia-driven simplicity of true REST, and the decentralized resilience of SQL everywhere, developers are no longer just choosing a library, they are choosing where the data lives: at the server, at the client, or both.

Three competing architectures, more or less

Web developers are long familiar with React and the galaxy of similar reactive frameworks like Angular, Vue, and Svelte. For nearly a decade, these have dominated the narrative with their competition and co-inspiration. HTMX and hypermedia-driven applications have championed a return to the true RESTful thin client, alongside alternatives like Hotwire and Unpoly.

We could in a sense see reactivity and hypermedia as two opposing camps. Somewhere in between is the local-first SQL movement, which proposes putting SQL directly in the browser. The waters are a bit muddy because local SQL can and does work right alongside React.

It’s still safe to say that a reactive framework paired with a JSON API back end that talks to a datastore (SQL or otherwise) is still the de facto standard. But that monolithic story is starting to fracture in some very interesting ways.

Where the weight of the data lies

Data of course is the central mass of web applications. Where it lives and how it moves produce the gravity around which everything else must revolve. Each of these architectures proposes to handle that gravity in its own way, with different benefits and tradeoffs.

Hypermedia (e.g., HTMX): Keep the data largely off the client. The client is just a visual representation of the server data. The back-end “API” is responsible for producing the data-driven markup. Any kind of datastore can be used by the API server.

React and friends: A sophisticated, stateful engine runs in the client, and the developer syncs that state with the back end via RESTful JSON API calls. The back-end server tends to be dumb, responsible largely for just invoking other services to provide business logic or data persistence.

Local-first SQL: The data is distributed to the clients, like with React and friends, but in a much different way. Although the data is automatically synced directly to a datastore (like Postgres), the back-end API server is used only for specialized service calls—not for data persistence.

To summarize:

• HTMX: Data gravity is at the server.
• React: Data gravity is split between the server and the client.
• Local-first: Data gravity is at the client.

Comparing the approaches

Besides the technical stats, the developer experience for each of these paradigms is quite different. However, while each paradigm feels different, they intersect in some interesting ways. Let’s take a closer look.

React and friends

Reactivity is the world we have been working in for 15 years. We’ve got a whole universe of frameworks: React, Angular, Vue, Svelte, Solid, and full-stack variants like Next.js, Nuxt, SvelteKit, Astro, etc. The beauty of these is in the core reactive idea. You have a state that consists of the variables and the UI is updated automatically. The UI is a pure function of state: $UI = f(state).

The downside is the gradual, almost imperceptible layering of intense complexity over the top of it all. This complexity seems at first just incidental, but it is in fact a direct outcome of the basic premise: building a state engine on the browser.

The result is you have two states: the browser and the database. The reactive engine becomes a negotiation layer. Add to that the various inherent complexities of managing the browser state, and the result is quite a lot for front-end developers to wrap their heads around.

In the effort to manage such complexity, wring more performance, and improve developer experience, we have wound up with quite a sprawling empire of tools and techniques. Even just for React we have React Server Components, complex state-management libraries like Redux or Zustand, and orchestration layers like TanStack Query for manual cache invalidation.

On the back end, we talk to JSON APIs (or GraphQL), which can become unwieldy as a kind of boilerplate layer, but has in its favor an almost universal understanding.

HTMX and similar (Hotwired, Unpoly)

HTMX is like using HTML that has superpowers. You can do a huge amount of what you use reactive frameworks for, including all the AJAX and a lot of the partial rendering and effects, with just a few extra attributes sprinkled judiciously.

You spend a lot of time on the server, using a template engine like Pug, Thymeleaf, or Kotlin DSL. These are where you bring together the data from the persistence service and combine it with markup. The markup you generate includes the HTMX attributes.

You tend to decompose the templates, i.e., break them up into dedicated chunks. The idea is you want to have a chunk that can be used within the larger UI to create the whole layout, along with the ability to use that chunk alone when (and if) it is called upon for an AJAX response.

Hypermedia with HTMX is a very powerful model. You are actually using REST, meaning you are transmitting a representational state.

Hotwire and Unpoly are similar libraries. In the case of Hotwire, you can achieve quite a bit of functionality and performance even without changing your HTML, just by using Turbo Frames to intercept link clicks and form submissions, automatically turning standard page navigation into partial DOM updates.

The beauty of the hypermedia approaches is that you gain a lot with a little. You are staying as much as possible in HTML, the very poster child of simplicity. On the other hand, you are giving up some of the sheer sophisticated power of reactive frameworks.

Local-first apps

Local-first development is the new kid on the block. Like React and friends, local-first keeps the data in two places, but it does so in a radically different way. In its most essential form, it means running a database in the browser that is kept aligned with the remote datastore via a syncing engine. This kind of thing has been done before with NoSQL databases like CouchDB or with the IndexedDB API, but the modern browser takes it to another level with a Wasm-based database engine, like SQLite.

The user gets a small view of the full data, called a partial replication or a bucket (also called a “shape”). The front-end app interacts directly with that data, and the infrastructure automatically does the work of keeping everything synced. A big benefit here is strong offline support (because the client device is carrying around an actual database).

This is a massive departure from the request-response cycle. In local-first, you don’t fetch data; you subscribe to it. The network becomes a background daemon that reconciles local and remote state using CRDTs (conflict-free replicated data types). CRDTs ensure that if two users edit a task while offline, the merge is seamless rather than messy.

There is also a degree of simplification in using SQL everywhere, though that is offset by a rather unfamiliar and involved architectural setup. A syncing engine like PowerSync or Electric SQL is required, and it has a set of rules that must be maintained. Plus the auth and interaction between the database and the syncing engine must be configured.

Local-first eliminates both the API server and the HTML template server. It pushes the entire data negotiation layer into the automated syncing engine that runs off developer-defined rules.

Interestingly, local-first SQL can be used as a data driver for React (and other reactive engines) or plain vanilla HTML + JS. As such, it is an interesting alternative take on the architecture of the web, which is agnostic about the front end.

Perhaps the strangest arrangement to contemplate is using HTMX and local-first SQL together. This is like a mad scientist architecture, which of course means developers are doing it. In this setup, the back-end HTMX template engine is actually a service worker running the SQL engine. In theory, you get the simplicity of HTMX and the ultra-speed + offline functionality of local SQL.

Reactivity, hypermedia, or local-first? How to choose

We remain in the era of the default choice being React plus a JSON API. From there you might experiment with innovative frameworks like Svelte or Solid. If you are looking for an ingenious way to leverage RESTful simplicity, HTMX or Hotwired are must-tries. Local-first SQL is an exotic animal, fit for the likes of Linear or Notion right now, but somewhat daring for most of us doing standard production work.

More broadly, the emergence of this trilemma signals the end of the “one true way” for web development. We are moving away from the library wars and into a world of architectural choice.

The choice between reactivity, hypermedia, and local-first isn’t just about code. It’s about where you want to place the data.

• If you want the data to be a server-side document, choose hypermedia.
• If you want the data to be a shared memory state, choose reactivity.
• If you want the data to be a distributed database, choose local-first.

And of course, it is possible to put the approaches together to strive for a blend of the right benefits for your project.

As the JSON-over-the-wire monolith continues to fragment, the best architects won’t be the ones who know the most hooks or the most attributes. They will be the ones who understand the weight of their data and choose the architecture that lets the data move most freely. The framework wars are over, but the battle for the network has just begun.