Introduction: The Hypermedia Renaissance We are living in the middle of a hypermedia renaissance. Frameworks like HTMX have correctly identified that the "Single Page Application" (SPA) model often introduces unnecessary complexity, pushing developers to manage state in two places and build expensive APIs for what should be simple UI updates. The core premise of HTMX is brilliant: Hypermedia as the Engine of Application State (HATEOAS). By returning HTML fragments (partials) from the server instead of raw data, we keep the logic where it belongs—on the server—and keep the client thin and declarative. Hypermedia as the Engine of Application State (HATEOAS) But in its quest for hypermedia purity, HTMX has made a dogmatic choice that might be holding the movement back: The insistence that the wire format must be HTML. The insistence that the wire format must be HTML. must It’s time to talk about why JSON partials aren't just an alternative - they could be the future of the hypermedia-driven web. The Performance Myth: Is HTML Actually Faster? One of the most common arguments for HTML partials is that the browser "knows how to parse HTML." The assumption is that taking an HTML string and throwing it into innerHTML is the fastest way to update the DOM. innerHTML But the data tells a different story. In benchmarks comparing 100-row and 1000-row table renders, we looked at several ways to update the DOM. We compared standard HTML methods (innerHTML, DOMParser) against JSON-based methods using vDOM (Virtual DOM) and oDOM (Object DOM) formats. Both vDOM and oDOM are lightweight JSON representations of the DOM that allow for structured UI definitions. innerHTML DOMParser vDOM oDOM vDOM oDOM 100 Rows (10 Cycles) - Chrome Latest Method

Raw Size

Gzip Size

Avg (ms)

Min (ms)

Max (ms)



innerHTML

27.24 KB

1.08 KB

1.25

0.80

2.20



DOMParser

27.24 KB

1.08 KB

1.39

0.80

1.80



Raw vDOM (JSON)

46.66 KB

1.17 KB

1.54

1.20

2.30



Raw oDOM (JSON)

30.67 KB

1.08 KB

1.14

0.90

1.50



Lightview vDOM

46.66 KB

1.17 KB

2.88

1.80

3.90



Lightview Tagged

--

--

2.21

1.60

3.70 Method

Raw Size

Gzip Size

Avg (ms)

Min (ms)

Max (ms)



innerHTML

27.24 KB

1.08 KB

1.25

0.80

2.20



DOMParser

27.24 KB

1.08 KB

1.39

0.80

1.80



Raw vDOM (JSON)

46.66 KB

1.17 KB

1.54

1.20

2.30



Raw oDOM (JSON)

30.67 KB

1.08 KB

1.14

0.90

1.50



Lightview vDOM

46.66 KB

1.17 KB

2.88

1.80

3.90



Lightview Tagged

--

--

2.21

1.60

3.70 Method

Raw Size

Gzip Size

Avg (ms)

Min (ms)

Max (ms) Method Method Raw Size Raw Size Gzip Size Gzip Size Avg (ms) Avg (ms) Min (ms) Min (ms) Max (ms) Max (ms) innerHTML

27.24 KB

1.08 KB

1.25

0.80

2.20 innerHTML innerHTML innerHTML 27.24 KB 27.24 KB 1.08 KB 1.08 KB 1.25 1.25 0.80 0.80 2.20 2.20 DOMParser

27.24 KB

1.08 KB

1.39

0.80

1.80 DOMParser DOMParser DOMParser 27.24 KB 27.24 KB 1.08 KB 1.08 KB 1.39 1.39 0.80 0.80 1.80 1.80 Raw vDOM (JSON)

46.66 KB

1.17 KB

1.54

1.20

2.30 Raw vDOM (JSON) Raw vDOM (JSON) Raw vDOM (JSON) 46.66 KB 46.66 KB 1.17 KB 1.17 KB 1.54 1.54 1.20 1.20 2.30 2.30 Raw oDOM (JSON)

30.67 KB

1.08 KB

1.14

0.90

1.50 Raw oDOM (JSON) Raw oDOM (JSON) Raw oDOM (JSON) 30.67 KB 30.67 KB 1.08 KB 1.08 KB 1.14 1.14 1.14 0.90 0.90 1.50 1.50 1.50 Lightview vDOM

46.66 KB

1.17 KB

2.88

1.80

3.90 Lightview vDOM Lightview vDOM Lightview vDOM 46.66 KB 46.66 KB 1.17 KB 1.17 KB 2.88 2.88 1.80 1.80 3.90 3.90 Lightview Tagged

--

--

2.21

1.60

3.70 Lightview Tagged Lightview Tagged Lightview Tagged -- -- -- -- 2.21 2.21 1.60 1.60 3.70 3.70 1000 Rows (10 Cycles) - Chrome Latest Method

Raw Size

Gzip Size

Avg (ms)

Min (ms)

Max (ms)



innerHTML

274.21 KB

9.17 KB

11.57

5.80

15.40



DOMParser

274.21 KB

9.17 KB

8.49

6.70

12.40



Raw vDOM (JSON)

