Building this website
A personal website can take many forms and serve many different purposes. With that said, what I decided I wanted when I started building this website was:
- A place to write about stuff I find interesting
- A website I could refer to on my CV, detailing some of my work and my experiences
- An opportunity to build and deploy an entire website from scratch, testing some technologies along the way
Nothing too complex or fancy, I’ll admit (this is a static website after all), but this was my first serious foray into web development.
Web dev paralysis
I think the main reason I hadn’t delved deeply into web development before is decision paralysis. When it comes to building websites, there are so many options to choose from it can become overwhelming. Should I use Angular? React? What about Astro or Eleventy, since I am building a static website? Even then, how should I style my website? I’ve used Bootstrap before, maybe I should go with that? But what about Tailwind? Or I could go with one of the hundreds of Tailwind components library, like daisyUI?
Then there are the thousands upon thousands of npm packages out there, each designed to fill a specific niche. And inevitably, you will stumble upon the exact one you need - days after you’ve solved the issue it addresses by employing some unwieldy and hacky methods.
Finally, even after all of this, there is the question of hosting, and the plethora of options available.
Facing this avalanche of choices, most people looking to build a website for fun (i.e. without client requirements) will probably look into what the most marketable technologies are, and end up with Angular or React. Of course, for a static website, this is a bit overkill, but at least it is still a learning opportunity.
I personally have tried a lot of web frameworks, but I keep coming back to Svelte and SvelteKit. The boilerplate involved in writing React or Angular apps feels daunting to me. Svelte feels like one of the cleanest, simplest way to build relatively complex websites, and that simplicity translates well into less intricate projects (such as this one). I am not sure if this will stay the same with Svelte 5 and its runes, but I am hopeful.
Alright, so now we have Svelte as a UI framework, and SvelteKit as a development framework. For styling purposes, I decided to go with Tailwind. I find that I prefer using classes rather than raw CSS, and while component libraries are great for maintaining a cohesive look throughout a website, they don’t offer much freedom.
Markdown madness
With some frameworks figured out, it’s time to get to actually building the website. A simple home page, a navbar, an about page… but what about the actual meat of the website, the blog posts/articles?
At the start of this project, I figured I would simply write everything in HTML directly. After all, with Tailwind’s Typography plugin, it’s quick and easy to style HTML into something that’s easy to read.
After a bit of writing however, I found the process of writing blog posts in HTML very cumbersome. I decided to go looking for some alternatives, and that’s when I stumbled upon this wonderful blog post by Josh Collinsworth.
This post describes every step needed to build a static Markdown blog with SvelteKit, which is exactly my use case. If you’re looking for more details or step-by-step instructions, I urge you to give Josh’s post a read, but the gist of it is that we’re using mdsvex, which allows us to use Svelte components in Markdown, or Markdown in Svelte.
With it, and a bit of configuration things like this are possible in a Svelte file:
<script>
import MarkdownArticle from './my-article.md';
</script>
<article class="prose prose-slate-gray lg:prose-xl">
<MarkdownArticle />
</article>
And we can also do this in markdown:
<script>
import MyComponent from '$lib/components/MyComponent.svelte';
</script>
# Markdown title
<MyComponent />
Some more markdown!
Best of all, this works great with the Tailwind Typography mentioned above!
Of course, there is plenty more to be done, but with the basics figured out, all the website needs is some fleshing out, which can be done in due time.
Happy hosting
The last step is to actually host and deploy our website somewhere. Once again, there are plenty of available options here, but I decided to take Josh Collinsworth’s advice and go with Netlify.
Having never hosted anything online before, I was pleasantly surprised at how easy it was: open up a Netlify account, register a domain, link a GitHub repo to it, and done! Now every time I push some code to my main branch, the website is automatically rebuilt and redeployed for me. Obviously hosting a more robust application might be more involved, but this is plenty enough for my needs.
All’s well that ends well
This has been my first post, and hopefully the start of a long series. I don’t intend for this to be a good resource or anything, but more of a glimpse into my reasoning as I went about building this website. Honestly, this is more for me than for you, reader. I hope to one day come back to this and marvel at how much I’ve improved and how much I’ve learned since this was first published.