Introducing My Astro Blog

After two years of coding in the work world, it’s high time to make a personal website for tracking my projects and budding skills. At the beginning, coding seemed like a beast that only could be tamed after years of education (which I didn’t have). I watch a lot of Youtube, and I quickly found two channels that fundamentally changed my learning path: the Primeagen and Fireship. I barely understood 5% of what they said, but their hardcore approach is what formed my opinions and nurtured my interests. Two years later, because of them, I have chosen Astro as my framework to build this website. I learned a lot, and here are my thoughts after completion of my first iteration.

Other Javascript Frameworks

I began learning web development with React. It is popular and well-documented, which made it very easy to find high-quality resources. It is also heavily abstracted from raw browser api functions, which is nice for learning but bad for broad understanding. Luckily for me, I began learning React after functional components were well-established, but it was still a struggle to adopt the React way of thinking.

To be brief, React and other dev tools like it introduce a lot of complexity that isn’t justified for most websites. Good-old fashioned HTML, CSS and a sprinkling of JS can get a surprising amount of work done while maintaining an easier code base. Most applications don’t need much data interactivity to justify what React brings to the table, and they sacrifice site performance as a result.

What’s Astro?

Astro’s goal is to ship as little Javascript to the client as possible. It’s a return to old-school statically rendered sites, where the files are generated on the server and ready for instant transfer when a client requests it. However, it uses Javascript for developers to dictate how the server behaves, without needing to know a separate backend language, all while managing to remain very terse:

---
import { getCollection } from  "astro:content";
const  allPosts  =  await  getCollection("posts");

allPosts.sort((a, b) =>  b.data.pubDate.getTime() - a.data.pubDate.getTime());
---

Astro also offers the ability to ship other framework components via “islands,” a design choice which again, minimizes javascript to only parts of the sites that are needed. It also allows for different hydration choices, meaning that islands can be rendered when it makes sense.

Finally, as of recently, Astro offers experimental SSR and hybrid rendering modes. This means that the developer can essentially opt-in to generating pages dynamically as the user requests them, without affecting the entire website. The classic use-case for this is authentication, where the server determines if the user has access priviledges to the page they are requesting, based on their session cookie.

What Does This Website Need?

I set out with a couple goals for this website, while trying to keep it as future-oriented as possible.

1. It should be blog-centric, focusing on information about me and what I’m learning.
2. Performance is key, because I am a marketer and will likely track performance metrics.
3. Ability to create and showcase fun, dynamic components.
4. An authentication layer to create a sort of personal idea repository in blog format.

Astro is well-suited for these tasks and has given me an excellent project development experience. Content collections are a very efficient way to organize blog entries, and component fences are intuitive for keeping data views and controls in the same place. It is highly performant, with features like pre-fetching, and because it ships minimal javascript. It allows for islands of interactivity with React, Vue, Angular, Svelte, etc. It also supports cookie manipulation and server-side rendering, which can be used for created auth-protected pages (it’s a bit complicated, but well-documented). I plan on talking a bit more about the nuances of these factors in other posts, so stay tuned. Thanks for reading!