The migration was faster than the old excuses
This website started as a lightweight setup: mostly vanilla JavaScript, a little Preact where interactivity helped, and a lot of custom glue. That stack made sense at the time. Direct, understandable, easy to bend.
But once the site needed real pages, direct-linkable articles, prerendering, and stronger SEO, the old shape became friction. Not impossible frictio, just the kind that keeps whispering: keep patching what you already have.
So I did the migration anyway. The interesting part is not that it worked. It’s how fast it worked.
From custom glue to route-native pages
The old site relied on hash navigation and SPA-like overlays. Fine until you want pages that behave like actual pages.
The blog was the clearest case. Articles existed as content, but they weren’t first-class documents on the web. Search engines want paths. Links want paths. Sharing wants paths. A route like /blog/my-article is simply a better unit than #/blog/article/my-article.
With Astro, that became straightforward. The content already existed. The migration mostly meant giving it a route structure, a shared layout, proper metadata, and static output.
What stood out: the work was less about fighting integration and more about making clearer architectural choices.
Why this matters now
For a long time, teams treated stack changes as inherently expensive. The cost wasn’t just rewriting cod, it was setup, adapters, build tooling, deployment friction, and all the little incompatibilities that made “best tool for the job” sound good in theory but expensive in practice.
That excuse is getting weaker fast.
In this migration, integration cost was close to zero compared to a few years ago. Content stayed in JSON. Preact still worked where I needed islands. Static generation, routing, sitemap generation, and page metadata came almost for free once the structure moved into Astro’s model.
The hard part wasn’t integration. The hard part was deciding to stop defending the old choice.
The old mindset optimized for switching cost
A lot of projects still carry an outdated instinct: once a tool is in the repo, everything should be forced through it.
That made sense when every new tool meant days of friction and a serious risk of breaking the whole system. But that’s no longer the environment we work in.
Today, the cost of combining the right tools has collapsed. Not to literal zero, but close enough that it changes how decisions should be made. A simpler rule wins: use the tool that fits the job best.
Not the tool you already happen to have. Not the tool you know best. Not the tool that avoids a migration conversation.
The one that fits the job.
What the migration actually proved
Moving from vanilla JavaScript with a little Preact to Astro didn’t require a dramatic rewrite of everything. It required:
- Identifying the parts that should become real pages
- Preserving the parts that were already useful
- Isolating interactivity into small islands instead of dragging the whole site into client-side complexity
- Letting the build tool do what modern build tools are now very good at
The web stack is no longer a place where one wrong early choice traps you for years. If the architecture is reasonably clean and the boundaries are understandable, changing direction is far cheaper than many teams still assume.
Architecture should follow fitness, not inertia
I don’t find it convincing anymore when people argue for a weaker fit just because it avoids mixing technologies.
Uniformity still has value. Simplicity still matters. But there’s a difference between coherence and inertia.
If one tool is better for static pages, another for client-side interaction, and another for automation or content workflows, the default should be to compose them wel, not flatten everything into one compromised system.
Closing thought
Integration cost has dropped so much that tool choice can be driven by fitness rather than fear.
That doesn’t mean chasing novelty. It means being honest about purpose.
Vanilla JavaScript was useful. A little Preact was useful. Astro was the better tool for where the site needed to go next.
Choose the best tool for each purpose, and stop pretending the cost of doing so is still what it used to be.