3 min read10 hours ago

–

Press enter or click to view image in full size

For years, most of us have defaulted to React, Angular, Vue, and the whole SPA ecosystem whenever we needed to build something “modern.” They’ve become the safe choice. But lately, there’s been a noticeable shift happening in the front-end space. A lot of teams — including some big ones — are moving toward HTML-first frameworks like htmx, Marko.js, and a few others that take a more traditional, server-driven approach.

And honestly, it makes sense.

Not every application needs a heavy client-side engine. In many cases, the SPA model adds more complexity than value. HTML-first frameworks bring back some of the simplicity and speed the web was originally designed for, without taking away the interactivity users expect.

Here are a few reasons why this approach is gaining momentum.

1. You build with HTML instead of fighting with layers of JavaScript

HTML-first tools let you focus on the actual structure and behaviour of your application instead of juggling component trees, hydration, reducers, context providers, and all the overhead that comes with SPA frameworks.

With htmx, for example, you just send HTML from the server, and it swaps the right bits on the page. No 20-file React component folder. No client-side state library. No over-engineering.

It feels refreshingly straightforward.

2. Performance improves almost automatically

SPAs ship a ton of JavaScript — and the browser pays for it every time: parsing, executing, hydrating, diffing, and so on.

HTML-first frameworks work the opposite way. They load fast because the browser handles what it’s best at: rendering HTML. Interactivity is added in small, targeted pieces instead of shipping an entire runtime.

Users (especially mobile users) feel the difference immediately.

3. Server-driven UI is cleaner for most business apps

Most real logic — validation, rules, access control — lives on the server anyway. HTML-first frameworks don’t force you to duplicate it on both sides.

Instead of creating an API endpoint, transforming it, consuming it, and syncing everything in the client… you just render HTML with the updated state.

Simple. Predictable. Easy to reason about.

4. You end up with less code and fewer dependencies

One of the biggest benefits is simply a smaller codebase:

• no huge bundle
• no complicated build pipeline
• fewer moving parts
• easier onboarding for new team members
• fewer version-upgrade headaches

This also means fewer bugs and faster long-term maintenance.

5. Progressive enhancement, not a rewrite

You can add htmx or Marko to almost any existing backend without breaking the entire project structure.

Want a dynamic table? Enhance that section.

Need modal interactions without a full SPA? Swap in the HTML.

It’s not an “all or nothing” decision — you improve the UI step by step.

6. SEO, accessibility, and browser behavior just work

When your app uses real HTML instead of a virtual DOM, you avoid a lot of accidental problems that SPAs introduce. Back button, deep linking, accessibility tools, and SEO all behave naturally.

No hacks required.

7. Ideal for enterprise apps, dashboards, and portals

Not every application is a highly interactive design tool. A lot of the systems companies build — booking platforms, dashboards, admin tools, forms, internal portals — fit perfectly with this model.

They don’t need 500 KB of JavaScript to handle basic interactions.

HTML-first frameworks strike a good balance between interactivity and maintainability.

Final thoughts

React and Angular absolutely have their place, and they’re great when you really need a complex client-side application. But for many projects, an HTML-first approach is faster to build, easier to maintain, and lighter on the browser.

It’s not a step backward — it’s a reminder that the web already gives us everything we need to build powerful, responsive applications without the extra weight.