Plain Vanilla Web

Original Article ↗ Hacker News Discussion ↗

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.