467.66 KB

9.05 KB

11.14

9.20

16.90



Raw oDOM (JSON)

308.41 KB

9.18 KB

8.83

7.60

10.00



Lightview vDOM

467.66 KB

9.05 KB

15.70

12.80

20.30



Lightview Tagged

--

--

16.29

13.40

23.90 Method

Raw Size

Gzip Size

Avg (ms)

Min (ms)

Max (ms)



innerHTML

274.21 KB

9.17 KB

11.57

5.80

15.40



DOMParser

274.21 KB

9.17 KB

8.49

6.70

12.40



Raw vDOM (JSON)

467.66 KB

9.05 KB

11.14

9.20

16.90



Raw oDOM (JSON)

308.41 KB

9.18 KB

8.83

7.60

10.00



Lightview vDOM

467.66 KB

9.05 KB

15.70

12.80

20.30



Lightview Tagged

--

--

16.29

13.40

23.90 Method

Raw Size

Gzip Size

Avg (ms)

Min (ms)

Max (ms) Method Method Raw Size Raw Size Gzip Size Gzip Size Avg (ms) Avg (ms) Min (ms) Min (ms) Max (ms) Max (ms) innerHTML

274.21 KB

9.17 KB

11.57

5.80

15.40 innerHTML innerHTML innerHTML 274.21 KB 274.21 KB 9.17 KB 9.17 KB 11.57 11.57 5.80 5.80 15.40 15.40 DOMParser

274.21 KB

9.17 KB

8.49

6.70

12.40 DOMParser DOMParser DOMParser 274.21 KB 274.21 KB 9.17 KB 9.17 KB 8.49 8.49 6.70 6.70 12.40 12.40 Raw vDOM (JSON)

467.66 KB

9.05 KB

11.14

9.20

16.90 Raw vDOM (JSON) Raw vDOM (JSON) Raw vDOM (JSON) 467.66 KB 467.66 KB 9.05 KB 9.05 KB 11.14 11.14 9.20 9.20 16.90 16.90 Raw oDOM (JSON)

308.41 KB

9.18 KB

8.83

7.60

10.00 Raw oDOM (JSON) Raw oDOM (JSON) Raw oDOM (JSON) 308.41 KB 308.41 KB 9.18 KB 9.18 KB 8.83 8.83 8.83 7.60 7.60 10.00 10.00 10.00 Lightview vDOM

467.66 KB

9.05 KB

15.70

12.80

20.30 Lightview vDOM Lightview vDOM Lightview vDOM 467.66 KB 467.66 KB 9.05 KB 9.05 KB 15.70 15.70 12.80 12.80 20.30 20.30 Lightview Tagged

--

--

16.29

13.40

