Next, Nuxt, Gatsby, SvelteKit … there’s been an explosion of frontend application frameworks lately. I’ve tried many (but not all) of them, and I’ve got to say, it’s never been a more delightful experience to spin up a new project. So much so, that I’ve got hundreds of unfinished ones lying around everywhere.
Recently, Astro, another new frontend application framework, launched itself on the unsuspecting JavaScript public.
Whilst many of us may have been tempted to say “oh no not another one”, this framework really stood out to me.
What’s the point of difference with this one? Why does it “matter” so much? Well, consider this:
1. Frontend can be one happy family again #
Astro could be considered the first frontend “meta framework”.
What’s one of those then? It’s a “set of core interfaces for common services and highly extensible backbone for integrating components this is already Java thing by the way.
Astro is essentially a “bring your own frontend” approach to modern web frameworks. You can use whatever framework (oh, ok “library” then) you know and love, and still spin up a performant app that you can host almost anywhere.
Think about the potential here. Astro could be the place the frontend finally comes together. It no longer matters (as much) what framework you use. Use them all if you like 🤷♂️.
Love Vue? You can love Astro. React? Same. Svelte? You’ll find no argument from Astro, because Astro is the glue that underpins how we build websites and applications.
Great, innit? It’ll probably never happen but I can dream, can’t I?
2. Astro pushes the boundaries for every javascript framework* #
(* oh, ok library then)
Take a look at this tweet from Evan You, the creator of Vue:
Is it a coincidence that Vue now can do a similar thing to Astro? did Astro get Evan to start thinking more about this problem? Could the same be said for the other frameworks too?
I know the React team have been working on it for a long time. I even opened (very prematurely it turns out!) this issue on the GatsbyJS repo around 2 years ago.
React 18’s hydration prioritisation is a good step forward, however the whole DOM tree still need to be hydrated. Won’t it be great when we need only attach JavaScript generated elements to the DOM when components really need them?!
It would be wonderful to think that partial rehydration could be everywhere, it would certainly level the playing field and even things up a lot for the next 1 billion web users.
Check out Astro #
If you care about performance (you care right?) please check out this gamechanger. I’m so excited for the potential here.