This is the third time I've cleared my directory and started over from scratch on a new version of my blog. In 2012, this site was written in PHP and some jQuery. In late 2016 I started creating a new version written on top of the Django framework, but it didn't stick. In 2019, I wrote a new site in React focused on a portfolio and blogging, but I still struggled to get around to writing posts. Why? Because in my setup writing content was tedious and bogged down by using a framework far more powerful than necessary.

Blogging is About Content

My problem was that writing my content was inconvenient and too involved with code. I want to get the code out of the way so I can focus on the content. I spent more time with Webpack, file loaders, and weird Babel errors than coming up with ideas for posts. In an effort to keep my site simple, I didn't use a CMS and wrote my posts within React components. This was clearly a mistake, as I was inherently having to write code for each post. I did some research and discovered that MDX could be a good option to focus more on writing content than writing code, but I was beginning to think that even using React was more than I needed for this site.

I'm writing code so I don't have to write code when I write content.

However, my research into MDX showed me that I did need to formalize the separation between my content and my code, and I am a huge fan of writing content in Markdown. In this context I don't consider writing Markdown for content a form of coding, even though I can write code in Markdown files. Switching to Markdown provides me a more maintainable way to write content that isn't tied to a specific framework either. With my track record of rewriting my site, I may very well choose a new framework soon--and with my content in Markdown I can much more easily switch between frameworks.

Now that I was adament on separating my content from my structure, I was primed to be introduced to the wonderful world of static site generators.

Turning it Up to Eleventy

I knew that React based static site generators existed like Gatsby, but I was interested in dialing things back a bit and returning to good 'ole HTML for writing a website.

My good friend Ben Myers gave me an excellent primer into Eleventy and his motivations for rewriting his personal website from React to Eleventy. He could not have explained it any better--by the end of our Zoom chat, I was sold. My biggest pain points with my old blog written in React were:

• React feeling over-engineered for my use case of a personal site and blog
• Annoying Webpack configuration requirements, like file loaders just to use static content
• Poor SEO without setting up Server Side Rendering

If you want to learn more about Ben's motivations for moving to Eleventy, I highly recommend reading his post about it here.

One of the biggest benefits of static site generation is reducing the amount of Javascript sent to the client compared to a single page app. Oddly enough, wasn't one of my top concerns, but switching to a static site generator like Eleventy that includes zero Javascript by default is a nice bonus for site performance. I will be adding a small bit of Javascript in for my custom, anonymous and privacy conscious analytics API.

Additionally, I chose to keep the design exactly the same--a first test for potential future rewrites. Generally, it went really well! I managed to keep the exact same design with only a little bit of pain because of my use of Tailwind CSS. Love it or hate it, I was able to quickly set it up with Eleventy using this helpful article on CSS Tricks . The biggest snag I had is that separating my content and structure meant my Markdown gets generated into classless HTML, so that's simple <p> tags and <h2> tags. While great semantically, this makes it a tad bit more inconvenient to use Tailwind. What I did to solve this for now was moving templated styles for my blog posts into a CSS file looking like this:

.blog p {
    @apply py-3 text-lg font-montserrat leading-loose; 
}

Now that I'm writing a good chunk of my CSS in actual CSS files again, I'm considering going back to writing the raw CSS myself. However, I do feel like Tailwind still gives me value, so for now it stays.

In the future, it is possible to set up different kinds of custom Markdown to HTML conversion in the Eleventy config Javascript file, where I could inject my Tailwind utility classes, but it seemed more straightforward to organize my CSS in the example above.

Reducing Burden of Hosting

Next, came the hosting. I have a managed Kubernetes cluster hosted at Digital Ocean that I've used to learn about container orchestration and configuring a semi-production level cloud environment. Within this cluster I hosted Docker containers for my website, something that is complete overkill for hosting most front end sites these days. The container was literally just Nginx serving my static site assets. I knew I could do better--and for free.

Netlify is all the rage these days and I decided to give it a shot. Setting up was mostly a breeze, especially since I didn't even have to link my Git repo (yet) in order to test it out--all I had to do was drag and drop my built site folder and within seconds it was deployed. Directing my morganwesemann.com domain to the Netlify site took a bit of time to take effect, likely due to time-to-live (TTL) at the DNS level. I'm not quite taking advantage of Netlify's global content delivery network (CDN) due to some DNS quirks, though. My domain nameservers still point to Digital Ocean, and I've redirected my root domain to Netlify's load balancer. I'll likely switch over fully to Netlify's DNS to get the extra perks of their CDN, and then set up some subdomain domain records to go to Digital Ocean, since my kubernetes cluster is accessed through a load balancer anyway.

Netlify does have a cool server-side site analytics offering for $9/month which adds no Javascript to your code, but at the moment I am sticking to just their free plan.

Wrapping Up

In this effort to simplify writing content on my blog I've discovered I that shouldn't put the cart before the horse. Right now, I want a blog to publish posts on, that's it. I don't need to manage state, I don't need to handle users, or even comments for that matter--start a discussion with me on Twitter instead. I can think of things I may want in the far future but nothing right now or in the near-future that React offers me.

I like React, but I'm not tied to it. My blog is a place to publish and share content, which doesn't need the bells, whistles, and overhead of React. One day I may decide I need a feature best implemented in React or another framework, and at that time I have a few options:

• Add React (or some other framework) support to my Eleventy setup
• Create a separate site within this domain to handle the required feature, if able
• Rewrite the site in something like Next.js or React-Static with MDX integrations and leveraging my existing Markdown

With that all in mind, time will tell if this latest rewrite gets me to be more active on this blog!