Yet Another Site Rebuild

It’s a tale as old as time (or, at least as old as the internet and web development) - a developer has a fully-functional personal website, but can’t resist the urge to rebuild it using a different technology stack. It may be a bit of tired trope, but I’m certainly not immune; the purpose of this post is to celebrate yet another rewrite of my site and some thoughts I have related to the process.

Reflecting on the Past

A large rewrite and/or refactor is always a good opportunity to reflect on the history of a codebase and how it has morphed over time.

I started maintaining a personal website back in high school - I think close to my senior year, so ~2009 / 2010’ish. I was doing freelance writing at the time and wanted a place to showcase some writing samples, rates, and reviews from past clients. I found a very simple HTML template and modified it to fit - nothing fancy, but got the job done.

Since then, both myself and the site have gone through some major changes. I graduated high school, went to college and earned a business degree, went into digital marketing, and finally pivoted to software development - where I’ve been ever since. As my technical skills progressed, I would often use my website as a low-pressure environment to experiment with different frameworks and tools.

As I look back on all the iterations of the site, I’m filled with pride for how far I’ve come and appreciation for the journey along the way. Although there are certainly many aspects of the codebase and UX that I wouldn’t use as examples of my best work, I think it is important to acknowledge that making mistakes and trying things out - especially in personal projects - is a critical part of growing as a software developer.

All the Iterations of the Site So Far

Screenshot	Dates	Tech Stack	Notes
	2009-2011(ish)?	Static HTML	Don’t judge me please! I was literally a teenager at this point 😂
	2012-2016	Google Blogger (XML templates, WYSIWYG Editors)
	2016-2018	Hand-Rolled PHP	…
	2018-2026	WordPress + my own custom theme
(Looks pretty much identical to the WordPress version right now)	2026-?	Astro + my previous WordPress theme, rebuilt as Svelte components + standard CSS

The Rewrite

Despite being in use for about 8 years (!), the WordPress theme that I had built for myself actually chugged along the entire time with pretty much no major issues. Thanks to the stability of WordPress, breaking changes were pretty much nonexistent during system updates, and thanks to some off-the-shelf caching plugins (LiteSpeed, for example), the site never had performance issues - despite running on a cheap shared host and seeing an ever-increasing visitor count.

So why rewrite the site again? It ain’t broke - why “fix” it?

Friction.

WordPress is generally geared towards a WYSIWYG editing experience, where most users are writing their content directly within the platform and changing the UX via drag-and-drop widget editors and configuration pages.

This suited me well initially, but as I gained experience as a software developer my workflow for authoring content changed considerably - e.g., instead of writing in a rich text editor (like Word, Notion, or WordPress’s WYSIWYG browser-based editor), I now prefer to stay within my IDE and write in Markdown. Because my use-case no longer aligned with what WordPress was offering, this led to increased “friction” in a number of ways. To summarize: to go from idea, to written and published post, started involving enough additional steps and annoyances that it was a major contributor to my drop in posting.

This by itself was honestly enough of a reason to rewrite the site with a framework that would streamline the process of publishing Markdown, but additionally switching from WordPress to Astro would have the following benefits:

• Type-safety:
  • YAML “frontmatter” in Markdown can be parsed, validated, and used to auto-generate static typings
  • Whereas type-safety with a WordPress backend can feel kinda half-baked (PHP doesn’t have the best support for expressive types), with Astro I can have my entire site built in strongly-typed TypeScript.
• Simplified tech stack, with smoother dev experience:
  • It is totally possible to run WordPress locally - even more so nowadays with Docker and other tools - but whereas WordPress requires PHP + MySQL and an actual runtime, Astro can statically build the entire site with a single command ran within a Nodejs environment
• No backups to worry about:
  • The markdown content is the database, controlled via git, and there is no MySQL tables to need to maintain and backup.
  • With a single command I can now backup both my site (UX + static builder) and the content, into a single compressed tarball, with git history included.
• Increased Cybersecurity:
  • WordPress has a rocky relationship with safety, but to be fair to WordPress, mostly from 3rd party plugins that users install. Since I will be using Astro to statically generate the site, I don’t have to worry about “runtime” vulnerabilities in the same way - however, it is important to note that you could still have supply chain vulnerabilities with a static generator.

