Don’t get me wrong; I love Next.js. However, my goal for this blog site leans more towards the niche that Astro offers. On Astro’s website, it says, ‘Astro builds fast content sites, powerful web applications, dynamic server APIs, and everything in between.
For starters, you can see in the image below that this blog post scored 100% in all aspects of CWV (Core Web Vitals). I had spent a lot of time banging my head against the wall when I tried to achieve the same thing using Next.js. With Astro, achieving this Core Web Vitals score is an everyday thing.
Don’t believe me? Check the actual score for yourself at this link.
I’ve also watched many YouTube videos from ThePrimeagen and Theo.gg talking about Astro, which significantly influenced me to consider making the switch. Theo provided a comprehensive overview of Astro, inspiring me to give it a try for the blog site I’m building. I’m glad I did, and I don’t regret it.
TL;DR: In this blog post, I’m only going to cover the most basic things that I believe are crucial to mention when explaining why I switched from Next.js to Astro. It’s impossible to cover every aspect of these two web frameworks, and to be honest, I don’t know everything about Next.js and Astro either. If you think there are things I missed, please feel free to correct me in the comment section below.
Allow me to demonstrate why Astro’s architectural decisions made more sense to me than what Next.js provides.
Components, Pages & Layouts: Astro vs. Next.js
Next.js and Astro’s implementation of components are very similar.
In Next.js:
(1) Server Components: All the components you create are automatically generated as React server components by default. This means that each time you create a .jsx or .tsx file inside your app directory, it’s automatically rendered as a server component. So, if you want to perform computations, you have access to low-level functions that you don’t get when rendering React on the client side. However, you can create a client component by adding the “use client” directive at the top of your jsx file, making it easy to add interactivity. This is what I really like about Next.js.
(2) Public Pages: The only way to expose your route publicly is to create a file called “page,” which can be a .jsx, .tsx, or a .js file under a named route folder.
(3) Layout System: Next.js offers a layout system structured hierarchically. It follows a convention where your components should be inside the app directory. From there, you can create a root layout component shared by components in different folders of your application under the app directory. On top of that you can create, layouts inside another child directory.
With Astro:
(1) Everything is Server Components: All your components are either rendered at build time or server-rendered. This is almost the same design as Next.js, but the key difference is that you have a clear distinction where your components, layouts, and pages reside, as they have separate folders inside your src folder.
(2) Public Pages: All the pages you want to expose publicly should be inside the src/pages folder, which is my preferred way of structuring my files. With Next.js, I had to repeatedly create many page.js files nested on top of each other in the directory structure just to achieve the file-based routing setup.
(3) Layout System: This is where Astro excels (in my opinion)! In Astro, all your publicly available pages allow you to pass props to the layout component. The Layout component is where you place your HTML head where your meta data resides. Doing this allows you to dynamically add meta tags to the head tag of your web page, which is excellent for SEO. Additionally, you can add your Open Graph meta tags dynamically to display the content when shared on social media platforms.
In Next.js, you have limited options to do this. In fact, passing data between a parent layout and its children is not possible in Next.js. On top of that, layouts do not have access to the route segments below them. You’ll need to implement workarounds, which to this day I haven’t been able to wrap my head around, just to achieve the same functionality that’s inherently possible with Astro with ease.
Astro Supports React, Vue, & Svelte
Yes, that’s right! You can use your favorite UI frameworks with Astro. Don’t believe me? You can check it out for yourself at this link. In fact, the component that powers this specific blog post is a React Component.
Since I am using a Headless Content Management System called Contentful, I had to wrap the content of this blog post into a JSX file where it’s easier for me to work with Contentful’s Content Delivery API. And the best part is that Contentful is free!
Core Web Vitals
Lately, this is what everyone is going crazy about. When Google introduced Core Web Vitals in the 2nd quarter of 2020, everyone on the internet got excited but was also worried at the same time. The anxiety stemmed from the fear that their websites might rank low on Google’s search engine. Websites built using frameworks and content management systems often fell short when assessed against Core Web Vital scores, so to speak. The primary culprit was the excessive shifting of JavaScript code to the client during the request/response cycle. Many of these websites run on PHP, where server-side rendering is the prevailing norm (I love PHP by the way).
Astro’s approach of not shipping JavaScript to the client filled me with skepticism at first. However, that skepticism didn’t last long once I tried Astro; it simply blew me away!
On top of that, it only took me less than 24 hours to make the switch. The reason is that Astro only uses HTML, CSS, and JavaScript. They didn’t created something that will require you to learn another language. What’s already available is what they used. So, switching is not big of a deal when it comes to Astro.
I could probably make my Next.js app as performant as Astro’s, but I’d likely spend more time wrestling with it and searching through the documentation. Remember, lost time is lost time. Next.js would probably be more efficient if you’re building a web application with features like dashboards, user management, and reports where SEO isn’t a primary concern.
My Final Thoughts
Before I built this blog site, I found myself at a crossroads, debating between using something like WordPress and other technologies similar to Astro. Of course, it would have been much easier to go with WordPress, but for a simple site like this, I asked myself a lot of questions:
- I’d like to create a straightforward blog to express myself. Can I do this without adding too much complexity?
- Is a full-fledged Content Management System (CMS) necessary for my relatively simple blogging needs?
- Do I really need to pay for expensive servers when I can use something like Vercel?
- Is extensive interactivity required for an excellent user experience on a blog?
I may have missed writing the other questions or self-reflections I asked myself, but for a simple content-driven website like this, it doesn’t require something groundbreaking.
While having a good Core Web Vitals score is as crucial as other SEO metrics, what truly matters is how good or unconventional the content you’re putting out there is at the end of the day. And remember that the choice of a web framework depends on individual project requirements, and what works best for one project may not be the same for another.