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. https://github.com/grucloud/bau https://jurisjs.com 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. 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 Declarative syntax: Uses HTML-embedded attributes rather than imperative scripting Declarative syntax Hypermedia responses: The server responds with HTML, not JSON Hypermedia responses 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: HTTP Method Support Delete Contact Delete Contact Flexible Targeting: The hx-target attribute specifies where server responses should be inserted, using CSS selectors: Flexible Targeting hx-target Event Triggers: Custom triggers control when requests fire: Event Triggers Swap Strategies: Multiple options for how content replaces existing DOM: Swap Strategies innerHTML (default) outerHTML beforebegin, afterbegin, beforeend, afterend delete, none innerHTML (default) innerHTML outerHTML outerHTML beforebegin, afterbegin, beforeend, afterend beforebegin afterbegin beforeend afterend delete, none 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. CSS Transitions and Animations htmx-swapping htmx-settling htmx-added htmx-request swap:1s settle:1s Progressive Enhancement: HTMX's hx-boost can enhance existing links and forms: Progressive Enhancement hx-boost WebSockets & SSE: Native support for real-time updates: WebSockets & SSE 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. website 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: only 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. Hypermedia (HTMX-style): Use src and href for server-driven content and page navigation. Hypermedia (HTMX-style) src href Functional (BauJS-style): Use Javascript template tag functions for complex, imperative logic. Functional (BauJS-style) Data-Driven (JurisJS-style): Define UIs as pure JSON (vDOM/oDOM) for config-driven interfaces. Data-Driven (JurisJS-style) AI-Safe (cDOM): Use sandboxed JSON structures with an executable expression language (JPRX) for safe, AI-generated user interfaces. AI-Safe (cDOM) 1. Hypermedia & Interaction Lightview's hypermedia system is built on standard HTML attributes (src, href) extended with powerful capabilities. src href Unified Attributes: 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., ). src: Fetches content to populate an element. Can be a URL (for server-side partials) or a CSS selector (for local partials). src href: Triggers navigation or content loading on user interaction (e.g., ). href Targeting & Location: Lightview offers sophisticated control over where content is inserted using the target attribute or location setting. Targeting & Location target location 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. Standard Locations: innerhtml, outerhtml, beforebegin, afterbegin, beforeend, afterend. 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. Shadow DOM location="shadow" :shadow target="#component:shadow" Advanced Requests (data-method & data-body): Customize HTTP actions directly in HTML: Advanced Requests ( data-method data-body Delete

Save Delete

Save 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. Self-Sourced Partials (CSS Selectors as Source) src This enables "Self-Sourced Partials" where content can be pulled from a , a hidden , 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.

