Generally, a tutorial explains how to do things. I also like to explain why I do them, what motivates my decisions. This article is the introduction to a series where I explain how I created and deployed my personal blog using modern technologies like Astro, TypeScript, and GitHub Pages. Here, I’ll tell you about the objectives I have for this blog and why I’ve made each technological decision.

What is my goal with this blog?

Every technological decision must be aligned with the overall goal. That’s why the first question I ask myself is about the objective I’m aiming for.

In general, when we create a personal blog, we do it to share knowledge, experiences, and reflections. If the blog is created to build a personal brand (as is the case here), then we will share knowledge, experiences, and reflections on topics that we believe define that brand.

In my case, these topics are software development in general, secure software development, and the management of secure development projects. Additionally, I also try to discuss “technical selfishness.” And this last point is the most significant factor in setting my objective.

I haven’t maintained a blog in my 20-year career because I’ve always been too busy working. The desire to achieve and do more with less gave rise to this philosophy (the “technical selfishness”).

Therefore, my goal is to create a blog that I “don’t have to manage” and that I can easily expand with new features.

To achieve this, I made the following decisions:

1. Manage content creation from Obsidian

Obsidian is the foundation of my “second brain.” Everything I write and document ends up there, so it is also the place where I typically generate the articles that may end up on this blog. Obsidian works based on Markdown files, which will influence many of my decisions.

On the other hand, it supports the use of symbolic links (or “shortcuts” if you’re a Microsoft user), allowing me to manage content from Obsidian that is stored in a folder outside its structure.

2. Develop using Astro as the foundation

Astro is a relatively new framework focused on generating static websites, but with the ability to include interactive components only where they are really needed. Additionally, it is focused on performance optimization. Astro generates static HTML by default and only loads JavaScript in the browser when absolutely necessary.

There are other frameworks that allow generating static HTML with JavaScript loaded as needed, but as I try them, I find drawbacks (and if I talk about them, it will be in another post). It’s not that I won’t use them, but rather that Astro offers me an agnostic base compared to other frameworks.

On one hand, its orientation towards static HTML generation is ideal for a blog, as most of the content is static.

On the other hand, Astro allows me to work with multiple component frameworks like React, Vue, or Svelte, giving me flexibility for future expansions or experiments.

My star reason: Astro works out of the box with Markdown files (and with a small configuration, it also supports MDX), so it is ideal for integrated use with Obsidian.

3. Develop using TypeScript

TypeScript is a superset of JavaScript that adds static typing to the language. At this point, TypeScript has its supporters and detractors. And I’m not talking about people like me, but titans of development who have used TypeScript in demanding and competitive environments. This warrants another post… or perhaps an entire series of posts with arguments for and against.

For me, the main reason for choosing TypeScript is that it has static typing, which allows me to catch errors before executing the code, significantly reducing bugs and the tests needed to detect them, and increasing the maintainability of the project.

Additionally, the clarity it brings (IMHO) through its types and annotations makes the code more readable and easier to understand, both for me and for anyone who might contribute in the future.

On the other hand, the complexity of having to find or create the appropriate type when necessary is more than compensated for by the ability to catch many more errors at transpilation time. And this helps me sleep very peacefully with projects that may be in the hands of junior developers.

In a project like this blog, which is likely to become a project template, I consider TypeScript to be key to facilitating future developments that don’t depend on me.

4. Store the generating code in a private repo

I will likely create a blog template for Astro based on this blog. That template will be public (obviously) so that anyone can use it.

However, this blog will probably grow beyond what that template offers, and while they may influence each other (by adapting a future feature of the template to this blog or vice versa), the differences in this blog will be proprietary.

By working with a private repository, I can control who has access to the code and avoid exposing sensitive details to the public.

Additionally, keeping the source code in a private repository allows me to experiment and test new features without worrying that unfinished or experimental code will be made public. This gives me the freedom to iterate quickly and ensure that the code I eventually deploy is of the highest quality.

5. Publish the website on GitHub Pages

GitHub Pages is a free and highly reliable platform for hosting static websites directly from a GitHub repository. The choice of GitHub Pages for this project is straightforward: it’s easy to set up (custom domain with HTTPS included), integrates perfectly with GitHub’s workflow, offers excellent uptime, and, most importantly, I don’t need to maintain it.

Another key reason is the simplicity it offers in deployment. With GitHub Actions, I can fully automate the process of building and deploying the website from my private repo to a public repo containing only the final static files, allowing me to focus on development and content without worrying about the infrastructure.

It’s clear that I could have used other platforms, but as I mentioned at the beginning, I’m looking for more with less, so I don’t want platforms that require constant maintenance or servers that demand my attention.

With this stack, I can focus on experimenting, learning, and demonstrating what I already know. I can be creative in a way that other stacks do not allow.

Moreover, most of what I write on this blog will be republished on platforms (in Spanish on LinkedIn and in English on Medium), so I don’t expect much traffic beyond close contacts and the curious.

---

This article is the starting point not so much to understand how to build a modern blog, but why I’ve made certain technological decisions, so I invite you to contact me if you have questions or similar, complementary, or opposing opinions.