VanJS – A no-JSX framework based on vanilla JavaScript

Original Article ↗ Hacker News Discussion ↗

A new JavaScript UI library, VanJS, promises reactive interfaces in under 1 KB using plain functions instead of JSX or a build step, prompting comparisons to React, Preact, Solid, Mithril and other “minimal” frameworks. Commenters debate whether extreme bundle-size optimization still matters given modern networks, but many argue that less tooling, faster execution on low-end devices, and simpler mental models are real advantages. The thread surfaces broader fatigue with constantly reinvented front-end stacks, alongside genuine interest in signal-based reactivity, interoperability, and approaches that move away from virtual DOM and heavy build pipelines.

Overall Reception & Purpose

  • Many see VanJS as another entry in a long line of minimalist “reactive vanilla JS” libraries, akin to Xeact, Hyperapp, Arrow, Mithril, etc.
  • Some are cynical about yet another framework, but others argue experimentation is valuable and how today’s major frameworks originated.
  • Several like that it’s small, conceptually simple, and easy to fork or extend.

Size, Performance, and Network Costs

  • Strong focus on the sub‑1KB size; some argue that framework size is negligible compared to images/fonts and will be cached anyway.
  • Others counter that JS size still matters, especially for low-end devices and limited data plans, and that execution cost, not just bytes, impacts UX.
  • VanJS’s own benchmarks are cited to claim it outperforms React by updating locally without a virtual DOM.
  • A subthread notes that adding even tiny conveniences (e.g., SVG/MathML constants) is deliberately avoided to keep bytes down; some praise this, others see it as over-optimization.

No JSX, Function-Based View Syntax

  • A major topic is the lack of JSX:
    • Fans of JSX see its absence as a drawback; they prefer HTML-like, nested tags for readability and structural clarity.
    • Opponents consider JSX a historical crutch, a syntactic misfit requiring a build step, and argue plain JS function calls are cleaner and avoid extra tooling.
  • Some note that React can be used without JSX and that VanJS’s syntax ends up similar to non-JSX React.
  • There are extended debates comparing readability of nested function calls vs XML/HTML trees, with no clear consensus.

Reactivity, State, and Lifecycle

  • VanJS uses simple “state.val” objects (signal-like). Some find this intuitive and concise; others find the “val should be immutable, but is set via a setter” wording confusing at first glance.
  • Questions are raised about missing features: lifecycle hooks (onMount/onCleanup), stores, and higher-level control constructs like For/Index/Show.
  • Async data fetching is discussed; VanJS supports an Await-style abstraction and state updates, but idiomatic patterns are not immediately obvious from the homepage examples.

Broader Reflections & Alternatives

  • Some prefer staying with existing tools (React, Preact, Solid, Svelte) or moving to htmx/LiveView and non-JS languages via WASM or compile-to-JS.
  • A recurring theme is the “circle of frameworks”: minimal tools accrete features, become complex, and inspire a new wave of tiny replacements like VanJS.