Astro

Astro is an open-source web framework built around a simple default: a page is HTML until something on it has to be interactive. Components render on the server at build time, the browser receives markup and CSS, and the client-side JavaScript is limited to the specific components that need it, the pattern its documentation calls islands.

That default is why we reach for it on content-driven work. A marketing site, a documentation set or a publication is read far more often than it is interacted with, and a framework that sends a full application runtime to render a paragraph is paying for the wrong thing. Pages built this way start fast on a mid-range phone and on a slow connection, which is where most of the traffic actually is.

It is also framework-agnostic where that helps. An existing React, Vue or Svelte component can be dropped into an Astro page and hydrated on its own, so a team already invested in one of those does not have to rewrite a component library to move a site onto Astro.

Content is typed rather than loose. Content collections validate every entry against a schema at build time, so a missing field or a malformed date fails the build instead of reaching production as an empty element. It is the same argument for TypeScript, applied to the copy.

What we get out of it on a typical build:

• Static output that deploys to a CDN or object storage with no server to patch, or server rendering through an adapter where a route genuinely needs to be dynamic.
• Schema-validated content, so editorial mistakes surface in CI rather than on the page.
• Per-page control over what ships to the browser, which keeps Core Web Vitals a property of the architecture instead of something chased after launch.
• Built-in handling for the parts every content site needs anyway: image optimisation, sitemaps, RSS, redirects and Markdown or MDX authoring.
• A component model close enough to plain HTML and CSS that a designer can read a template, and a build that a client team can take over.

It is not the right choice for everything, and we say so before it gets picked. Application-shaped work (a dashboard, an authenticated workspace, anything where most of the screen is stateful) belongs in React or Angular, and forcing it into a content framework produces a worse version of both. The same goes for a site whose editors need a CMS that Astro has to be wired into: that integration is real work, and it is worth costing up front rather than discovering late.

Where a project is genuinely a mix, a fast public site plus a small logged-in area, that boundary is usually the right seam to design around, and we would rather draw it deliberately than end up with one framework doing both jobs badly.