The HTML-First Approach: Why Htmx and Lightweight Frameworks Are Revolutionizin

For years, when it came to building something “modern” on the web, the almost automatic choice fell on React, Angular, Vue, and the entire Single Page Application (SPA) ecosystem. These frameworks became the safe choice, almost a de facto standard. But lately, a significant shift is happening in the front-end landscape. Many teams — including some large ones with enterprise projects — are moving toward HTML-first frameworks like htmx and other tools that take a more traditional, server-driven approach.

And honestly, it makes perfect 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 sacrific…

And honestly, it makes perfect sense. 🎯

In this article, we’ll explore in depth the reasons behind this trend, backed by concrete data and statistics.

The JavaScript Bloat Problem: The Numbers Speak Clearly 📊

Before analyzing the advantages of the HTML-first approach, it’s essential to understand the magnitude of the problem we’re facing.

The Exponential Growth of JavaScript

The HTTP Archive data is eloquent: the average amount of JavaScript transferred per page has grown from 90 KB in 2010 to 650 KB in 2024. And this trend shows no signs of slowing down.

But these are just average values. A detailed 2024 analysis reveals far more extreme cases:

Slack, a chat application, loads 55 MB of JavaScript — practically the size of the original Quake 1 with all resources included
Jira, a task management software, weighs almost 50 MB
LinkedIn reaches 31 MB
Simple social network “Like” buttons typically require 12 MB of code
Even Google Maps, relatively modest by modern standards, weighs 4.5 MB

If we assume an average line of code is about 65 characters, we’re talking about shipping approximately 150,000 lines of code with every website, sometimes just to display static content!

💡 Ever thought about it? Slack, a messaging app, requires more space than an entire 3D video game from the 90s. To send text messages.

The Performance Impact

JavaScript is the most computationally expensive resource a browser has to handle. It’s often the bottleneck that determines whether a page appears fast or slow, as an oversized bundle can block rendering and degrade overall performance.

For those using a high-end laptop with fiber connection, this might be just a minor annoyance. But for those browsing with a low-end phone or unstable connection, it can make the difference between staying on the site or abandoning it completely.

Framework Sizes Compared

Here’s a comparison of the major JavaScript frameworks’ sizes (gzipped versions), according to data from LogRocket and Strapi:

Framework	Gzipped Size
Angular	~62.3 KB
React + ReactDOM	~44.5 KB
Vue	~34.7 KB
htmx	~14 KB

htmx weighs about one-third of Vue and less than one-quarter of Angular. And these are just the core frameworks — real applications typically include libraries for routing, state management, form handling, HTTP client, and much more.

Building with HTML Instead of Fighting with JavaScript Layers 🛠️

HTML-first tools let you focus on the actual structure and behavior 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 simply send HTML from the server, and the library swaps the right parts on the page. No 20-file folders for a single React component. No client-side state management libraries. No over-engineering.

It’s an approach that feels surprisingly straightforward and linear.

A Practical Example

Let’s consider a simple button that loads dynamic content.

Traditional SPA approach (React):

// useState, useEffect, fetch API, loading state management,
// error handling, conditional rendering...
function LoadDataButton() {
const [data, setData] = useState(null);
const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);

const handleClick = async () => {
setLoading(true);
try {
const response = await fetch('/api/data');
const json = await response.json();
setData(json);
} catch (e) {
setError(e);
} finally {
setLoading(false);
}
};

return (
<div>
<button onClick={handleClick} disabled={loading}>
{loading ? 'Loading...' : 'Load Data'}
</button>
{error && <div className="error">{error.message}</div>}
{data && <DataDisplay data={data} />}
</div>
);
}

HTML-first approach with htmx:

<button hx-get="/data"
hx-target="#result"
hx-indicator="#loading">
Load Data
</button>
<span id="loading" class="htmx-indicator">Loading...</span>
<div id="result"></div>

The server returns the HTML ready to display directly. End of story.

✨ The difference is clear: 30+ lines of React code vs 5 lines of HTML with htmx. Same result, radically different complexity.

Performance Improves Almost Automatically ⚡

SPAs ship tons of JavaScript to the browser — and the browser pays for it every time: parsing, executing, hydrating, diffing the virtual DOM, 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.

The Data Confirms

According to a 2024 study:

The median Time to Interactive (TTI) for SPAs was 2.9 seconds, versus 1.8 seconds for SSR sites
The median Time to First Byte (TTFB) was 0.6 seconds for SPAs, versus 0.2 seconds for SSR

Users — especially mobile users — feel the difference immediately.

Why Server-Side Rendering is Faster for Content

SSR’s advantage lies primarily in the faster time to display content, which becomes more evident on slow Internet connections or underpowered devices. Server-rendered markup doesn’t need to wait for all JavaScript to be downloaded and executed to be displayed, so users see a fully rendered page sooner.

