|
Core Philosophy
|
HTML-first. Enhanced with <template> and EHTML extensions. Browser remains the framework. |
JavaScript-first. UI is fully constructed from JS components. |
Server-first. HTML is generated on server using templating engines. |
|
Templating Model
|
Native <template> + EHTML features like mapToTemplate and releaseTemplate. No templating engine needed. |
JSX, directives, component templates compiled into JS bundles. |
Requires templating engines (EJS, Rails ERB, Blade, Razor, etc.). |
|
Data Binding
|
Declarative binding via data-* attributes. Data & view always decoupled. Structured mapping built-in. |
Components tightly coupled with their data sources. Harder to trace. |
Data inserted during server render; templates don’t know where data came from. |
|
Nested Structures / Forms
|
Built-in nested form support with automatic JSON serialization. |
Requires custom form logic or libraries. |
Server parses nested forms manually; limited dynamic interactions. |
|
Dynamic Updates
|
Uses HTML <template> and dynamic mapping utilities. Can update just the part you need. |
Requires re-rendering component hierarchies, reconcilers, or signals. |
Typically needs full page reload unless enhanced by TurboLinks/Turbo Frames. |
|
Routing Model
|
Simple: HTML files + JSON endpoints. No client router required. |
Client-side routing libraries required. |
Backend-driven routing; each route returns full HTML. |
|
Caching Strategy
|
Strong. Data and templates are separated → headers/menus cached, content updated independently. Perfect for CDN/edge delivery. |
Weak. HTML is mostly empty, everything loads via JS, so CDN cannot cache rendered views. |
Limited. HTML and data tightly coupled → hard to cache partials; whole pages cached or nothing. |
|
Performance Profile
|
Very light. No framework JS. Fastest first paint. Only dynamic data loaded when needed. |
Slow first load due to large JS bundles + hydration. High CPU overhead on client. |
Good first paint but waits for server to collect data. Entire page blocked until render finishes. |
|
Build Step
|
None. Pure browser execution with optional ES modules/import maps. |
Always requires bundlers/transpilers (Webpack, Vite, SWC). |
No front-end build step, but requires server template compilation. |
|
Maintenance Complexity
|
Extremely low. No framework churn. HTML remains stable for decades. |
High. Frequent framework updates, breaking changes, build-tool drift. |
Medium. Template engines are stable, but backend coupling increases maintenance. |
|
Data Flow Transparency
|
Fully transparent: HTML declares data sources; logic minimal; easy debugging. |
Hard to trace. Logic split between components, hooks, effects, stores. |
Hard to trace: data lives in backend controllers/services, not visible in templates. |
|
Interactivity Level
|
Excellent for most apps. Template mapping easily handles dynamic lists and partial updates. |
Very high, especially for complex, real-time or granular UI interactions. |
Limited without additional JS; mostly full reloads. |
|
WebSocket / Live Data
|
Simple. EHTML patterns allow multi-template updates with minimal JS. |
Requires custom WebSocket clients + state management. |
Requires custom JS; server templates don’t help with real-time updates. |
|
SEO
|
Excellent. Full HTML loads first, dynamic content fills in later. |
Poor by default. HTML is mostly JS bootstrapping → requires SSR for good SEO. |
Excellent. Search engines receive full HTML immediately. |
|
Progressive Enhancement
|
Native. Without JS, most of the page still works. |
Weak. CSR often fails entirely without JS. |
Very strong. HTML-first. |
|
Component Reuse
|
Use <template> as components—simple, portable, no toolchain required. |
Components require framework syntax + build chain. |
Limited. Templates reusable server-side but not client-side. |
|
Developer Experience
|
Very high: simple HTML, declarative mapping, instant refresh, no virtual DOM. |
Heavy: component trees, dependency management, complex build pipelines. |
Moderate: templating straightforward, but tied deeply to backend stack. |
|
First Load Experience
|
Fastest: minimal JS, static HTML served immediately. |
Slow: app waits for JS bundle download + execution. |
Can be slow: server waits for all data before sending HTML → blank screen until finished. |
|
Resilience / Failure Modes
|
Very resilient: if dynamic data fails, static HTML still loads. |
Fragile: if JS fails, the whole page often breaks. |
Resilient: server returns HTML even if some data partials fail. |
|
Technology Lock-In
|
Low. EHTML sugar is HTML-based and easy to migrate or remove. |
High. App structure locked into framework architecture. |
Medium. Migration depends on backend language and templating engine. |
|
Backend Dependency
|
None. Backend just provides JSON + static HTML files. |
Tight. Must integrate frontend build pipeline with backend. |
Very tight. UI tied to backend language and templating engine. |
|
Debugging Simplicity
|
Extremely easy: inspect HTML + data attributes; no hidden lifecycle magic. |
Hard: data flows through multiple layers (hooks, effects, stores, frameworks). |
Moderate: server logs + template debugging required. |