Plain Vanilla Web

Original Article ↗ Hacker News Discussion ↗

Advocates of “plain vanilla” web development argue that modern HTML, CSS and JavaScript are sufficient for many sites and smaller apps, avoiding the complexity, tooling overhead and long‑term fragility of big frameworks like React. Others counter that frameworks still offer major advantages for large, stateful applications and teams, even if they’re often misapplied to simple CRUD or content sites. Web Components emerge as a contentious middle ground: useful for encapsulated, framework‑agnostic UI pieces, but criticized for awkward data passing, Shadow DOM quirks and the need for extra libraries to handle templating and state.

Appeal of “Plain Vanilla Web”

  • Many appreciate the guide as a practical reminder that modern HTML/CSS/JS are powerful enough for many sites without frameworks or build tools.
  • Vanilla approaches are praised for:
    • No build steps, smaller dependency surface, fewer CVEs.
    • Easier debugging (cleaner stacks, fewer layers).
    • Long‑term maintainability: a simple HTML/CSS/JS site still works years later, whereas framework stacks often rot.

Web Components: Promise vs. Reality

  • Positive view:
    • Custom elements give a standard way to create reusable, encapsulated UI primitives that work in any framework or no framework.
    • Good fit for “design systems” and for distributing components (microfrontends, cross‑framework widgets).
  • Criticisms:
    • Attribute model (strings only) makes passing complex data awkward; you end up juggling attributes vs. properties vs. methods.
    • Shadow DOM introduces styling and tooling friction, especially for app‑internal components; many prefer custom elements without shadow DOM.
    • A lot of “boilerplate” and lifecycle gotchas (e.g., connectedCallback firing on each re‑attach).
    • In practice people often add Lit or similar; at that point critics ask why not use a full framework instead.

State Management & Reactivity

  • Several argue state management is the central hard problem frameworks solve: keeping UI consistent with changing data without manual DOM diffing and event cleanup.
  • Others counter that:
    • Simple global state + event handlers (classic MVC) is enough for many apps.
    • You can use the same state libraries (signals, context patterns, Redux‑like stores) with vanilla or web components.
  • There’s recognition that once state and composition get complex, you are de‑facto building your own mini‑framework anyway.

Frameworks: Tradeoffs, Hype, and Scope

  • Pro‑framework points:
    • Huge productivity and shared conventions for large teams and complex SPAs.
    • Good ecosystems (routing, data fetching, testing, SSR) and hiring pipeline.
    • React itself isn’t that heavy at runtime; bloat often comes from surrounding tooling.
  • Anti‑framework points:
    • Overkill for simple CRUD/sites; often slower and more fragile than straightforward server‑rendered pages with “sprinkles” of JS or HTMX‑style interaction.
    • Churn (React patterns, build tools, meta‑frameworks) leads to expensive upgrades and frozen legacy UIs.
    • Many SPAs regress UX (spinners, broken back button, sluggish navigation) versus well‑cached MPAs.

Sites vs. Apps, and Non‑Web Alternatives

  • Commenters stress distinguishing:
    • Content sites (blogs, news, docs) – often best with SSR and minimal JS.
    • Rich web apps (complex dashboards, collaborative tools, games) – more likely to benefit from a framework or a well‑designed component + state layer.
  • In B2B and internal tooling, a surprising amount of real work still runs on Excel/CSV, email, and file exchange; sometimes that’s simpler and more appropriate than building full web UIs.

Progressive Enhancement, Robustness & UX

  • Some lament that even “vanilla” demos often fail completely without JS (e.g., web‑component demos that don’t degrade to links or plain code).
  • Others call for a return to unobtrusive JS and graceful degradation: HTML forms, server‑side rendering, and light JS on top, reserving SPA‑style complexity only where it’s clearly justified.