VanillaJSX.com

Purpose and trade-offs of the Virtual DOM

• Many comments stress that vDOM’s main value is declarative UI and state consistency, not raw speed. It lets you treat UI as view = f(state) and avoid manual DOM syncing bugs.
• Several note that direct DOM access is synchronous and can cause layout thrash and jank; vDOM plus batching can mitigate this, especially for complex apps and older browsers.
• Others argue carefully written vanilla DOM code is always faster and that vDOM is “pure overhead” once you can drop legacy browsers; they see vDOM mainly as a productivity / safety tool.
• Some say vDOM encourages the illusion you can “re-render everything all the time,” which backfires at scale, forcing developers to learn memoization, fine-grained updates, etc.

Alternatives: Lit, Svelte, Solid, Web Components

• Lit-html: uses template literals and static <template> structures, updating only dynamic parts without a traditional vDOM. High performance, but templates can’t arbitrarily change shape; more burden on the developer when structure is dynamic.
• Svelte and Solid: avoid a generic vDOM by compiling or using fine-grained reactivity, updating DOM directly at a granular level. Seen as giving many vDOM benefits with less overhead.
• Some note that even “no-vDOM” systems still maintain parallel structures or dependency graphs; they just don’t call them vDOM.

VanillaJSX.com and imlib

• VanillaJSX makes JSX expressions produce real DOM nodes (in the browser) and strings (in Node/SSG) with a tiny runtime.
• Supporters like the simplicity, tiny bundle, SEO-friendliness, and closeness to the platform; it’s basically “document.createElement but nicer,” with JSX-driven editor tooling.
• Critics say returning real DOM blunts JSX’s main advantage (immediate-mode declarative updates) and forces imperative event wiring and state handling; they doubt it scales to large, reactive apps without a proper reactivity layer.
• The author positions it as an SSG + light client-side enhancement tool, not a full React replacement, and cites moderately complex sites built this way.

JSX vs strings, hyperscript, and other DSLs

• Many value JSX for:
  • IDE support (types, autocomplete, go-to-definition).
  • Clear visual mapping to HTML/DevTools.
  • Unified syntax for primitives and custom components.
• Others prefer:
  • Hyperscript-style h("div", …) APIs or Clojure-like data structures for trees.
  • Tagged template literals (e.g., lit-html) that avoid a compile step.
• Some find JSX visually noisy or cognitively hard; others find function-call trees unreadable and prefer HTML-like syntax.

Broader sentiment about frameworks

• Strong undercurrent of “framework fatigue”: claims that modern stacks (especially React) are over-complex, bloated, and often unnecessary for simple or mostly-static sites.
• Counterpoint: for truly complex, state-heavy UIs (BI tools, email clients, etc.), React/vDOM-style architectures are reported to make state management and team development much more tractable.