HTML First

Original Article ↗ Hacker News Discussion ↗

A manifesto advocating “HTML first” web development—favoring semantic HTML, minimal JavaScript, and avoiding heavy build tooling—has reignited long‑running tensions between simplicity and modern frontend frameworks like React. Supporters argue that leaning on native browser features, attributes, and server‑rendered HTML makes sites more accessible, maintainable, and approachable for newcomers, while critics warn that inline event handlers, DSLs like hyperscript, and the lack of clear patterns for state and reuse don’t scale to complex applications or meet contemporary security and accessibility expectations. Many see value in the principles for small to medium, content‑heavy sites, but doubt they can replace component‑based frameworks and build pipelines for large, highly interactive web apps.

Overall reaction to “HTML First”

  • Many like the push toward simpler, HTML-centric development, especially for small/medium sites and server‑rendered apps.
  • Others see it as romanticizing early‑2000s practices and ignoring why frameworks, build tools, and separation of concerns became common.

HTML vs Frameworks (React, Vue, etc.)

  • Pro‑HTML‑first:
    • Most web UIs are forms and basic interactivity; server rendering + “sprinkles” of JS (htmx, Alpine, etc.) often suffice.
    • Frameworks impose heavy complexity (state management, routing, build chains) and can add ~50% effort to projects that don’t need SPA behavior.
    • Good for learnability and “View Source” as a teaching and debugging tool.
  • Skeptical:
    • For larger, stateful apps (dashboards, booking engines, rich tools), frameworks help manage complexity, reuse, and team workflows.
    • Without them, teams tend to reinvent ad‑hoc mini‑frameworks and still fight browser quirks.
    • Many devs value using one powerful stack everywhere instead of splitting mental models.

Inline attributes, locality, and separation of concerns

  • Supporters of inline onclick/utility classes argue:
    • “Locality of behavior” (HTML, behavior, and styling together) makes components easier to understand in one place.
  • Critics argue:
    • This re‑introduces the very spaghetti that CSS/JS separation solved; hard to refactor and debug at scale.
    • Inline JS breaks or weakens CSP, increases XSS exposure, and complicates security reviews.
    • Accessibility suffers (e.g., clickable <div> instead of <button>).

CSS, Tailwind, and class design

  • Tailwind praised for:
    • Avoiding unmaintainable semantic CSS files by composing small utility classes.
    • Working well at component scope and encouraging consistent design tokens.
  • Criticism:
    • It effectively turns class into a second style attribute; HTML gets cluttered.
    • Requires a build step (purging/generating CSS), conflicting with “no build” ideals.
    • Some measurements suggest Tailwind bundles can be larger than well‑designed semantic CSS.

HTMX, hyperscript, and “HTML-based” libraries

  • HTMX and Alpine are cited as good “HTML‑first” ways to add interactivity without full SPAs.
  • Concerns:
    • Returning HTML from APIs can tangle front‑ and back‑end concerns.
    • hyperscript is explicitly a custom DSL, contradicting the article’s own warning against custom syntaxes.
    • Some see HTMX as fine for internal tools and modest apps, not for very large frontends.

Accessibility, UX, and native elements

  • Many emphasize native semantics (<button>, <details>, <summary>, <datalist>, proper ARIA) as crucial for accessibility and keyboard/screen‑reader support.
  • Others note native controls (date pickers, multiselects) are inconsistent, hard to style, and often too limited, pushing teams back to custom JS components.

Historical / meta themes

  • Several comments frame this as another turn of a recurring cycle: inline → CSS/JS separation → JS frameworks → now “HTML‑first” again.
  • Strong disagreement over whether this is genuine progress, useful course‑correction, or just the latest fad.