Astro is a return to the fundamentals of the web

Original Article ↗ Hacker News Discussion ↗

Title, tone, and terminology reactions

  • Original “developer’s f* dream” title and the “f*” shorthand confused many; mods changed the HN title.
  • Several commenters find the article’s writing style very “LLM-like” and formulaic, sparking meta-discussion about how humans now get mistaken for bots.
  • New jargon like “hydration”, “islands”, etc., feels alien or overblown to some; others note these ideas existed long before the terms.

Astro’s model and perceived strengths

  • Fans like that Astro is HTML/CSS‑centric, static by default, with opt‑in JS “islands” for interactivity.
  • Praised features: components with props and type safety, content collections, built-in image/CSS optimizations, and Vite-powered dev experience with hot reload.
  • Several report good experiences replacing WordPress/Jekyll and building personal, docs, or marketing sites with very fast load times.

Comparison to “fundamentals” and classic tools

  • Many note Astro’s “static first + sprinkles of JS” is just progressive enhancement / old-school web pages, similar to PHP+jQuery, Rails, Django, Laravel, or even SSI.
  • Skeptics argue you can get similar results with plain HTML/CSS/JS, traditional template engines, or static site generators like Hugo, Jekyll, 11ty, Zola.
  • Supporters respond that Astro’s DX (components, islands, tooling) is a substantial upgrade over raw templates.

Astro vs other modern frameworks

  • Compared frequently to Next.js, SvelteKit, Fresh, htmx/Datastar:
    • Next.js with React Server Components also does per-part hydration, but is seen as heavier and narrower in scope (routing/data/bundling, less “full-stack” than Rails/Laravel).
    • SvelteKit gets praise for static+dynamic routing; some think Astro is a downgrade unless you specifically want islands.
    • Fresh is islands-only Preact on Deno; Astro is more framework-agnostic but requires a build.
    • Some prefer htmx/Datastar plus any backend for simpler, backend‑agnostic progressive enhancement.

Use cases, complexity, and CMS

  • Broad agreement Astro excels at content-heavy sites: blogs, marketing, docs, catalogs, portfolios.
  • Debate whether it suits “complex apps”; some say yes via islands and microfrontends, others think SPAs or server frameworks are better.
  • Lack of built‑in CMS is a sticking point for small-business sites; you must integrate a headless CMS or roll your own, versus WordPress’s turnkey admin.

Performance, hydration, and islands

  • Supporters emphasize perceived performance: static HTML visible quickly, with JS hydrating only interactive parts.
  • Critics question sending non-functional HTML that needs JS to work, and argue true progressive enhancement should keep forms and core flows functional without JS.
  • There’s technical back-and-forth on CSS inlining vs caching, HTTP/2, and when inlining actually helps.

Concerns and criticisms

  • Complaints about needing npm and a build step for “fundamentals of the web”; some reverted to raw HTML/CSS.
  • Telemetry-by-default and JS-based SSR are disliked by some who’d rather use Go/Rust or simpler stacks.
  • Routing for more complex setups is reported as confusing by at least one user.
  • Longevity worries: will today’s Astro-based sites still be easy to build and maintain in 5–10 years?

Meta: industry memory and fashion

  • Several note frontend repeatedly “rediscovers” old ideas (AJAX, DHTML, progressive enhancement) under new names, with little historical memory.
  • The frontend ecosystem and its debates are compared to the fashion industry or a cargo cult more than to stable engineering discipline.