JavaScript Views, the Hard Way – A Pattern for Writing UI

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.