A coding blog was one of my first web development projects, which I created because I enjoy writing and wanted to help other people with coding problems that I had solved.

First try

The first iteration of Array of Sunshine was built with create-react-app, which, little did I know, had been depreciated for years. However, I had started learning React and wanted to put my skills to use.

While it functioned okay (mostly), it wasn't achieving its goals. Yes, you could navigate between articles instantaneously, but who would want to read all my niche content in one go? As a single-page application, it also scored poorly on performance and SEO.

The main problem, however, was that it needed to be more maintainable.

If I wrote a new article, all sorts of errors would appear, and older articles would disappear or get jumbled up. This was a disaster that prevented me from being able to write regularly - which probably wouldn't have happened if I had known how to use TypeScript.

Round two

Then, I read The Complete Career Developer's Career Guide by John Sonmez, which has an entire chapter devoted to blogs and why all developers should have a coding blog.

A blog advertises your skills 24/7/365 and is relatively easy to set up - especially if you don't code it yourself. In fact, he actively discourages engineers (especially non-web developers) from coding their own blogs.

I took a middle ground, opting for the default WordPress site but creating a custom theme, which would be an excellent front-end project.

This worked well until I installed a handful of plugins (SEO, caching, security, image optimisation), and it kept crashing every time I wanted to upload a new article.

I see these features as essentials, not extras, so it has put me off using WordPress again in the future.

Third time lucky

Fast forward a few months, and I was ready to give it a big glow-up.

I had started using Next.js and was now writing everything in TypeScript. Plus, I had finished writing an article about another book I had finished - The Secret Diaries of Miss Anne Lister - that I was desperate to publish.

Anne Lister (1791 - 1840) used a cypher in her diaries to write about her homosexuality.

Getting started

Before I got started on Version 3, I set out my goals for the site:

• Easy to publish new articles
• Code blocks with syntax highlighting and copy buttons
• Excellent SEO
• Great Lighthouse scores
• Clean and minimal design (so much web design is about appealing to other people's preferences, so it's nice to think about myself for a change!)
• Articles should be visually engaging, with lots of images.

My starting point was this gorgeously minimal Next.js template by Vercel, which I adore in terms of aesthetics, though it needed a lot of customisation to do what I set out to do.

Removing MDX

The template supported MDX, which, when I discovered the language, was very excited about - probably quite influenced by their slick marketing site.

That only lasted about 24 hours, however, as I swiftly found many compelling reasons not to use it - the main one being that it prevents type checking and can lead to all sorts of errors with links and images.

Crucially, you only find out about these once you build the site, which is annoying and violates the 'fail fast' principle.

While it makes the article file succinct, and brevity is often an asset, it doesn't make sense for a solo developer project.

Blogging in TypeScript is more verbose, but autocomplete does much of the heavy lifting and catches problems immediately.

Challenges

Updating to use the app router

It was a challenge to update the template to use the new file-based 'App' router, but I learned a lot about the configuration of a Next.js site along the way, so this was a huge positive.

Social & featured images

I wanted each article to have a featured image at the top of the page (for visual engagement), which would also be the meta image (for social engagement). This caused me a lot of trouble because I needed to understand how Next.js handles images and the purpose of the /public folder on a website.

The problem, I eventually discovered, was that I was trying to use the same image for two very different purposes.

Once I learned that images in the /public folder are served with a stable URL, and the size and format aren't altered, I thought the solution might be to duplicate the image file.

However, this didn't seem right to me because it seemed akin to breaking one of the fundamental rules of programming: Don't Repeat Yourself! However, I'm now sure this is the best solution.

Keeping a copy of the image inside /src/app allows Next to convert the image to WebP and create an src set of different sizes, allowing the user's browser to select the smallest suitable image for the device, affecting performance dramatically.

Along with several other optimisations I made, this allowed me to achieve perfect Lighthouse scores across the board.

Other metadata

Initially, I created a complicated metadata auditing system to test each page for optimum-length titles (measured in characters) and descriptions (measured in pixels).

While this could be an excellent idea for an NPM package, for this site, it was over-engineering, slowing me down considerably and detracting from my main goal (publishing articles easily).

Plus, as robust as these checks were, they wouldn't write the metadata for me, and the quality of the content itself is the important thing anyway.

After shopping around for more simple solutions, I found a Chrome extension called Detailed SEO Extension, which is simple and fast to use. It might not be as comprehensive as other options, but it's a good choice for this casual coding blog.

Creating nice code blocks

Creating a CodeBlock component was relatively easy, but I did spend a lot of time on the styling.

I'm adamant that every snippet of code should have a file name (or indicate that it's for the command line), as I find it incredibly frustrating when you can see what looks like a solution to a problem, only you have no idea where it's supposed to go.

1interface CodeBlockProps {
2	language: 'typescript' | 'html' | 'css' | 'tsx';
3	fileName: string;
4	disableLineNumbers?: boolean;
5}

To pass the Lighthouse accessibility tests, I made several customisations to the syntax highlighter theme.

While this works nicely in light mode, the dark mode colours have proved challenging to customise. This has been incredibly frustrating because it's just changing the colour of text... it shouldn't be hard!

In the future, I will create a CodeBlock component where the theme can be set with Tailwind colours, which are naturally much more expressive than hex codes.

What I learned

Focus on the bigger picture

In the future, I'll not get too fixated on things that don't matter much (e.g., perfect metadata) and instead focus my attention on the project's broader goals (making it easy to add new articles).

It's okay as long as the main metadata elements are set.

Using existing material as much as possible

Using a template was a great idea, not only because it reduced the amount of code I needed to write. The main benefit was that it has taken away a lot of anxieties over the design - especially spacing, which is so easy to screw up.

Documentation is important

If I ever release an open-source project, I am adamant that it will have AMAZING documentation.

Next steps

• Fix the code block dark theme, then add a dark mode toggle button.
• Add a newsletter. I already have a great solution using the Mailchimp API, with styled user feedback and error handling. I just need to change the style of the form to match the minimal theme of the site.
• Make some money. I'll add some advertising, plus Amazon affiliate links for all the books I mention.

Conclusion

I'm very proud of how my blog turned out, and even though the white background shows all the smudges on my computer screen, I love the design.

The best part, though, is how easy it is to publish new articles - which means I have zero excuses for not writing more regularly. I'm committed to this project and excited to keep writing more content and improving it until I retire.