How the Rewrite Went

Although there were some rough edges around the rewrite from WordPress to Astro - mostly due to a learning curve with the internals of Astro and its content layer - for the most part the transition went smoothly. There is still a good deal of legacy code that I would like to clean up - e.g. little bits of CSS and JS that have survived multiple site transitions and could be improved - but overall I’m much happier with where things are at now.

To recap - the site now operates as a single monorepo, with the content as markdown and the site UX being statically built via Astro + Svelte. No more PHP, no more WordPress plugins to maintain, no more MySQL, and no more “runtime” to maintain.

To publish a new post, my process is now streamlined to:

1. Write the post in markdown (how I was already doing it)
2. git commit & git push
3. DONE! GitHub CI will build the site with my changes and push it live (via Netlify, as the host / CDN)

Thoughts

Motivating:

The power of reducing friction

One “truism” in life that I have found especially applicable to myself is that the more friction is involved with the steps to complete a task, the less likely one is to be able to build and maintain executing it as a habit. E.g., it is easier to commit to reading a chapter every day if you keep your book near where you are most frequently - rather than if you have to go fetch and retrieve the book from across your living space each day.

This fundamental truth is the basis behind lots of different habit-building “tips”, but is one of those things that is too easy to lose sight of.

Simple is better

For code in particular, I stand strong by my belief that (in most cases) simple is better than complex. That’s not to say that you can eliminate complexity in a codebase, but I do believe you should let it influence your architecture decisions. That is part of why I was so excited to be able to transition my UX over to using Svelte - I’ve written before about how I think Svelte beats every other UX framework for its approach to complexity.

Owning your own work feels good

The satisfaction I get from building something, turning an idea to solve a problem into an actual solution that I built, is why I got into software development in the first place.

Web has come so far!

This is me nerding out, but I am constantly enthused by just how far web technologies have come. Not just for UX, but also for DX - being able to rewrite some of my old CSS to use newer nesting syntax felt so good.

Demotivating:

AI Slop and Shouting into the void

The biggest demotivating factor when working on my site and putting “content” out there on the web, is this feeling of shouting into the void, or perhaps more aptly, dropping a grain of sand in the ocean. Mostly thanks to the explosion of AI slop and Google’s loosening grasp on intelligent search rankings, the likelihood of something anyone writes online getting read and digested has dropped dramatically 😔

To combat my melancholia around this concept, I try to remind myself that the flipside of this phenomenon is that - for many - careful curation of original human-centered content has actually become more important than ever. I know that for myself at least this is true - I have put more effort into pruning my subscriptions and supporting actual artists and original content creators out there.

Intellectual Property (IP) Theft

The second grim effect of the rise of “AI” on web content, is that even IF you create original content that has enough value to be useful to people, it is more likely than ever that it will straight up be stolen and then regurgitated but with attribution to you stripped.

What is even more depressing is that this isn’t a handful of small bad actors doing this that could be more easily thwarted - it is Google and other behemoths doing it under the guise of “legitimate” products (e.g. Google Search, ChatGPT, etc.). Good luck trying to copyright strike or sue Google!

Not to say that there has been zero legal pushback - see “Google’s AI summaries are stealing traffic, publisher of Rolling Stone, Variety says in lawsuit”.

For those not aware - what I’m talking about is that Google and other large services that offer interactive “AI” tools have been scraping web sites, extracting content, stripping and reprocessing it, and then showing it to users either without attribution entirely, or in a way that the net effect is the user never actually visits the original content source (the website it was pulled from).

Coincidentally, this effectively means that Google et al. get all the benefit and revenue from that content, while the original creator gets nothing.

Good summary: The Register: How Google profits even as its AI summaries reduce website ad link clicks

This has further cemented my belief a huge part, if not the majority of generative AI usage, is all about IP theft / IP laundering and a wealth transfer to the top - the shenanigans that these giant corporations are pulling are the exact same type of things that they themselves would punish individuals for doing if it threatened their business model.

I’ll stop my ranting now - I’m probably going to put out a separate post that goes a bit deeper into my thoughts about the use of generative AI at some point soon.