Tab 1 This content was sourced from a local template tag!

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. Automatic Hash Scrolling src href /docs/api.html#signals 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). Smart Offsets: The scroll position automatically accounts for a fixed navigation bar if defined (via --site-nav-height). Smart Offsets --site-nav-height Shadow DOM Support: Scrolling also works for content loaded into a Shadow Root. Shadow DOM Support Partial Loading: Works for both full navigation (href) and partial content updates (src). Partial Loading href 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. Declarative Event Gating ( lv-before 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. Modifiers: Built-in support for throttle(ms) and debounce(ms). Modifiers throttle(ms) debounce(ms) Pipelines: Chain multiple gates (e.g., lv-before="click throttle(500) confirm('Are you sure?')" ). Pipelines 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. Custom Gates validateUser() 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. Automatic Template Resolution: ${...} tags in HTML are automatically updated when state changes. Automatic Template Resolution ${...} Named Registration: Signals and states can be registered by name for easy template binding. Named Registration JSON Schema Control: Enforce data integrity on reactive state using standard JSON Schema. JSON Schema Control For a detailed technical comparison of Lightview's reactive state vs. HTMX's server-driven approach, see the State Management section. State Management 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). Data-as-UI Safe AI-Generation 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. Multiple JSON Formats vDOM: Standard Virtual DOM structure. oDOM: "Object DOM" shorthand for concise config-based UIs. vDOM: Standard Virtual DOM structure. vDOM oDOM: "Object DOM" shorthand for concise config-based UIs. oDOM /* 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": "+" } } ] } } /* 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. Safe AI Generation with cDOM cDOM (Clean/Computed DOM) without JPRX (JSON Path Reactive eXpressions) 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. Security: No eval or arbitrary script execution. Security eval 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. Logic Use Case: Ideal for "GenUI" applications where an LLM generates the interface on the fly. Use Case 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: 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 Custom hx-* attributes for all functionality hx-* Extensive attribute vocabulary (hx-get, hx-post, hx-target, hx-trigger, etc.) hx-get hx-post hx-target hx-trigger Consistent prefix makes HTMX features immediately recognizable Steeper learning curve due to attribute variety Lightview: 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 Uses standard HTML attributes (src, href) where possible src href 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: HTMX Lightview uses standard data- attributes for configuration: Lightview data- Save Save Lightview's data-body is highly flexible: Lightview's data-body 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. CSS Selector: Automatically serializes the target (e.g., #myForm as FormData, or an input's value). CSS Selector #myForm FormData value JSON: Use json:{"id": 1} for literal JSON payloads. JSON json:{"id": 1} Javascript: Use javascript:state.get('user') to pull data directly from reactive state. Javascript javascript:state.get('user') Text: Use text:Hello for plain text payloads. Text text:Hello Triggering Events HTMX has sophisticated trigger syntax: HTMX Lightview has a similar approach using lv-before gating: Lightview lv-before Targeting and Content Positioning Both frameworks provide flexible control over where content is inserted: HTMX uses hx-target and hx-swap attributes: HTMX hx-target hx-swap Load More Load More Lightview uses target with optional location suffix or separate location attribute: Lightview target location Load More

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. Key difference shadow Content Sourcing (Server vs. Local) HTMX: HTMX Designed for server-driven hypermedia (HDA) Sources must be URLs that return hypermedia (HTML) responses Requires a network request for every partial update Designed for server-driven hypermedia (HDA) Sources must be URLs that return hypermedia (HTML) responses Requires a network request for every partial update Lightview: Lightview Multi-source flexibility Sources can be URLs OR CSS selectors Enables "Self-Sourced Partials" where content is pulled from local tags or other DOM elements Allows bundling common UI fragments to reduce initial network waterfall Multi-source flexibility Sources can be URLs OR CSS selectors Enables "Self-Sourced Partials" where content is pulled from local 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. HTMX 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. Lightview 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. Server Session: State is maintained in the backend database or session. Server Session Hidden Form Fields: passing state back and forth in requests. Hidden Form Fields DOM Attributes: Storing simple state in data-* attributes. DOM Attributes data-* Alpine.js Integration: For complex client-side logic, HTMX developers often reach for Alpine.js or similar lightweight libraries. Alpine.js Integration 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. Automatic Template Resolution src href ${...} Named Registration: Signals and states can be registered by name so they are available for template resolution globally: Named Registration // 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'); // 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'); Welcome, ${state.get('user').name} Welcome, ${state.get('user').name} JSON Schema Validation: Lightview states can be optionally enforced by JSON schemas, providing data integrity for complex objects: JSON Schema Validation const user = Lightview.state({ name: 'Alice', age: 30 }, 'user', { schema: { type: 'object', properties: { name: { type: 'string' }, age: { type: 'number' } }, required: ['name', 'age'] } }); const user = Lightview.state({ name: 'Alice', age: 30 }, 'user', { schema: { type: 'object', properties: { name: { type: 'string' }, age: { type: 'number' } }, required: ['name', 'age'] } }); Reactive Primitives: 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. signal(value): For primitive values. signal(value) state(object): For deep observation of objects and arrays. state(object) effect(fn): To run side effects when dependencies change. effect(fn) 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: HTMX Lightview doesn't have built-in WebSocket/SSE support (as of the current version), though it can be added through standard JavaScript. Lightview Security HTMX relies on standard web security practices: HTMX Same-origin policy CSRF token support via hx-headers Content Security Policy compatibility Same-origin policy CSRF token support via hx-headers hx-headers Content Security Policy compatibility Lightview includes security by default: Lightview Same-domain policy enforced automatically Dangerous protocol blocking (javascript:, data:) Customizable validation hooks Same-domain policy enforced automatically Dangerous protocol blocking (javascript:, data:) javascript: data: Customizable validation hooks Progressive Enhancement HTMX excels at progressive enhancement: HTMX Link Link 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. Lightview href src hx-boost Component Architecture HTMX doesn't have a component model—it enhances standard HTML. HTMX Lightview includes: Lightview Single-file components Template components Import/export of variables between components Sandboxed remote components 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. 50 built-in components Loading Card Chart Drawer 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 Adding interactivity to server-rendered apps: HTMX excels at incrementally enhancing traditional web applications Adding interactivity to server-rendered apps Team familiarity with server-side rendering: If your team is comfortable with Rails, Django, Laravel, etc. Team familiarity with server-side rendering Progressive enhancement is critical: HTMX degrades gracefully when JavaScript is disabled Progressive enhancement is critical Real-time features: Built-in WebSocket/SSE support Real-time features Simple, predictable behavior: HTMX's single-purpose focus makes it easy to reason about Simple, predictable behavior 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 Multi-paradigm flexibility: When you want to mix functional programming, JSON-based UI, and hypermedia in one codebase Multi-paradigm flexibility Safe AI-generated UIs: Using cDOM for secure, sandboxed AI-generated interfaces Safe AI-generated UIs Component-based architecture: When you want reusable components without a build step Component-based architecture Client-side reactivity: Applications needing fine-grained reactive updates Client-side reactivity Shadow DOM/Web Components: Built-in support for encapsulation Shadow DOM/Web Components Hybrid approach: Mix hypermedia patterns with reactive programming Hybrid approach 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 Self-Sourced Partials Performance Considerations Both frameworks are performant, but optimize different things: HTMX: HTMX Network-focused optimization (reduce round trips) Server does the heavy lifting Minimal client-side processing History and caching built-in Network-focused optimization (reduce round trips) Server does the heavy lifting Minimal client-side processing History and caching built-in Lightview: 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 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: HTMX Conceptually simple: HTML + attributes Extensive documentation and examples Large community and ecosystem "Hypermedia Systems" book as comprehensive guide Conceptually simple: HTML + attributes Extensive documentation and examples Large community and ecosystem "Hypermedia Systems" book as comprehensive guide Lightview: Lightview Multiple mental models (hypermedia + reactivity + functional) Comprehensive documentation with 40+ components and extensive examples Smaller community Requires understanding multiple programming paradigms Multiple mental models (hypermedia + reactivity + functional) Comprehensive documentation with 40+ components and extensive examples Smaller community Requires understanding multiple programming paradigms Debugging HTMX: HTMX Browser DevTools work naturally Excellent logging and events for debugging Request/response inspection straightforward Browser DevTools work naturally Excellent logging and events for debugging Request/response inspection straightforward Lightview: Lightview Dependency tracking can be harder to debug Reactive updates may be less obvious Built-in development mode helps Dependency tracking can be harder to debug Reactive updates may be less obvious Built-in development mode helps Ecosystem and Adoption HTMX: 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 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: Lightview Smaller but growing ecosystem Companion backend framework (Watchlight) Less third-party integration Newer to the scene 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

