JavaScript Views, the Hard Way – A Pattern for Writing UI
A GitHub repo proposing a “views the hard way” pattern for building JavaScript UIs without frameworks has reignited debate over whether convention‑based, vanilla DOM code can stay maintainable as apps and teams grow. Commenters contrast the simplicity, debuggability and performance of hand‑rolled views with the predictability and state management of tools like React, Svelte, Web Components and lit-html, and raise concerns about XSS, redundant UI updates, and team discipline. Many conclude that while minimal abstractions work well for small or backend‑driven apps, reactive libraries still pay for themselves in larger, highly interactive frontends.
Conventions vs enforced structure
- The proposed pattern is praised for simplicity and debuggability but questioned on maintainability in large teams.
- Critics note it relies purely on convention, so nothing prevents divergence; class-based or framework-based APIs (e.g., UIKit-style) enforce structure and predictability.
- Others counter that all codebases ultimately depend on conventions; making developers consciously own those conventions can improve understanding, at the cost of discipline.
Manual DOM, micro-frameworks, and templating
- Several commenters share similar “views the hard way”: small helpers, template literals, or React.createElement-style helpers that build DOM directly.
- Benefits cited: performance, easy debugging, no build step, minimal abstractions, and “learning the platform.”
- Downsides: nested templates become hard to compose; full re-renders blow away focus and cursors; managing granular updates and selectors gets fiddly.
State management and DOM-as-source-of-truth
- One camp treats the DOM (textContent/value/checked) as the canonical state, using getters/setters on Web Components and avoiding separate JS state variables.
- Supporters say this avoids divergence between JS state and UI and keeps code concise.
- Critics argue it fails to scale: complex UIs with shared data, lists, and redundant views need separation of data and presentation; using DOM as state runs into issues with non-text state, browser extensions mutating DOM, and coordination across components.
- Others advocate a single centralized state object plus clear architectural patterns instead of scattering state across components.
Security and templating/XSS
- String-based HTML building with template literals is repeatedly called “begging for injection attacks.”
- Some rely on server-side sanitization; others argue this is unsafe or context-insensitive when the client generates HTML from JSON.
- There’s detailed debate distinguishing sanitizing (filtering) from escaping/encoding, and emphasizing context-aware escaping at render time or building DOM trees instead of raw HTML strings.
Reactive frameworks vs “vanilla”
- Many argue React-style reactivity is absolutely worth the complexity once UIs and dependency graphs grow, especially in teams.
- Others say most apps are small enough that reactive frameworks are overkill, and that the industry over-tilted to client-side rendering.
- There’s nostalgia for Backbone-like patterns and interest in modern lightweight tools (lit-html, signals, small micro-frameworks) that give some reactivity without full frameworks.
Web Components and ecosystem culture
- Web Components are proposed as a natural fit; some note the original repo predates broad support, but examples already use them.
- Broader complaints surface that frontend lacks the kind of “batteries-included” conventions backend ecosystems (e.g., PHP frameworks) provide, leading to endless reinvention and fractured patterns.