23.90 Lightview Tagged Lightview Tagged Lightview Tagged -- -- -- -- 16.29 16.29 13.40 13.40 23.90 23.90 Data source: Lightview DOM Benchmarks (Chrome Latest) Data source: Lightview DOM Benchmarks (Chrome Latest) Lightview DOM Benchmarks The results are surprising: Although results may differ slightly depending on the browser and device, parsing a structured JSON object and using createElement can be as efficient as asking the browser to tokenize and parse a flat HTML string. createElement From a user experience perspective, the difference between any approach will be imperceptible. Most monitors refresh at 60Hz, meaning a frame lasts ~16.6ms. For typical partials (the 100-row case), every single method—including Lightview—completes in less than 3ms, which is roughly 1/5th of a single frame. Even at 1000 rows, every method completes within or very near the one-frame threshold. The perceived behavior will remain smooth and responsive, far outclassing the "jank" often associated with full page reloads. ~16.6ms 1/5th of a single frame While more complex implementations like Lightview vDOM add overhead (taking ~2.88ms for 100 rows and ~15.70ms for 1000 rows), this overhead buys you the immense power of fine-grained reactivity. Instead of just swapping a partial, the framework can track exactly which nodes need to update when data changes. Lightview vDOM fine-grained reactivity Network Bandwidth: The Gzip Equalizer There is a frequent claim that JSON is inherently smaller than HTML. Theoretically, it could be 20% to 25% smaller based on its non-repeating syntax. However, when we look at standard UI components using common tags like div, h#, p, span, td, and tr, the reality is more nuanced. div h# p span td tr JSON requires quoting every property and string value (e.g., {"td":"value"} vs <td>value</td>). In many cases, this quoting overhead makes raw JSON larger than raw HTML. In our benchmark, the raw oDOM (Object DOM) was ~308 KB compared to HTML's ~274 KB. {"td":"value"} <td>value</td> raw JSON larger than raw HTML However, Gzip is the great equalizer. Because JSON has a very regular structure, it compresses exceptionally well. In our 1000-row test, the Gzip sizes were almost identical: Gzip is the great equalizer HTML Gzip: 9.17 KB
JSON (oDOM) Gzip: 9.18 KB
JSON (vDOM) Gzip: 9.05 KB HTML Gzip: 9.17 KB HTML Gzip JSON (oDOM) Gzip: 9.18 KB JSON (oDOM) Gzip JSON (vDOM) Gzip: 9.05 KB JSON (vDOM) Gzip Even if JSON were smaller than the raw HTML, it is likely Gzip would still equalize their size due to HTML’s repetitive tag names and angle braces. Bandwidth should rarely be a primary determining factor between the two formats, unless browsers were to natively support a more compact, unquoted JSON format. While it is possible to transmit unquoted JSON and eval it on the client, this introduces significant security vulnerabilities. Furthermore, a custom JavaScript parser for unquoted JSON is unlikely to ever match the performance of a browser's native, highly-optimized JSON.parse. eval JSON.parse Ultimately, the choice between HTML and JSON shouldn't be based on a few bytes of bandwidth, but on factors like flexibility, security, and developer experience. The Flexibility Factor: Beyond the Browser This is where the HTML-only approach truly shows its limits. HTML is a document format designed for browsers. If your server returns HTML partials, you are effectively tethering your backend to a specific rendering engine. JSON, however, can serve as a Universal DOM Representation. When a server returns a UI partial as JSON (a vDOM or oDOM structure), it isn't just "data"—it's a platform-agnostic description of an interface. Universal DOM Representation This flexibility allows for: Cross-Platform Targeting: A single JSON partial from the server can be rendered as HTML in a browser, but it can just as easily be mapped to native iOS (SwiftUI) or Android (Jetpack Compose) components.
Native Performance: By sending a description instead of a document, native apps can use their own optimized layout engines rather than forcing content into a resource-heavy WebView. Cross-Platform Targeting: A single JSON partial from the server can be rendered as HTML in a browser, but it can just as easily be mapped to native iOS (SwiftUI) or Android (Jetpack Compose) components. Cross-Platform Targeting Native Performance: By sending a description instead of a document, native apps can use their own optimized layout engines rather than forcing content into a resource-heavy WebView. Native Performance We are seeing this trend emerge with technologies like Google's A2UI, which uses JSON to bridge the gap between platforms. Lightview is also built on this principle, treating JSON partials as the "source of truth" for the UI, whether it eventually ends up in the standard DOM, the Shadow DOM, or a native mobile view. A2UI Lightview By choosing JSON over HTML for your partials, you aren't sacrificing hypermedia; you're gaining platform independence. platform independence Security and the AI Frontier The rise of AI-generated user interfaces (GenUI) adds another layer to this debate. Letting an LLM generate raw HTML or worse, JavaScript, is a security risk. JSON partials allow for a "sandboxed" UI. In Lightview, we use cDOM (Computational DOM) and JPRX (JSON Path Reactive eXpressions) along with XPath expressions. This allows the server to send a JSON-like structure that defines both the layout and the reactive logic (like "if this happens, update that") without ever executing arbitrary eval() or <script> tags. cDOM (Computational DOM) cDOM (Computational DOM) JPRX (JSON Path Reactive eXpressions) eval() <script> It is "Logic-in-JSON"- a safe, declarative way to build dynamic interfaces that even an AI can generate without opening a backdoor into your application. A Challenge to HTMX HTMX has done wonders for the web development community. It has simplified our lives and reminded us of the power of the web's original architecture. But it shouldn't stop at HTML. Imagine an enhancement to HTMX that supports JSON partials. By allowing the client to receive structured UI definitions, HTMX could pave the way for safer, more dynamic, and cross-platform hypermedia applications. It would bridge the gap between the simplicity of HATEOAS and the power of dynamic, safe AI-generated interfaces. Not All-or-Nothing To be clear: we aren't suggesting that you send your entire website as a giant JSON blob. Initial page loads should still be semantic HTML—that's what browsers and SEO crawlers want. But for dynamic partials - the updates, the modals, the infinite scrolls, and the live dashboards—the "wire" should be JSON. It’s as fast as HTML, more flexible, and safer. dynamic partials Hypermedia is the right architecture. JSON is just a better engine. To see the raw performance data for yourself, check out the DOM Benchmark tester. To see the raw performance data for yourself, check out the DOM Benchmark tester. DOM Benchmark tester

This story contains new, firsthand information uncovered by the writer.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

The HTML Partial Trap: Why HTMX is Only Half the Story

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

AI Empathy Across Disciplines

How to Create a Responsive Table with HTMX and Django

Introducing gdocweb: Web Building with Java 21, Spring Boot 3.x, and More

Augmenting the Client With HTMX

How to Deploy Go + Templ + HTMX + TailwindCSS to Production

Why I Ditched JavaScript and Built a SaaS Stack With HTMX, Go & Postgres That Just Works

AI Empathy Across Disciplines

How to Create a Responsive Table with HTMX and Django

Introducing gdocweb: Web Building with Java 21, Spring Boot 3.x, and More

Augmenting the Client With HTMX

How to Deploy Go + Templ + HTMX + TailwindCSS to Production

Why I Ditched JavaScript and Built a SaaS Stack With HTMX, Go & Postgres That Just Works

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps