Just fucking
use Astro

This essay was written by Michael Andreuzza at Lexington Themes, the individual responsible for making this argument possible during a rare moment of unallocated time.

Most websites are content with a small amount of interactivity. If you are shipping a full single-page application for a marketing site, you are not “modern.” You are being architecturally negligent, prioritizing developer convenience over user experience, and actively degrading the quality of the web.

This is a public service announcement for developers who are still building websites as if the last decade of tooling evolution never happened, and proudly presenting the result as innovation.

• "No frameworks ever." Congratulations: you have rebuilt a significantly worse CMS with inferior routing, brittle builds, and no meaningful guardrails. Your system is one junior developer away from becoming an unmaintainable collection of markup.
• "SPA for everything." Congratulations: you shipped hundreds of kilobytes of JavaScript to render static content. Your users did not consent to executing your architectural thesis in their browser.

• Pages
• Content
• Navigation
• Forms
• A small number of interactive widgets

not because websites should masquerade as desktop applications awkwardly embedded in browser tabs.

Because “pure HTML at scale” is a comforting myth that collapses the moment your site grows beyond a trivial number of pages and shared concerns.

• Layouts are duplicated endlessly instead of abstracted
• A “small amount of JavaScript” devolves into an unstructured tangle
• Content becomes loosely defined and error-prone
• The build process turns into a fragile chain of scripts and workarounds

Astro provides structure without forcing everything into the client or demanding ideological purity.

• Componentization without committing to a monolithic JavaScript framework
• Proper layouts instead of copy-paste repetition
• Predictable file-based routing
• Typed content collections that prevent broken frontmatter
• The freedom to use React, Vue, or Svelte only where it is justified

And yes, this remains true in December 2025: Astro ships zero client-side JavaScript by default. No caveats. No hidden costs. No unnecessary hydration.

Because React is excellent, for applications.

Most websites are not applications, regardless of how strongly some teams wish they were.

• Marketing pages
• Documentation
• A blog
• Landing pages
• An ecommerce frontend (not a client-side simulation)

then shipping a full SPA is equivalent to deploying industrial machinery to solve a trivial problem.

Astro embodies the “HTML-first, JavaScript-when-necessary” approach that many developers claim to follow but rarely enforce.

Here is the correct mental model.

Your page is static by default. Interactivity is the exception.

Need a carousel? Make it an island.
Pricing toggle? Island.
Search? Island.

Everything else remains server-rendered, predictable, fast, and respectful of the user.

• Substantially less JavaScript delivered to users
• Fewer hydration-related failures
• Reduced debugging complexity
• Pages that function immediately rather than after a JavaScript initialization phase

You do not need to hydrate the entire page. You need to hydrate the single component that requires it, and leave the rest alone.

Use Astro when:

• Your site is primarily content with selective interactivity
• SEO is a real requirement, not a slide-deck bullet point
• You want componentization without an SPA performance penalty
• Frameworks are tools, not defaults
• Interactivity is localized rather than global
• You want maintainability beyond a few dozen pages

If your response is “I can do this with vanilla JavaScript,” that may be true, but difficulty alone is not a virtue, and unnecessary friction is not a mark of expertise.

Astro is not appropriate for:

• Heavy client-side applications with pervasive shared state
• Real-time collaborative systems
• Interfaces where nearly every element is interactive
• Complex offline-first applications

Stop treating it as a website and use:

• React / Next
• SvelteKit
• Remix
• Whatever your team can competently maintain

Astro is designed for websites that behave like websites, with selective application-level behavior where appropriate.

When used correctly, Astro does not ship what you do not use. That is the design goal.

If your Astro site delivers hundreds of kilobytes of JavaScript, you have ignored the model and reconstructed an SPA. That outcome reflects misuse, not a tooling flaw.

The real issue is the inability to evaluate the problem at hand. Tool choice is treated as identity rather than engineering judgment.

Some teams build everything as if it were static marketing collateral.
Others build everything as if it were a state-saturated application.

Not preference or ideology:

• Website? Astro.
• Application? Full framework.
• Hybrid? Astro with islands.

Stop treating tools as extensions of personal identity. This is engineering. Approach it with professionalism.