Alex Edwards

Migrating to Astro

TL;DR

Over the course of 12-ish hours of work, I was able to migrate from using Nextjs site to Astro.

Hosting

There’s several things to be admired about NextJS, but I wasn’t entirely happy with going against the grain when it came to hosting. In short, NextJS promotes either their own platform (vercel), or self-hosting with NodeJS handling the incoming HTTP/s request directly.

Other frameworks however, such as Astro, Sveltekit, Nuxt etc. are pursuing an ‘adapter’ approx for production.

Loading graph... Javascript is needed for the graph to render

Changing hosting from Nodejs, to AWS Lambda, to Cloudflare workers is as simple as building the framework with a specific adapter.

Trimming javascript requirements

I’ve built out a fairly static site, where interactivity is normally facilitated by web standards rather than Javascript. While transitioning to a SPA during hydration, without all the javascript, page-load is relatively quick and made better with prefetching. I don’t need personalised rendering and caching layers are handled by powerful CDNs. However, thanks to Astro, I can now ‘opt-in’ to javascript libraries such as React or Svelte. Running client-side code where needed, with strategies similar to lazy-loading images - even more flexibility than simply async or defer scripts.

In the future, Astro still facilitates features such as remote content, API endpoints, authentication.

Final Thoughts

My experience transitioning to Astro has been relatively seamless.

It helped to not have much “skin in the game” with the previous iteration, but what there was, transitioned very quickly to astro components for static javascript-free components, or the couple react-based components to be hydrated on the client.