Show HN: Aberdeen – An elegant approach to reactive UIs

Original Article ↗ Hacker News Discussion ↗

Intended use & scope

  • Author positions Aberdeen as suitable for full applications, not just widgets.
  • Some commenters want clearer “real app” examples; initial tic‑tac‑toe example felt too complex as an elevator pitch, leading to requests for simpler counters and TodoMVC‑style demos.
  • Questions raised about how to structure reusable “widgets” and separate model logic from view logic, especially when all behavior appears inside view functions.

Programming model & reactivity

  • Core idea: proxied data plus automatically rerun functions (“immediate mode” rendering).
  • Functions passed to $() are tracked: reads of proxied data create dependencies; when data changes, corresponding DOM changes are reverted and that function reruns.
  • Proxies effectively behave like nested signals; updates can affect fractions of components without a virtual DOM.
  • Some discussion of the “diamond problem” and batching: Aberdeen batches updates and re-runs scopes in creation order.

Syntax: JS-only vs JSX/HTML

  • Aberdeen intentionally avoids JSX and HTML templates; UIs are expressed purely in JS/TS via a hyperscript‑like $ function and string shortcuts ('div.class:text').
  • Proponents like having full control logic (if/for/switch) in plain JS without ternaries and .map() embedded in JSX.
  • Critics argue HTML/JSX is more natural, easier to read, and leverages existing HTML knowledge; concern about “walls of JS” and harder DOM tree navigation.
  • Multiple suggestions to support JSX or a templating variant; author pushes back, citing no‑build and JS‑only goals.

Comparisons to existing frameworks

  • Repeated comparisons to Vue (early proxy‑based reactivity), Mithril (hyperscript + VDOM), SolidJS (signals, fine‑grained updates, stores), Valtio (proxy state), Flutter (functions emitting UI), Svelte (compile‑time reactivity).
  • Some see Aberdeen as conceptually very close to Vue/Solid with different ergonomics and no compile step.
  • Mithril and Solid proponents note similar capabilities (fine‑grained updates, deep stores) and question what is fundamentally new beyond syntax and build‑less setup.

Performance, ergonomics & criticism

  • Author reports proxy overhead is negligible in practice; js‑framework‑benchmark PR suggests React‑like runtime with better TTFP/size, though benchmark is not ideal for Aberdeen’s sorted lists.
  • Some praise simplicity and elegance; others dispute “simple”, arguing that magic proxies and automatic reruns hide real complexity and resemble other signal‑based systems.
  • Concerns about console‑log debugging of proxies, TypeScript strictness, lifecycle hooks (only clean + getParentElement()), SEO with no HTML/server‑side, and lack of ecosystem/community.
  • Thread contains both enthusiasm (especially for non‑JSX, hyperscript style) and skepticism about long‑term adoption and marginal differentiation from existing reactive libraries.