The conventional advice is to finish the project first, then learn the better tool. I ignored that advice, and I think it was the right call — but not for the reason most people give when they argue for jumping to new technology mid-stream.
Here’s what actually happened.
What pushed me over
About three weeks into building a content-heavy site in React, I hit a specific problem: I was rendering a blog index page using useEffect to fetch a list of posts that never changes. The data was static. The content was static. But I was shipping JavaScript to the browser to fetch and render it on every page load, managing loading states and error handling for content that could have been baked into HTML at build time.
I’d been aware of Astro for months. I’d bookmarked the docs. I kept telling myself I’d look at it properly after the project was done.
Then I spent two hours on that blog index page, and the gap between “what React is designed for” and “what this page actually needs” became impossible to ignore.
The real cost of switching mid-project
I want to be honest about this because I’ve seen people frame mid-project pivots as clean wins. It wasn’t painless.
I spent about four days in transition — migrating components, learning Astro’s file-based routing, understanding the content collections API, figuring out how to structure a project that’s partly static and partly interactive. Four days when I wasn’t making forward progress on the actual product.
Whether that’s worth it depends on the project. For a learning project like this portfolio, it clearly was. For something with a real deadline and real users depending on it, the calculation is different.
What I had to actually unlearn
The syntax shift was minor. The mental model shift was significant.
In React, my default assumption is: everything is a component that runs in the browser. State management, data fetching, rendering — all of it happens client-side unless I explicitly opt out.
In Astro, the default is inverted: nothing runs in the browser unless it needs to. Pages are HTML by default. Components are templates by default. JavaScript only ships when you explicitly ask for it by adding a client:* directive.
That inversion sounds simple but it changes how you approach every design decision. Before reaching for state, I now ask: does this actually need to be stateful? Before reaching for a component, I ask: does this need to be interactive, or does it just need to render?
Most things don’t need to be interactive. Most content doesn’t need JavaScript. Astro makes the right choice the default choice — you have to opt in to complexity rather than opt out.
The island architecture in practice
The navbar on this site has scroll behaviour and a mobile menu — it needs JavaScript. The contact form has validation and submission state — it needs JavaScript. Every other section is just content.
With Astro, those two components hydrate on the client as React islands. Everything else is static HTML shipped directly, no JS overhead, no hydration cost. The result is a site that feels like a React app on the interactive parts and loads like a static site everywhere else.
That’s not a compromise. That’s actually better than either pure React or pure static HTML would have been for this specific use case.
Was it worth doing mid-project?
Yes. Not because Astro is magic, but because learning it when I had a concrete problem to solve made everything stick faster than any tutorial would have. I wasn’t building a contrived example — I was solving an actual problem with a real production consequence.
The more general version: if you’re working on a project and you discover there’s a tool that would meaningfully improve what you’re building — not a marginal improvement, but a structural one — the right time to learn it is probably now. The delay cost is real. The cost of the wrong foundation compounds.
Finish-first advice exists for a reason, and it’s often correct. But sometimes the better tool is how you finish the project properly.