This generally translates to better Core Web Vitals metrics, superior user experience, and can be critical for applications where content display time is directly associated with conversion rate.

Server-Driven UI is Cleaner for Most Business Applications 🏢

Most real logic — validation, business 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 understand and debug.

One Routing, One Source of Truth

One of the most underrated aspects of the HTML-first approach is the elimination of routing duplication. In traditional SPAs, you inevitably end up with two parallel routing systems: one on the server (for APIs and initial rendering) and one on the client (for internal navigation). This means double configuration, double maintenance, and often hard-to-debug inconsistencies.

With htmx and the server-driven approach, there’s only one routing: the server’s. URLs correspond directly to resources, the browser handles navigation natively, and the developer has a single source of truth to maintain.

Validation: Only Where It Really Matters

The same principle applies to formal checks and data validation. In SPA architectures, developers often find themselves implementing the same validation logic twice: on the client (to provide immediate feedback and improve UX) and on the server (where checks MUST always reside for security reasons).

With the HTML-first approach, validation stays where it belongs: on the server. And thanks to the speed of partial HTML responses, user feedback is still almost instant. The server validates the data and returns the HTML with any error messages already rendered. No logic duplication, no risk of inconsistencies between client and server rules, no possibility of a malicious user bypassing client-side checks.

What if you want to implement a client-side check to avoid too many server requests? You can always do it! The fundamental difference is that you’re not forced to implement validation twice — you can choose to do it only when it makes sense for UX, knowing that server-side validation is already guaranteed.

🔐 Security note: Client-side validation is always bypassable. A malicious user can simply disable JavaScript or modify HTTP requests. Server-side validation is not optional — it’s the only one that really matters for security.

The HATEOAS Pattern Revives

The HTML-first approach aligns with the HATEOAS architectural principle (Hypermedia as the Engine of Application State), one of the original REST constraints often ignored in modern JSON APIs.

But what exactly does this principle say? HATEOAS states that a client should be able to interact with an application entirely through the hypermedia responses dynamically provided by the server. In other words, the client should have no prior knowledge of how to interact with the server beyond an initial entry point — all possible actions should be discovered dynamically through the links and controls present in the response itself.

Think about it: when the server returns HTML, it automatically returns links to related pages, forms for available actions, buttons for permitted operations. The interface is the API. The browser already knows how to navigate links and submit forms — no client-side logic is needed to “interpret” the response and decide what to do next.

Can your JSON-APIs do this? In the vast majority of cases, no. JSON APIs return raw data that the client must interpret, and navigation and interaction logic must be implemented separately in the front-end code. The client must “know” beforehand which endpoints to call, how to construct requests, and how to interpret responses — effectively violating the HATEOAS principle.

Let’s make a concrete example: a customer list that shows the individual customer’s detail on click.

With a traditional JSON-API:

{
"customers": [
{"id": 1, "name": "Mario Rossi", "email": "mario@example.com"},
{"id": 2, "name": "Luigi Verdi", "email": "luigi@example.com"}
]
}

The client receives this data and must know beforehand that to get the detail it needs to call /api/customers/{id}. This knowledge is hardcoded in the front-end JavaScript code. If the URL changes, the client breaks. If there are access rules that prevent viewing certain customers, the client doesn’t know until it tries to call the endpoint and receives an error.

With htmx and the HTML-first approach:

<ul>
<li>
<a hx-get="/customers/1" hx-target="#detail">Mario Rossi</a>
</li>
<li>
<a hx-get="/customers/2" hx-target="#detail">Luigi Verdi</a>
</li>
</ul>
<div id="detail"></div>

The server returns the HTML with links already embedded. The client doesn’t need to “know” anything — it simply follows the links present in the response. If a user doesn’t have access to a certain customer, the server simply doesn’t include that link in the list. If the URL changes, the server generates the new links and the client continues working without modifications.

Which of the two approaches respects HATEOAS? Only the second. HTML is hypermedia by definition — it was designed exactly for this purpose.

To be precise, a well-designed JSON-API should include a links property for related resource discovery:

{
"customers": [
{
"id": 1,
"name": "Mario Rossi",
"email": "mario@example.com",
"links": {
"self": "/api/customers/1",
"orders": "/api/customers/1/orders"
}
}
],
"links": {
"self": "/api/customers",
"next": "/api/customers?page=2"
}
}

But let’s be honest: the vast majority of JSON-APIs in production don’t implement these links. And even when they do, the problem isn’t solved: the client still needs to have a UI ready and capable of interpreting that data and displaying it appropriately. JSON links tell where to go, but not how to present what’s found. The client still needs to “know” that a customer has a name, an email, and that orders should be displayed in a table with certain columns.

With HTML, instead, the representation is already included in the response. No client-side rendering logic needed.

