VanillaJSX.com

Original Article ↗ Hacker News Discussion ↗

A new project, VanillaJSX, shows how JSX can be used to generate real DOM nodes directly, bypassing React’s virtual DOM and heavy runtime abstractions. Commenters weigh the benefits of this minimalist, imperative approach—clearer mental model, tiny bundles, better fit for static sites—against the advantages of virtual DOM and reactive frameworks for large, highly dynamic UIs, such as declarative state management and safer update patterns. The thread situates VanillaJSX alongside alternatives like lit-html, Svelte, Solid, Web Components, and Astro, reflecting a broader push to reduce frontend complexity and get closer to “just the browser” while still retaining good tooling and maintainability.

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.