On choosing the right framework

We get asked, often, why we reach for Astro on most marketing and content-heavy projects. The honest answer is: it asks less of us, and gives more to our users.

The criteria

Before any framework decision, we ask four questions:

• What does the user pay for this choice? Measured in download size, time-to-interactive, and battery.
• What does the team pay? Measured in onboarding time, build complexity, and debugging difficulty.
• What does the business pay? Measured in vendor lock-in, hosting cost, and migration risk.
• What does the future pay? Measured in how well this will age over five years.

A framework that wins on three of four is usually the right pick. Winning on all four is rare and worth celebrating when it happens.

Where Astro fits

For content-heavy sites — marketing pages, blogs, documentation, portfolios — Astro is currently our default. It ships zero JavaScript by default, integrates cleanly with any UI framework when needed, and produces output that any host can serve.

For complex interactive applications — dashboards, editors, real-time tools — we usually reach for something else. Astro’s “islands” model is brilliant for sprinkling interactivity into mostly-static content, but it isn’t the right shape for a fully dynamic SPA.

The boring conclusion

The best framework is the one that makes the work you actually have to do easier. That’s almost never the newest, loudest, or most discussed. It’s usually the one that quietly disappears so you can think about your actual problem.