Building with Hypermedia: HTMX's Purity and Lightview's Flexibility.

Introduction

The hypermedia renaissance is in full swing. After years of SPA dominance, developers are rediscovering the power of server-driven architectures that leverage HTML as the engine of application state. The framework leading this charge, HTMX, focuses exclusively of hypermedia. An alternative, Lightview, doesn't lock you into hypermedia-only patterns. Unlike HTMX's focused hypermedia approach, Lightview is a multi-paradigm framework that supports and hypermedia patterns, functional programming with template tag functions like BauJS [https://github.com/grucloud/bau], and JSON representation (like JurisJS [https://jurisjs.com]), - all within the same framework. This article provides a technical comparison of HTMX and Lightview hypermedia capabilities to help you choose the right tool for your project. It also inlcudes some tangential Ligthview features that may incline you to choosing an approach that is not strictly client-server hypermedia.

You might say at this point, "Wait a second, HTMX is supposed to simplify development, why would I want the complexity of multiple coding paradigms?" You might not, the point of Lightview is to give you choice, you could build your entire application with hypermedia, or you could build your entire application with functional programming, or you could build your entire application with JSON representation, or you could build your entire application with a mix of all three. It all depends on what you need. Perhaps your app starts out hypermedia, but as you grow, you find that you need to use functional programming to build complex business logic in an offline first mode, or you find that you need to use JSON representation for cross-platform portability, or you you need to add dynamic AI generated aspects that are computational but browser safe.

What is Hypermedia?

Before diving into the comparison, let's establish what we mean by hypermedia. Hypermedia refers to content that contains links and controls for navigating to related resources. Traditional HTML provides this through links and forms, but modern hypermedia frameworks extend these capabilities to any element, enabling richer interactions. Any element can serve as a link and any element can specify the source from which it desires to obtain its content. The samllest of these is perhaps htmz.

HTMX and Lightview: Completing HTML as a Hypertext

HTMX, created by Carson Gross as a successor to intercooler.js, aims to "complete HTML as a hypertext." It extends standard HTML attributes to provide AJAX, CSS Transitions, WebSockets, and Server-Sent Events directly in markup.

Lightview, created by this author, Simon Blackwell, was designed in collaboration with LLMs, to not only complete HTML as hypertext, but to also provide a more portable, declaritive approach for the server delivery of content, although the hypermedia content can still be HTML like HTMX, it can also be JSON virtual DOMs that represents HTML or native UI components.

Core Philosophy

HTMX embraces the Hypermedia-Driven Application (HDA) architecture, characterized by two constraints:

Declarative syntax: Uses HTML-embedded attributes rather than imperative scripting
Hypermedia responses: The server responds with HTML, not JSON

This approach keeps the complexity on the server, while the client remains simple and declarative.

Key Features

HTTP Method Support: HTMX allows any element to issue HTTP requests using standard verbs:

<button hx-delete="/contacts/1" 
        hx-target="#contact-list"
        hx-confirm="Are you sure?">
    Delete Contact
</button>

Flexible Targeting: The hx-target attribute specifies where server responses should be inserted, using CSS selectors:

<input type="text" 
       hx-get="/search" 
       hx-trigger="keyup changed delay:500ms"
       hx-target="#results">

Event Triggers: Custom triggers control when requests fire:

<div hx-get="/news" 
     hx-trigger="every 30s">
    <!-- Auto-refreshing content -->
</div>

Swap Strategies: Multiple options for how content replaces existing DOM:

innerHTML (default)
outerHTML
beforebegin, afterbegin, beforeend, afterend
delete, none

CSS Transitions and Animations: HTMX provides built-in support for smooth UI transitions through stable element IDs, swap phase classes (htmx-swapping, htmx-settling, htmx-added), request state indicators (htmx-request), timing modifiers (swap:1s, settle:1s), and integration with the View Transitions API. This allows hypermedia-driven applications to achieve SPA-like smoothness without custom JavaScript.

Progressive Enhancement: HTMX's hx-boost can enhance existing links and forms:

<body hx-boost="true">
    <!-- All links and forms now use AJAX -->
</body>

WebSockets & SSE: Native support for real-time updates:

<div hx-ws="connect:/chatroom">
    <div hx-ws="send">
        <input name="message">
    </div>
</div>

Dependencies

HTMX has zero dependencies, making it ideal for adding hypermedia capabilities to existing applications without introducing additional complexity.

Lightview: Multi-Paradigm Framework with Hypermedia Support

Lightview also has zero dependencies unless you choose to use its pre-built UI components, and it takes a different approach by offering multiple programming paradigms in one framework. While it includes hypermedia capabilities similar to HTMX, it doesn't force you to use them exclusively. You can use declarative hypermedia patterns, functional programming, or data-driven JSON definitions—all within the same application. The Lightview website provides extensive online documentation and interactive REPLs for trying out the framework.

Core Philosophy: The Power of Choice

Lightview is flexible by design. It doesn't prescribe hypermedia as the only architecture. Instead, it lets you choose the right tool for the specific part of your application:

Hypermedia (HTMX-style): Use src and href for server-driven content and page navigation.
Functional (BauJS-style): Use Javascript template tag functions for complex, imperative logic.
Data-Driven (JurisJS-style): Define UIs as pure JSON (vDOM/oDOM) for config-driven interfaces.
AI-Safe (cDOM): Use sandboxed JSON structures with an executable expression language (JPRX) for safe, AI-generated user interfaces.

1. Hypermedia & Interaction

Lightview's hypermedia system is built on standard HTML attributes (src, href) extended with powerful capabilities.

Unified Attributes:

src: Fetches content to populate an element. Can be a URL (for server-side partials) or a CSS selector (for local partials).
href: Triggers navigation or content loading on user interaction (e.g., <button href="/page.html">).

Targeting & Location: Lightview offers sophisticated control over where content is inserted using the target attribute or location setting.

Standard Locations: innerhtml, outerhtml, beforebegin, afterbegin, beforeend, afterend.
Shadow DOM: Lightview has first-class support for Web Components. You can insert content directly into a shadow root using location="shadow" or the :shadow suffix on a target (e.g., target="#component:shadow"). This differentiates it from HTMX, which focuses on Light DOM.

Advanced Requests (data-method & data-body): Customize HTTP actions directly in HTML:

<!-- DELETE request -->
<button href="/api/items/123" data-method="DELETE" target="#log">Delete</button>

<!-- POST with body -->
<button href="/api/save" data-method="POST" data-body="#form-id">Save</button>

Self-Sourced Partials (CSS Selectors as Source): Another powerful Lightview differentiator is the ability to source content from the current document. While HTMX is designed to fetch hypermedia partials from a server, Lightview allows the src attribute to contain a CSS selector.

This enables "Self-Sourced Partials" where content can be pulled from a <template>, a hidden <div>, or any other element in the DOM. This reduces network overhead and allows developers to bundle "offline" partials directly within the initial page load.

Lightview takes the approach that hypermedia does not have to mean server-side partials, you can have a full hypermedia SPA.

<!-- Source content from a local template -->
<div src="#tab-1-content"></div>

<template id="#tab-1-content">
  <h3>Tab 1</h3>
  <p>This content was sourced from a local template tag!</p>
</template>

Automatic Hash Scrolling: Lightview supports automatic scrolling to a specific element ID when loading content via src or navigating via href. If the URL includes a hash fragment (e.g., /docs/api.html#signals), Lightview will automatically wait for the content to load and then scroll the target element into view.

Smart Offsets: The scroll position automatically accounts for a fixed navigation bar if defined (via --site-nav-height).
Shadow DOM Support: Scrolling also works for content loaded into a Shadow Root.
Partial Loading: Works for both full navigation (href) and partial content updates (src).

Declarative Event Gating (lv-before) and Triggers: Lightview provides a powerful "Gating" system to intercept events before they trigger actions. This replaces the need for custom event listeners for common patterns.

Modifiers: Built-in support for throttle(ms) and debounce(ms).
Pipelines: Chain multiple gates (e.g., lv-before="click throttle(500) confirm('Are you sure?')" ).
Custom Gates: Define global functions to validate actions (e.g., validateUser()) that return false to cancel the event.

2. Reactivity & State

Lightview includes a built-in, fine-grained reactivity system (Signals and State) that allows for instant updates and automatic template resolution. This separates it from HTMX, which primarily relies on server-rendered responses or DOM-based state for changes.

This system provides:

Automatic Template Resolution: ${...} tags in HTML are automatically updated when state changes.
Named Registration: Signals and states can be registered by name for easy template binding.
JSON Schema Control: Enforce data integrity on reactive state using standard JSON Schema.

For a detailed technical comparison of Lightview's reactive state vs. HTMX's server-driven approach, see the State Management section.

3. Data-Driven & AI User Interfaces

One of Lightview's most distinct features is its support for Data-as-UI (vDOM, oDOM) and Safe AI-Generation (cDOM).

Multiple JSON Formats: Lightview can fetch and render UI defined as JSON, which is often easier for backends to generate and manage than HTML strings.

vDOM: Standard Virtual DOM structure.
oDOM: "Object DOM" shorthand for concise config-based UIs.

/* vDOM (Explicit) */
[{ "tag": "div", "attributes": { "class": "p-4" }, "children": ["Hello"] }]

/* oDOM (Concise) */
{ "div": { "class": "p-4", "children": ["Hello"] } }

/* cDOM / JPRX (Reactive & Safe) */
{ 
  "div": { 
    "children": [
      { "span": { "text": "Count: =/myVal" } },
      { "button": { "onclick": "=/myVal++", "text": "+" } }
    ] 
  }
}

Safe AI Generation with cDOM: Letting AI write raw Javascript is a security risk. Lightview's cDOM (Clean/Computed DOM) is a sandboxed JSON format where AI can define structure and logic without executing arbitrary code. In this architecture, JPRX (JSON Path Reactive eXpressions) serves as the secure logic and expression language embedded within the cDOM structure, providing the power of reactivity and logic without the security vulnerabilities of eval.

Security: No eval or arbitrary script execution.
Logic: Supports logic like "if", "loop", and math and over 100 other functions via a safe expression language (JPRX). Think of JPRX as Excel for the DOM.
Use Case: Ideal for "GenUI" applications where an LLM generates the interface on the fly.

Use cDOM when you want the dynamism of a generated UI without the security nightmare of generated Javascript.

Head-to-Head Comparison

Syntax and API Surface

HTMX:

Custom hx-* attributes for all functionality
Extensive attribute vocabulary (hx-get, hx-post, hx-target, hx-trigger, etc.)
Consistent prefix makes HTMX features immediately recognizable
Steeper learning curve due to attribute variety

Lightview:

Uses standard HTML attributes (src, href) where possible
Smaller attribute vocabulary
More familiar to developers who know HTML
JavaScript API for reactive features or cDOM/JPRX for safer reactivity

Request Handling

Both frameworks support custom HTTP methods and request bodies, but with different approaches:

HTMX uses dedicated attributes:

<form hx-post="/submit" hx-swap="outerHTML">

Lightview uses standard data- attributes for configuration:

<button href="/api/endpoint" 
        data-method="POST" 
        data-body="#myForm">
    Save
</button>

Lightview's data-body is highly flexible:

CSS Selector: Automatically serializes the target (e.g., #myForm as FormData, or an input's value).
JSON: Use json:{"id": 1} for literal JSON payloads.
Javascript: Use javascript:state.get('user') to pull data directly from reactive state.
Text: Use text:Hello for plain text payloads.

Triggering Events

HTMX has sophisticated trigger syntax:

<input hx-get="/search" 
       hx-trigger="keyup changed delay:500ms">

Lightview has a similar approach using lv-before gating:

<input oninput="search(this.value)" 
       lv-before="input debounce(500)">

Targeting and Content Positioning

Both frameworks provide flexible control over where content is inserted:

HTMX uses hx-target and hx-swap attributes:

<button hx-get="/content" 
        hx-target="#results" 
        hx-swap="beforeend">
    Load More
</button>

Lightview uses target with optional location suffix or separate location attribute:

<!-- Target with suffix -->
<button href="/content" target="#results:beforeend">
    Load More
</button>

<!-- Separate location attribute -->
<div src="/content" location="beforeend"></div>

Key difference: Lightview includes shadow as a positioning option for Shadow DOM insertion, while HTMX focuses on standard DOM manipulation. This makes Lightview more suitable for Web Components architecture.

Content Sourcing (Server vs. Local)

HTMX:

Designed for server-driven hypermedia (HDA)
Sources must be URLs that return hypermedia (HTML) responses
Requires a network request for every partial update

Lightview:

Multi-source flexibility
Sources can be URLs OR CSS selectors
Enables "Self-Sourced Partials" where content is pulled from local <template> tags or other DOM elements
Allows bundling common UI fragments to reduce initial network waterfall

Transitions and Animations

HTMX has first-class animation support with swap phase classes, request state indicators, timing modifiers, and View Transitions API integration—allowing hypermedia apps to achieve SPA-like smoothness.

Lightview currently handles transitions through standard CSS transitions/animations and component lifecycle hooks without built-in swap phase abstractions. Future versions may include built-in swap phase abstractions.

State Management

This is where the frameworks diverge most significantly in their architectural approach:

HTMX: Server-Side State

HTMX is purely hypermedia-focused. Client-side state is minimal, typically handled through:

Server Session: State is maintained in the backend database or session.
Hidden Form Fields: passing state back and forth in requests.
DOM Attributes: Storing simple state in data-* attributes.
Alpine.js Integration: For complex client-side logic, HTMX developers often reach for Alpine.js or similar lightweight libraries.

Lightview: Client-Side Reactivity

Lightview includes a complete, fine-grained reactivity system inspired by SolidJS. This makes it a multi-paradigm framework that can handle state independently of the server.

Automatic Template Resolution: When HTML is fetched via src or href, Lightview automatically resolves template literals ${...} against the current state. This allows server-rendered partials to become instantly reactive on the client without hydration scripts.

Named Registration: Signals and states can be registered by name so they are available for template resolution globally:

// Registering a reactive signal by name
const count = Lightview.signal(0, 'count');

// Registering a deeply reactive state by name
const user = Lightview.state({ name: 'Alice', age: 30 }, 'user');

<!-- Loaded content automatically updates when 'user' state changes -->
<h1>Welcome, ${state.get('user').name}</h1>

JSON Schema Validation: Lightview states can be optionally enforced by JSON schemas, providing data integrity for complex objects:

const user = Lightview.state({ name: 'Alice', age: 30 }, 'user', {
    schema: {
        type: 'object',
        properties: {
            name: { type: 'string' },
            age: { type: 'number' }
        },
        required: ['name', 'age']
    }
});

Reactive Primitives:

signal(value): For primitive values.
state(object): For deep observation of objects and arrays.
effect(fn): To run side effects when dependencies change.

This architectural difference makes Lightview more of a complete application framework, while HTMX remains a dedicated hypermedia enhancement tool.

Real-Time Updates

HTMX has first-class support for WebSockets and Server-Sent Events:

<div hx-ext="sse" sse-connect="/updates" sse-swap="message">

Lightview doesn't have built-in WebSocket/SSE support (as of the current version), though it can be added through standard JavaScript.

Security

HTMX relies on standard web security practices:

Same-origin policy
CSRF token support via hx-headers
Content Security Policy compatibility

Lightview includes security by default:

Same-domain policy enforced automatically
Dangerous protocol blocking (javascript:, data:)
Customizable validation hooks

Progressive Enhancement

HTMX excels at progressive enhancement:

<!-- Works without JS, enhanced with JS -->
<body hx-boost="true">
    <a href="/page">Link</a>
    <form action="/submit" method="post">

Lightview's with the exception it currently lacks built-in support for websockets or server-side-events, Lightview's approach is just as capable of progressive enhancement. Because href and src are supported for every element, there is no need for anything like hx-boost.

Component Architecture

HTMX doesn't have a component model—it enhances standard HTML.

Lightview includes:

Single-file components
Template components
Import/export of variables between components
Sandboxed remote components

It also provides over 50 built-in components for common UI patterns, e.g. Loading, Card, Chart, Drawer, etc.

Use Cases

When to Choose HTMX

Adding interactivity to server-rendered apps: HTMX excels at incrementally enhancing traditional web applications
Team familiarity with server-side rendering: If your team is comfortable with Rails, Django, Laravel, etc.
Progressive enhancement is critical: HTMX degrades gracefully when JavaScript is disabled
Real-time features: Built-in WebSocket/SSE support
Simple, predictable behavior: HTMX's single-purpose focus makes it easy to reason about

When to Choose Lightview

Multi-paradigm flexibility: When you want to mix functional programming, JSON-based UI, and hypermedia in one codebase
Safe AI-generated UIs: Using cDOM for secure, sandboxed AI-generated interfaces
Component-based architecture: When you want reusable components without a build step
Client-side reactivity: Applications needing fine-grained reactive updates
Shadow DOM/Web Components: Built-in support for encapsulation
Hybrid approach: Mix hypermedia patterns with reactive programming
Self-Sourced Partials: When you want to use hypermedia patterns but source some content locally from the DOM to reduce network requests or provide offline-ready sections

Performance Considerations

Both frameworks are performant, but optimize different things:

HTMX:

Network-focused optimization (reduce round trips)
Server does the heavy lifting
Minimal client-side processing
History and caching built-in

Lightview:

Fine-grained reactivity (only updates changed nodes)
No virtual DOM diffing overhead
Can reduce network requests with client-side state
Dependency tracking optimizes renders

Developer Experience

Learning Curve

HTMX:

Conceptually simple: HTML + attributes
Extensive documentation and examples
Large community and ecosystem
"Hypermedia Systems" book as comprehensive guide

Lightview:

Multiple mental models (hypermedia + reactivity + functional)
Comprehensive documentation with 40+ components and extensive examples
Smaller community
Requires understanding multiple programming paradigms

Debugging

HTMX:

Browser DevTools work naturally
Excellent logging and events for debugging
Request/response inspection straightforward

Lightview:

Dependency tracking can be harder to debug
Reactive updates may be less obvious
Built-in development mode helps

Ecosystem and Adoption

HTMX:

Mature ecosystem with plugins and extensions
Server-side library support in all major languages
Large and active community
Used in production by many companies
Part of the broader hypermedia movement

Lightview:

Smaller but growing ecosystem
Companion backend framework (Watchlight)
Less third-party integration
Newer to the scene

Size

HTMX

HTMX minified and gzipped is 29KB

Lightview

Lightview can be loaded as three separate files:

// Core: 6KB minimized and gzipped
// Supports: tagged functions, signals, vDOM format
<script src="lightview.js"></script>

// X: 14KB minimized and gzipped
// Adds: hypermedia, html template literal support, oDOM support
<script src="lightview-x.js"></script>

// CDOM: 25KB minimized and gzipped
// Adds: cDOM, JPRX (not required for hypermedia)
<script src="lightview-cdom.js"></script>

The combined size required to emulate much of HTMX's functionality is 20KB, and this gets you lots of other power as well.

Code Comparison: Building the Same Feature

Let's build an active search feature with both frameworks:

HTMX Version

<input type="search" 
       name="q" 
       hx-get="/search"
       hx-trigger="keyup changed delay:300ms"
       hx-target="#results"
       hx-indicator="#spinner">

<img id="spinner" class="htmx-indicator" src="/spinner.gif">

<div id="results"></div>

Lightview Version

<input type="search" 
       id="search-input"
       name="q"
       href="/search"
       oninput="LightviewX.request(this)"
       lv-before="input debounce(300)"
       target="#results">

<div id="results"></div>

How it works:

href="/search": The endpoint to fetch.
oninput="LightviewX.request(this)": Triggers the Lightview hypermedia engine on every keystroke. Only required for input type elements. Click processing is automatic on non-input elements.
lv-before="input debounce(300)": Declaratively debounces the input by 300ms, replacing the need for complex trigger syntax.
target="#results": Directs the HTML or JSON response into the results div.

Integration with Backend Frameworks

HTMX works with any server-side technology that can generate HTML.

Lightview works with any JSON or HTML-generating backend—it doesn't dictate server-side architecture.

Migration Path

From SPA to HTMX

HTMX offers a gradual migration path:

Start with hx-boost on existing forms and links
Incrementally add more sophisticated hypermedia interactions
Replace SPA routes with hypermedia endpoints

From SPA to Lightview

Lightview also offers a gradual path:

Start by turning just a few elments into hypermedia
Incrementally add more sophisticated hypermedia interactions
Evolve functional components to tagged functions
Incorporate names signals and state
Add dynamic AI generation with cDOM/JPRX

Conclusion

Both HTMX and Lightview represent compelling alternatives but serve different needs:

Choose HTMX if you want:

Pure hypermedia-driven architecture
Minimal client-side complexity
Progressive enhancement
Proven, battle-tested solution
Strong community and ecosystem

Choose Lightview if you want:

Multi-paradigm flexibility (functional, JSON, hypermedia)
Safe AI-generated UIs with cDOM/JPRX
Component architecture without build tools
Fine-grained reactivity
Shadow DOM/Web Component support
Freedom to choose your programming style
Self-sourced local partials via CSS selectors

The key difference: HTMX is laser-focused on hypermedia and does it exceptionally well. Lightview gives you hypermedia as one option among several paradigms - it doesn't force you to choose hypermedia for everything.

Neither framework is "better" - they optimize for different priorities. HTMX stays true to the hypermedia vision with laser focus, while Lightview embraces flexibility, letting you use functional programming (like BauJS), JSON representation (like JurisJS), or hypermedia patterns as your use case demands.

Resources

HTMX

Official site: htmx.org
Book: "Hypermedia Systems" at hypermedia.systems
Discord: Active community discussion

Lightview

Official site: lightview.dev
Article on safe AI UI generation: How to Build an AI Generated Calculator Without Custom JavaScript