With htmx, the server doesn’t just return data, but returns complete user interface representations with links and available actions already embedded. This eliminates an entire category of problems related to state synchronization between client and server.

Less Code and Fewer Dependencies 📦

One of the biggest benefits is simply a smaller codebase:

No huge bundle to optimize and debug
No complicated build pipeline (webpack, babel, typescript config, etc.)
Fewer moving parts that can break
Easier onboarding for new team members
Fewer version upgrade headaches

This also translates to fewer bugs and faster long-term maintenance.

The Hidden Cost of Complexity

Every JavaScript library you add to the project brings a cost that goes well beyond the kilobytes of the initial download.

Take a typical example: you want to format a date. You install moment.js (or a modern alternative). But that library has its dependencies, which in turn have others. Suddenly, to format “2025-01-15” as “January 15, 2025”, you’ve added hundreds of kilobytes to your bundle.

And it doesn’t end there. Every library:

Has its own release cycle with breaking changes
Can have security vulnerabilities requiring urgent updates
Must be compatible with all other project libraries
Adds time to build and deploy

Many developers install libraries like lodash, axios, or moment just to use a single function. It’s like buying an entire toolbox just to use the screwdriver.

⚠️ Warning: Every dependency is a potential breaking point. JavaScript supply chain incidents continue to occur regularly — from compromised packages to maintainers abandoning critical projects. Fewer dependencies = fewer risks.

With the HTML-first approach, much of this complexity simply disappears. Date formatting happens on the server (where you have full control over the format), HTTP requests are handled by htmx with a few attribute lines, and the DOM is automatically updated with the received HTML. No need to reinvent the wheel with 200 KB of JavaScript.

Progressive Enhancement: Evolution, Not Rewrite 🔄

You can add htmx to almost any existing backend without overhauling the entire project structure.

Need a dynamic table? Enhance that section.

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

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

The Three Levels of Progressive Enhancement

Progressive enhancement is based on three fundamental principles:

Content First: At the heart of every website is its content. Progressive enhancement ensures that content is accessible to all users, even those with very basic browsers or slow Internet connections. This means starting from a solid HTML foundation. 1.

Basic Functionality: Ensure that core features work without advanced JavaScript. With htmx this is possible if you design carefully: links can have a standard href as fallback, forms can work with a normal submit. htmx enhances HTML’s standard behavior. However, it’s important to note that features based on buttons with hx-get or hx-post (that aren’t form submits) require JavaScript — it’s up to the developer to decide where graceful degradation is important and design accordingly. 1.

Enhanced Experiences: Progressively add advanced features for browsers and devices that support them.

Wikipedia, powered by MediaWiki, is a perfect example: it’s readable, navigable, and even editable using the basic HTML interface without styling or scripts, but it’s enhanced when these are available.

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. The back button, deep linking, accessibility tools, and SEO all behave naturally.

No hacks required.

SEO Benefits

Since the base content is always accessible to search engine spiders, pages built with progressive enhancement methods avoid the problems that can hinder indexing, while having to render the page’s base content through JavaScript execution makes crawling slow and inefficient.

This strategy speeds up loading and makes crawling by search engines easier, as the text on the page loads immediately through the HTML source code rather than having to wait for JavaScript to initialize and load content later.

Search engines prioritize accessible and easy-to-read content. Starting from a clean HTML structure and ensuring content is available to all users improves the chances of ranking well in search results.

Ready for the AI Search Era

There’s an aspect that many developers aren’t yet considering: the rise of AI-based search engines. Tools like ChatGPT Search, Perplexity, Google AI Overviews, and others are radically changing how users find information online.

These AI systems need clear, structured, and immediately accessible content. While some modern crawlers can execute JavaScript, execution is often limited, delayed, or incomplete. A SPA that loads content dynamically via JavaScript risks being indexed partially, inaccurately, or with significant delays compared to sites with immediate HTML content.

With the HTML-first approach, content is already present in the HTML document served by the server. AI crawlers (as well as traditional search engine spiders) can immediately access, understand, and index all content. No waiting for JavaScript execution, no risk of parts of the page not being seen.

In a world where more and more traffic will come from AI-generated responses, having easily accessible and well-structured content is no longer just a best practice — it’s a competitive necessity.

🤖 Prepare for the future: AI crawlers are becoming increasingly important. A site invisible to AI is a site losing opportunities. HTML-first puts you in pole position.

Accessibility Benefits

One of the most significant benefits of progressive enhancement is improved accessibility. Starting from a solid HTML foundation ensures that content is accessible to all users, including those with disabilities.

Screen readers and other assistive technologies work natively with semantic HTML. SPAs, on the other hand, often require complex ARIA implementations and specialized testing to reach the same level of accessibility.

htmx: The Rising Star ⭐

htmx is experiencing impressive growth. According to JavaScript Rising Stars 2024, htmx gained more annual GitHub stars than more established libraries like Vue and Angular (note: this refers to annual star growth, not total).

The Numbers of Success

In the Stack Overflow Developer Survey 2024, htmx is the 22nd most used web framework with 3.3% of developers using it
In terms of satisfaction, htmx is the 2nd most “admired” web framework with 72.9% in the Stack Overflow 2024 survey, second only to Elixir’s Phoenix framework (83.7%)
In the Django Developers Survey, htmx usage went from 5% in 2021 to 16% in 2022 — 220% growth
htmx 2.0.0 was released on June 17, 2024, marking an important maturity milestone
htmx was admitted to the GitHub Accelerator in 2023, a program that selects the most promising open source projects

What Makes htmx Special

htmx is small (~14-16 KB min.gz), dependency-free, extensible, and according to reports, has reduced code size by 67% compared to React in comparable projects.

htmx doesn’t just reduce bundle size — it eliminates the need for Virtual DOM diffing, component lifecycles, and client-side state orchestration. The result is faster page loads, less code to debug, and a lighter mental model for building user interfaces.

Ideal for Enterprise Apps, Dashboards, and Portals 💼

Not every application is a highly interactive design tool. Many 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.

Perfect Use Cases for HTML-First

Administrative dashboards: Tables with pagination, filters, CRUD actions
Internal portals: Document management, workflow approval, reporting
E-commerce backend: Order management, inventory, customers
Complex multi-step forms: Registration wizards, product configurators
Booking systems: Calendars, reservations, slot management
CRM and ERP: Contact management, sales pipeline, invoicing
Data-entry applications: Data import/export, bulk editing

htmx and Delphi: A Winning Combination 🚀

For Delphi developers, the HTML-first approach with htmx represents a particularly interesting opportunity. DelphiMVCFramework offers excellent support for this paradigm, allowing you to leverage the power and reliability of a Delphi backend with a modern, lightweight front-end.

Benefits for Delphi Developers

Robust backend: Delphi’s solidity and performance on the server
Powerful template engines: TemplatePro or WebStencils for dynamic HTML generation
Simple deployment: A single executable without node.js dependencies
No JavaScript build: Goodbye webpack, npm, and complex tool chains
Reusable skills: Delphi developers can be productive immediately

The quickstart projects available on GitHub (TemplatePro + htmx and WebStencils + htmx) offer an ideal starting point.

💡 Tip: If you’re a Delphi developer and want to start with htmx, clone one of the quickstart projects and you’ll have a working application in minutes. No npm configuration, no webpack, no 500 MB node_modules.

When NOT to Use the HTML-First Approach ⚖️

It’s important to be honest: the HTML-first approach isn’t the solution for everything. Here’s when traditional SPAs remain the better choice:

Highly interactive real-time applications: Graphic editors, collaboration tools like Google Docs, video editing applications
Offline-first applications: When the application needs to work significantly without connection
Games and 3D applications: Where intensive client-side rendering is necessary
Applications with complex client state: Where the interface state is significantly different from server state

For these types of applications, SPAs offer concrete advantages: sophisticated local state management, fluid transitions between complex views, and the ability to work offline with service workers.

The Future: A Hybrid Approach 🔮

The trend we’re observing isn’t a return to the past, but an evolution toward a more pragmatic approach. The best developers are learning to choose the right tool for the specific problem.

The Islands Architecture Paradigm

An emerging trend is “Islands Architecture”, where most of the page is static or server-rendered HTML, with JavaScript interactivity “islands” only where needed. Frameworks like Astro.js (with an impressive 94% of users who would use it again according to State of JavaScript 2024) are exploring this territory.

htmx fits perfectly into this paradigm, allowing you to add interactivity where needed without requiring a completely client-side architecture.

Conclusions 🎯

React and Angular absolutely have their place, and they’re great when you really need a complex client-side application. But for many projects, the 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.

With htmx now having over 72% satisfaction among developers, explosive GitHub star growth, and adoption by increasingly larger teams, it’s clear this isn’t just a passing trend. It’s a rediscovery of fundamental web principles, empowered by modern tools that make the development experience smooth and enjoyable.

The next time you start a new web project, before automatically reaching for React or Vue, ask yourself: “Do I really need all this?” The answer might surprise you.

🚀 Ready to try? Start with a small project or improve a section of an existing application. htmx doesn’t require a complete rewrite — you can adopt it gradually and see the benefits immediately.

Resources to Learn More 📚

🎓 Want to dive deeper with a course? bit Time Professionals offers dedicated courses on htmx and on the DelphiMVCFramework + TemplatePro + htmx integration. Taking a structured course allows you to be productive right away, with practical applications, real examples, proven architectural patterns, and best practices learned from years of field experience. Courses are available in Italian, English, and Spanish.