// X: 14KB minimized and gzipped // Adds: hypermedia, html template literal support, oDOM support

// CDOM: 25KB minimized and gzipped // Adds: cDOM, JPRX (not required for hypermedia) // Core: 6KB minimized and gzipped // Supports: tagged functions, signals, vDOM format

// X: 14KB minimized and gzipped // Adds: hypermedia, html template literal support, oDOM support

// CDOM: 25KB minimized and gzipped // Adds: cDOM, JPRX (not required for hypermedia) 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

Lightview Version

How it works: 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. href="/search": The endpoint to fetch. href="/search" 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. oninput="LightviewX.request(this)" lv-before="input debounce(300)": Declaratively debounces the input by 300ms, replacing the need for complex trigger syntax. lv-before="input debounce(300)" target="#results": Directs the HTML or JSON response into the results div. target="#results" Integration with Backend Frameworks HTMX works with any server-side technology that can generate HTML. HTMX Lightview works with any JSON or HTML-generating backend—it doesn't dictate server-side architecture. Lightview 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 Start with hx-boost on existing forms and links hx-boost 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 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: Choose HTMX if you want Pure hypermedia-driven architecture Minimal client-side complexity Progressive enhancement Proven, battle-tested solution Strong community and ecosystem Pure hypermedia-driven architecture Minimal client-side complexity Progressive enhancement Proven, battle-tested solution Strong community and ecosystem Choose Lightview if you want: 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 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. one option 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 Official site: htmx.org htmx.org Book: "Hypermedia Systems" at hypermedia.systems 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 Official site: lightview.dev lightview.dev Article on safe AI UI generation: How to Build an AI Generated Calculator Without Custom JavaScript How to Build an AI Generated Calculator Without Custom JavaScript