HN Debrief

You don't need React: creating a minimal UI library in Vanilla JavaScript

  • Programming
  • Web Development
  • Developer Tools
  • Open Source

The post walks through a minimal UI library in vanilla JavaScript that mimics a React-style mental model. The pitch is simple: for many websites, you can get component-like structure and reactive updates without bringing in React or a larger build stack. That landed with people who are tired of React being the default answer for every page with a button. Several said the right baseline for content-heavy sites is still HTML, CSS, and light JavaScript, or newer hybrids like Astro with Preact islands when a few parts truly need client-side complexity.

If you run a mostly content or forms-heavy site, start with server-rendered HTML and add small islands of interactivity instead of defaulting to a full React stack. If you do need rich client-side workflows, evaluate frameworks on the problems they remove for your team, not on ideology or bundle-size slogans.

Discussion mood

Mostly skeptical but sympathetic. People liked the anti-defaulting-to-React message, especially for simple sites, but many thought the article's implementation was too naive and technically sloppy to support its broader claim.

Key insights

  1. 01

    The hard part is dependency tracking

    The demo copies the pleasant `ui = f(state)` surface but skips the machinery that makes that pattern hold up in a browser. Preserving input values, recalculating only what depends on changed state, batching DOM writes, and scheduling reads like `getBoundingClientRect` are the real job. That is why a toy library can look finished long before it survives normal app behavior.

    Do not judge a UI approach by how little code it takes to render a todo app. Stress it with form state, repeated updates, layout-sensitive components, and partial rerenders before treating it as a framework choice.

      Attribution:
    • jakelazaroff #1
    • davexunit #1
    • avsn #1
    • ChiperSoft #1
  2. 02

    Astro plus islands matched the practical middle

    Several people converged on the same architecture for ordinary sites: server-render the page, ship almost no client JavaScript by default, and mount a small interactive component only where needed. Astro with Preact came up repeatedly because it gives teams component ergonomics without turning the whole page into a hydrated app.

    For marketing sites, docs, blogs, and many commerce pages, evaluate island architectures before reaching for a full single-page app. You can keep the developer model familiar while cutting client-side cost dramatically.

      Attribution:
    • afavour #1
    • donatj #1
    • matsemann #1
    • lkbm #1
    • bryanhogan #1
  3. 03

    React persists because organizations optimize for staffing

    The strongest pro-React case was not technical elegance. It was standardization. React reduces bespoke code, matches what hires already know, works well with LLM-assisted coding, and is often the favored path for enterprise SDKs and headless content stacks. Teams accept some runtime overhead to avoid custom patterns and maintenance traps.

    When picking frontend tech, account for labor market and vendor constraints explicitly. If your stack depends on common hiring, off-the-shelf components, or React-only SDKs, that can outweigh small performance wins from going minimal.

      Attribution:
    • pjmlp #1 #2
    • FeloniousHam #1
    • killerstorm #1
    • fidotron #1
  4. 04

    Site versus app is the wrong split

    A more useful framing was not "websites" versus "web applications" but where a product sits on the spectrum from published content to rich local interaction. Plenty of so-called apps still work better as server-rendered Django or Phoenix pages with selective enhancement. The label "app" often gets used to smuggle in a full SPA without proving the need.

    Describe the specific interactions you need instead of declaring your product a web app and inheriting a framework stack. Requirements like offline edits, long-lived local state, or dense client-side editing justify more than branding does.

      Attribution:
    • torginus #1
    • Scarblac #1
    • jakelazaroff #1
    • killerstorm #1
  5. 05

    Network is cheaper than CPU on weak devices

    One of the sharper performance points was that modern frontend pain is often not bandwidth but parse, hydration, and JSON processing cost on low-end phones. A few extra kilobytes are easy to wave away on desktop broadband. They are much less easy to ignore on slow Android hardware, where JavaScript-heavy pages visibly crawl.

    Measure on representative low-end devices, not your laptop. Track scripting and hydration time alongside transfer size before concluding your frontend is fast enough.

      Attribution:
    • afavour #1
    • inigyou #1
    • codazoda #1
    • lelandfe #1

Against the grain

  1. 01

    React overhead is often a solved problem

    A minority view held that this whole debate is stale because modern React workflows already handle static generation well enough, users tolerate the extra payload, and LLMs make routine React work cheap to produce. From that angle, betting on the dominant ecosystem is simply the lower-risk move for most teams.

    If your product already lives inside a React-centric org and performance budgets are being met, the migration cost to a lighter stack may not pay back. Challenge defaults, but quantify the gains before rebuilding around ideology.

      Attribution:
    • godwinson__4-8 #1 #2
  2. 02

    Complex forms and enterprise workflows justify frameworks

    The cleanest rebuttal to the "most apps are just CRUD" line came from people building software with huge accessible forms, offline requirements, and large teams maintaining the code for years. In that world, client-side state, validation, and reusable accessibility libraries are not luxury features. They are core product requirements, and frameworks can raise team productivity more than they hurt runtime performance.

    If your app depends on offline work, dense form flows, or strong accessibility support, cost out the engineering effort to rebuild those primitives yourself. A heavier framework can be the cheaper system overall.

      Attribution:
    • mexicocitinluez #1 #2
    • assimpleaspossi #1
    • FeloniousHam #1
    • Jaygles #1

In plain english

Astro ↩
A web framework focused on server-rendered pages with optional client-side interactive components called islands.
Batching ↩
Grouping multiple state or DOM changes together so the browser does less repeated work.
CRUD ↩
Create, read, update, delete, the four basic operations most data-entry applications perform.
Django ↩
A Python web framework known for server-rendered applications and strong built-in conventions.
DOM ↩
Document Object Model, the browser's tree representation of a web page that JavaScript can read and modify.
getBoundingClientRect ↩
A browser API that returns an element's size and position on the page, often triggering layout work if used carelessly.
Hook ↩
In React and similar libraries, a function-based API for using state, effects, and other framework features inside components.
Hydration ↩
The process where browser JavaScript attaches behavior to server-rendered HTML so it becomes interactive.
Immediate mode ↩
A UI rendering style where the interface is described anew each frame or update rather than being stored as a long-lived widget tree.
LLM ↩
Large language model, a machine learning model trained on large amounts of text to generate and analyze language.
Phoenix ↩
An Elixir web framework often used for server-rendered applications and real-time features.
Preact ↩
A small React-compatible UI library designed to deliver similar component patterns with less code and overhead.
React ↩
A popular JavaScript library for building user interfaces out of reusable components and state-driven rendering.
Scheduling ↩
Controlling when UI updates run so rendering and interaction stay smooth and predictable.
SPA ↩
Single-page application, a web app that updates content dynamically in the browser instead of loading a new page for each action.
useState ↩
A React hook used to store component state and trigger rerenders when that state changes.
Vanilla JavaScript ↩
Plain JavaScript without using a framework or library abstraction layer.

Reference links

Minimal and alternative UI libraries

  • VanJS
    Shared as a minimal reactive library that already explores the same small-library space.
  • TinyJS
    Offered as another tiny JavaScript UI library built around the same idea.
  • GeaJS
    Posted as an existing lightweight alternative instead of rolling a new one.
  • Mithril
    Referenced as a better approach to JavaScript templating and small-framework design.

Performance and page weight references

Browser platform and standards

  • Declarative partial updates
    Pointed to as an example of browser-native partial page update work that could reduce the need for SPA patterns.
  • MACH architecture
    Referenced to explain why enterprise ecosystems often steer teams toward React-based stacks.

Frameworks, starters, and examples

Immediate mode and architecture examples