A standards-first web framework

Original Article ↗ Hacker News Discussion ↗

A new “standards-first” web framework called Nue aims to strip away heavy JavaScript abstractions like React and Next.js, instead centering development on semantic HTML, vanilla CSS, Markdown for content, and minimal JavaScript. Commenters are split: some welcome the return-to-basics ethos and fast, lightweight tooling, while others criticize the project’s reliance on non-standard pieces (Markdown, a custom templating DSL, Bun), its React‑ and Tailwind‑bashing tone, and its current focus on relatively simple, mostly static sites. Many agree modern browsers can handle more without large frameworks, but question whether Nue’s approach will scale to complex, stateful applications or primarily serve as a niche alternative for content-heavy sites.

Overall Reception

  • Mixed response: some are energized by the attempt to strip away complexity and embrace modern browser capabilities; others see it as overhyped, underbaked, and mainly suited to static blogs.
  • Many agree current frontend stacks are complex, but disagree that pre-framework days were good or that Nue’s approach solves today’s hardest problems.

“Standards-First” Claim (Markdown, Bun, DSL)

  • Critics argue “standards-first” is undermined by:
    • Heavy reliance on Markdown (non‑standard, limited semantics).
    • A custom templating/attribute DSL (:for, @click, etc.) that is not HTML/JS.
    • Required tooling (CLI, Bun) and YAML config.
  • Defenders say:
    • Markdown is just a content format that compiles to semantic HTML and keeps content separate from layout.
    • Bun uses web-style APIs; Node also isn’t a “web standard.”
    • Standards live in the browser surface (HTML/CSS/JS), not in authoring tools.

Separation of Concerns, CSS-Centric Design, and Tailwind

  • Framework emphasizes strict separation: HTML for structure, CSS for design, JS for behavior; aims for codebases that are “mostly CSS.”
  • Some resonate, especially design‑system–oriented developers who like modern CSS (variables, container queries, view transitions).
  • Others argue:
    • Real complexity in apps is state management, data and business logic, not styling.
    • Component colocation of markup, logic, and styles is practical and proven.
    • Tailwind and atomic CSS help teams avoid CSS “spaghetti” and bikeshedding.
  • Debate over whether React/Tailwind “tight coupling” is a regression or an evolution driven by real-world needs.

Scope: Static Sites vs Apps

  • Current implementation appears strongest for content-heavy static sites; comparisons are made to Astro, 11ty, etc.
  • Multiple commenters doubt the approach will scale to complex, highly interactive SPAs or data-heavy apps; want concrete SPA examples and clear scope like HTMX provides.

Comparisons to Existing Tools

  • Frequently compared to React/Next, Astro, Svelte, Vue, HTMX, Lit, and Flutter.
  • Some see it as “Vue/Svelte-style” single-file templating plus islands, not fundamentally new.
  • Lit/web components advocates argue they are also standards-first; disagreement centers on whether components inherently violate “proper” separation.

Tooling, DX, and Maturity

  • Praised for very fast startup and HMR, and for generating clean HTML.
  • Criticisms:
    • Bun + global CLI requirement; limited or untested Windows support.
    • Early-stage gaps in docs, examples, testing guidance, editor integration, and runtime error clarity.
  • One detailed user report: building a Todo app was fast and pleasant overall, but debugging and documentation rough edges were significant.

Messaging and Tone

  • Several commenters find the tone dismissive of React/Tailwind and overly grand (e.g., “30x smaller than Next”) given the limited feature set and reliance on cutting-edge browser APIs with incomplete support.
  • Suggestions: less bashing, more precise claims, fairer comparisons, clearer explanation of what’s truly different and where it’s appropriate to use.