Starting a blog with a developer mindset in 2019

In a previous post, I talked about my motivation for starting this blog.

But starting and maintaining a blog is a lot of hard work. First, you have to decide what to name it, then figure out how to set it up and host it, what content management system would work for you along with their features and pricing, is there a theme to the blog - whether you’d prefer to stick to some particular subject or be more open - something that imparts a sense of “character” or “identity” to the blog. And all this before you’ve got the chance to put serious thought into how you’re actually going to keep posting regularly - creating the actual content for your blog - which may just turn out to be the most difficult part!

When I ventured out, I knew I wanted to focus on a “developer blog”, so at least I knew the theme I was going after. I thought that was a great starting point.

Soon enough surely, hesitation kicked in.

Should I go for some hosted platform solution, or have something I can call more of my own? Do I deploy a ready out-of-the-box framework, or start building something from scratch? Or probably something in between? What is a trusted and affordable service provider that I could use for hosting my content? How much should I even begin with as a spending budget for this? Will I get locked-in on some service provider or technology choices for storing my content? How difficult could it be to move my content to somewhere else if I wanted to in the future? How will I ever even manage to get an actual audience for this blog?

I had all the liberty to feel giddy looking at the number of options available and the choices to make.

Baby steps.

Eventually, I decided to go down the path of setting up my own domain and creating my blog as a static website generated using Gatsby and hosted on Netlify.

In my first blog post, I did add a light-hearted remark around “all the cool kids using Gatsby these days”. And who doesn’t want to be cool, yeah? In fairness though, my decision to follow this path was more deeply deliberated than just getting on the hype train. So far, it seems to have been a good decision.

Now I am not going to make this article a “Yet another post on how to set up your blog with Gatsby and Netlify”. There are a great, many, resources, all, over, the, web on that already!

What I will focus on instead, is sharing my rationale towards making that decision.

I’m certain there are people out there embarking upon the path of setting up their blog and in the process going through some of the same dilemmas that I did. This is an attempt at being of some help if I could.

⚠️ Content below is bespoke and opinionated.

Here’s are the things that mattered to me, which I’m going to talk about today.

• Self-owned content rather than hosted at somebody else’s mercy whom I’m probably paying again to serve content that I created.
• Creative freedom and customizability to establish identity and individuality.
• Technical freedom to do more under the same roof.
• Statically built website for speed, frugality and agility. With possible eco-friendliness sprinkled on top.
• Transparency, portability and version control of content
• The subliminal developer experience
• A pretext to learn new things and apply them
• But why Gatsby? Why Gatsby at all?
• So, is it all sunshine and rainbows?

Self-owned content rather than hosted at somebody else’s mercy whom I’m probably paying again to serve content that I created.

I prefer to fully own the content I create, published at my discretion and not subject to some third-party hosted platform’s changing policies and potential censorship. This is why I didn’t go for hosted solutions like Medium or even Wordpress.com.

Not to mention the associated service’s usage pricing models that would be involved: while they all start free, the way it typically goes is that as you get bigger, or desire to be more customizable or feature-rich, it’s common to charge you for various ancillary and auxiliary services. I’m not at all saying that’s unjustified considering all the useful services they may provide, rather something that I felt wasn’t worthwhile for me. At least not as the canonical place to put my content.

Creative freedom and customizability to establish identity and individuality.

The other reason I didn’t prefer hosted solutions is simply the fact that they all practically provide canned, run-of-the-mill experiences to everyone who signs up on their platform. There’s a lot of merit in the standardization of things. As someone who lives off building things for the web, you can understand probably where and why my sentiments lie in the context of standardizing things, but in this case, I’d clearly choose to move away at the behest of creative freedom.

A blog, portfolio (or both?) that I’ve put out there should reflect what I feel defines me, is unique or just the way I want my audience to experience it. I should be able to design an user experience with the look-n-feel and feature-sets that I want, free from limitations imposed by a certain service or platform that I’m using.

As a developer, being able to have that free reign is critical to me. I can afford to invest some time and effort to have things built exactly to my will. Not being able to do so today or tomorrow is not a chip I’m willing to bargain.

Some platforms like Wordpress do offer you decent degrees of flexibility, but still, come with a lot of opinions and often fall short of what you want to achieve, either ending up with practical limitations or simply becoming too cost prohibitive and making you lose interest and give up. Some other platforms are even worse. Forget customizing too much, Medium for one has stopped providing some basic capabilities to build your identity such as associating a custom domain name with your blog. They used to do that at a steep price at some point, but have stopped now altogether. I have my personal speculations (a gun to the head of your potential future from easily moving off their platform?), but that’s a conversation for another day.

Technical freedom to do more under the same roof.

Continuing with the above, it’s not just limited to the blogging aspect of it. I can imagine a future where I’d probably want to create custom content - say experiments, projects or labs that I’d want to set up, talk about and share. Being able to host and serve all of that together under the same roof would be great.

There are some counter-arguments to this. In theory, I could still host my blog on some chosen software platform, put that behind a domain and wire other enhancements hosted elsewhere through sub-domains and such… or even some hypothetical under-the-hood rewrites, as unlikely as sounds. I imagine it’s a decision probably best deferred. Right now, the best I could do is make the least assumptions and keep as many potential pathways open as I can. Cheers to Occam’s Razor!

Statically built website for speed, frugality and agility. With possible eco-friendliness sprinkled on top.

This is a popular school of thought now, and in my opinion for a lot of good reasons. At the moment, I have been bought into the general philosophy behind JAMStack. As a frontend engineer, I can’t help but confess that it has quite effortlessly grown close to my heart. I love the way how it naturally bakes in the segregation of data and view so easily into its core architectural principles and then enables a myriad of use-cases from the simplest to adequately complex web applications to be cheaply hosted, effectively scaled and swiftly modified to ever-changing needs, the 2010s-generation definition of “static websites”. Yes, that involves ample amount of client-side rendering, but we’ll try not to pick up pitchforks with the performance aspects of that just yet.

The use-case of a blog flows in surprisingly well into this paradigm. The actual content of your typical blog is predominantly going to be crafted manually rather than being dynamically generated. It’s not going to change on the fly from one reader visiting your blog to another. So are the pages that are rendered with the content, which can be crafted fairly well at build time rather than runtime.

There are definitely conceivable things could give your content an edge when done at runtime (say more complex features or optimizations around ranking content or a dynamically computed “top posts this week”), but most of these would be second or third order capabilities for a personal blog rather than the core experience, and if some sweet spot exists between dynamic generation vs. something that is fully statically built, it would fairly strongly lean towards being sufficiently achievable through intermittent build-time computations in a controlled environment as opposed to runtime calculations that need to be done every time a page is requested.

Avoid doing at runtime what you can do at design time. With that in mind, it doesn’t make a lot of sense to introduce an added dependency on a server requiring computational power to serve predominantly non-dynamic content, and on account of that, consume some energy. Again scaling those servers with more computational power with added traffic. More servers, more energy, more money. For a lot of apparent scenarios, it may not seem that big of a deal, but it feels quite wasteful to me.

With pre-built static components though, it becomes a fairly trivial matter in comparison of having to dumbly serve some static files without any complex computational needs, which can then be done by cheap, distributed and easily scalable CDNs. You can practically eliminate the time and energy required to compute things on the server over and over again and consequentially the need to even commission those servers, and at the same time be more easily available and closer to your audience with this static content that can be readily cached and distributed geographically.

Both of these factors are going to improve your user experience by making the pages of your blog load much faster.

Without the need for provisioning servers with custom requirements and computational demand, these CDNs come really cheap and easily scale by replicating themselves at various points of presence, which lets them respond to your audience with your content much faster. Imagine the pain you’d have had to go through if you realised you needed to deploy custom servers that compute your content, all across major geographical areas!

Case in point, Netlify provides services that are practically free of cost for hosting static websites to until a quite sufficiently large amount of traffic per month. If I were to go beyond that consumption for my blog, I’d take it as a happy problem to have, and pay for the additional amount gladly! On top of that it provides a bunch of other great things that I love, and I’m pretty sure you will too. Not an affiliate promotion. Just a happy customer.

Security-wise, data isolation is not something that I was gunning for here. That’s by design, where the usual idea of a blog and it’s content is to be available publicly, as was for me. Data integrity, however, is surely important, and something we can work out given a CDN service provider of choice, as well as make sure that we’re doing some basic things such as serving content over HTTPS from the CDN edge servers. These are pretty elemental at this point and commonly supported by these service providers out-of-the-box. For more scrupulous aspects of security, that would sadly be beside the point of this article. And the fact that you’re probably not looking for a security expert in me right now. So I’ll stop digressing more on that front.

Transparency, portability and version control of content

Imagine owning a blog with a large number of articles, thoughts, and posts that you’ve accrued over time with your blood, sweat and tears. Now imagine all that gone in a poof due to a database corruption with your blog hosting service provider. It makes my skin crawl.

Hosting service providers will generally make sure to host your content well. But bad things happen. Systems fail. And while the scenario of an acute loss of system availability may seem a little bit contrived in context, considering any well-meaning and sensible hosting service provider will intend to (and hopefully) make certain of data redundancy, at the end of the day it’s a matter of placed trust and the perceived transparency.

Of course, the whole damn world is running on the cloud. But not every cloud thunders the same, so to speak. My goal here is not to be paranoid but I’d prefer to avoid losing any sleep over this. It’s not possible for me to know upfront how well-built a certain xyz-affordable-hosting-dot-com might be, or to be more appropriate, the quality of service it’ll always provide me.

So rather than going down the route of hiring some service provider who spins a server and a rents out some storage space in some hosted database somewhere where it becomes hard for me to easily keep track of all the content that I create and keep changing; or don’t even know how complicated it is going to be to port all of that content in and out of that system, I’d bias towards keeping things simple and stick to mechanisms I already trust to not make my life harder later.

For a blog which is again mostly text-based serialized documents in some form and could be easily stored directly as files, rather than relying on some database-service backed system that stores my content and then potentially requires some additional processes (and SLAs) to push, pull, transform or migrate data, I’d stick to a simpler way where the content I create is retained directly natively in the form I created them. As files. In some repository. In the same way that I’m used to storing and maintaining with a lot of reliability, the source code that I write, again, with my blood, sweat and tears. This also gets me all the benefits of a well-defined, robust, and battle-tested version-control system.

I’m talking about authoring in Markdown and maintaining them on Github (or GitLab or BitBucket if you will).

I know I don’t have to sell Markdown here. In developer-town, it’s quite the universally accepted format for authoring documents. So I’m probably safe to not worry about potential pains of migration later if I wanted to move all my content from one system to another. If in future my destination system needs to understand something other than Markdown, it’s still probably possible that there’s some transpiler available somewhere, if this so-called destination system is popular enough.

What’s truly great about this approach is now the content that I create is apparent to me, how it’s stored and transformed. It’s simple. They are files. I can hit a simple file copy and replicate them as many times as I want, back them up when I want, where I want, extremely easily (probably along with git repo itself to preserve the versioning and it’s history). Given that, the chances of me losing it all is really, really slim. It does come with placing a lot of trust on Github really. That’s fair. Also acceptable. And definitely a much better bet than xyz-affordable-hosting-dot-com.

The subliminal developer experience

In continuation of the above theme, this is where I risk pissing off some great proponents of separation of concerns who also believe that all things should be black or white.

For me as a developer, maintaining my blog is not too different from maintaining any other software project. In fact, it’s both.

In the developer ecosystem, we’ve historically built great systems and tooling to make sure things work the way they are supposed to, and that building and maintaining those things are a good experience.

So it naturally feels great to impart a lot of those benefits to creating and maintaining content as well.

Does that mean we store all of that code and content intertwined together? The initial thought of “coupling together” code and content sounds repulsive. Where is the abstraction, the modularity, the single-responsibility, the separation of concerns? Oh, and the risk of non-generalization of software? Heresy!

But sacrificing those qualities is not exactly what we’re doing here. What I merely suggest is a bit more nuanced mechanism for the specific use-case of creating and maintaining a personal blog (or even one managed by a small group of people).

I know a typical personal blog is not going to blow out of proportions, neither does it have to be overly generalized and potentially over-engineered. So I’d start with a simple setup that I can easily maintain. Starting with one repository that contains everything is perfectly fine. In fact, having it all together pleasantly surprised me with some unexpected advantages!

It’s one single portable setup, and I don’t have to run around between multiple workplaces, editor instances or software tools which are essentially contributing to the same thing.

I get to use the same toolchain to construct my content that I use to construct my code. Writing content feels like writing code. When I write a new article, I get the benefits of pushing a version-controlled commit to a Github repository, a hook that automatically kicks off a build in Netlify when this commit is pushed and then deploys it to their CDN that hosts my website, through continuous deployment. It’s a simple workflow, predictable and hassle-free. It makes me happy.

The best part is, when I create content and see it in action, I get the benefit of getting instant feedback on code components that I build for rendering the pages of this blog off that bare-bone content, and if I need to tweak something, it’s a fairly simple matter of modifying the code in a file that I also have open in another tab in my code editor. I am my own principal customer, and it’s one of the best things that can ever happen to a software developer when building a product. I call this the “firewire of feedback” (yes, I just came up with that now).

It’s important to realise that building a blog - both the content and the software around publishing it - is not a one-before-the-other process. They happen in tandem. The day you first set up your blog; and every day henceforth. So as long as scale permits, and your source is designed to not complicate a separation if ever required later at a later point in time, it’s perfectly fine to have had put them all together now.

At a superficial level, this can sound unconventional, but not all conventional wisdom of the time is necessarily right. I’m tempted to draw a parallel to the kind of backlash that us “separatists” may have helped contribute to when React came along and said it’s probably better to put HTML, CSS and JS code all together in one single file for a component. But I will not. It’s a bit too extreme. And not very analogous. But hey, we all know how that went. It’s correct if it’s done for the right reasons. I guess the way to look at it is re-evaluating over time whether the concerns, in fact, are really so separate.

A pretext to learn new things and apply them

So far I talked about the means and the motive. Let’s also talk about an opportunity in the overall equation.

This is perhaps the simplest reasoning of all.

The idea of setting up your own blog, building features and being able to customize it to your heart’s content does come with a great appeal to a developer who’s excited to play around with new things.

It’s of course always possible to go about hacking around with new stuff anyway, but in my experience, more often than not such endeavours end up remaining temporal and isolated efforts, which without a structured motive to build, maintain or scale something do not really lead to any sustained excitement or a meaningful learning experience.

It just works better when you have a real-world target use-case in action. So why lose a great opportunity to capitalize on that?

Great software is built on well-executed principles of abstraction. I don’t love abstractions I don’t understand. I do love them later, but only after I’ve broken into, dissected and then put ‘em all back together. I love to work with primitives. I like to understand how the tools in my belt work… to a sufficient degree. This is not to say that I’d prefer to reinvent the laws of motion before using them to solve a problem, but I am just one of those people who can’t stay away long from getting their hands dirty messing around with the nitty-gritties. This habit is not always necessarily your friend. Sometimes, it just likes to manifest as a compulsive disorder.

So here’s me simply cashing in on that to learn a new concept or just a new way to look at a problem. Or a framework, tool or language. Fiddling with them. Applying them in context to real-world problems.

It enriches you.

But why Gatsby? Why Gatsby at all?

"I wasn't actually in love, but I felt a sort of tender curiosity."

— F. Scott Fitzgerald, The Great Gatsby

Come on. I could not just pass on the opportunity to not do that.

But putting all the flare and drama aside, it really boils down to one dead simple fact. For me, Gatsby simply seemed to fit the bill really well.

I wanted a static site generator, but in a language or toolchain that I was comfortable sticking around with for a while. And Gatsby seemed to meet that, along with having been a massive success in the JavaScript frontend community.

It seemed-thought through and well-designed, with a lot of the right bells and whistles to make you productive, yet comfortably distant in its own way to not breathe down your neck with too many opinions on how to build websites.

It came built using technologies I was convinced I would be interested to learn and play around with: React, GraphQL. And a thoroughly justified rationale at that.

It seemed to come with an architecture that consisted of well-defined component lifecycles and somewhat neutrally opinionated hooks for common and useful things, making it immensely pluggable and strangely powerful at the same time.

It did not come with a prescription on what to build and how to build it. It was not a blogging solution. But it was a solution using which blogs, and thankfully much more, could be so elegantly built.

It had great community support, and the right pedigree to build websites that are genuinely fast, that’s not just focused on the final end user experience (UX), but also the developer experience (DX). Powered with Webpack it supported out-of-the-box hot-reloads, came with a lot of sensible defaults, a large number of plugins and a rich set of guidelines, starter packs and inspiration to get you up and kickin’ sooner than you’d believe.

And great support for easily building Progressive Web Apps (PWA). The direction things are going, it’s probably fallible today to underestimate the power of PWAs. But I believe it’s even more dangerous to underestimate the power of a simple, elegant and well-built tool to facilitate building PWAs.

Maybe I did actually fall in love with it. Or maybe not. But rest assured I was convincingly sold enough to go ahead and give it a real try.

The documentation could improve though in being a bit more detailed, I suppose.

There’s a detailed chart of what Gatsby can and can not do in comparison to other popular static site generators such as Jekyll or content management systems (CMS) like Wordpress or site-builders if you’re interested.

So, is it all sunshine and rainbows?

Surely not. But it’s more sunny than gloomy though. In a good way.

At the end of it all, Gatsby is still a static site generator, although deceivingly powerful.

There are some features that a more “true” and powerful CMS with more dynamically rendered content and features could provide that I could wish for. Remember that dynamically computed “top posts this week” example I had in a section above?

However, having the pros and cons weighed and the cost-benefit measured, the return on investment of using Gatsby and Netlify in building and maintaining a blog has been so far simply amazing! And I would not have it in any other way! Well… if the software industry has taught me something, never say never. But today is not that day.

Also, not having gone the route of using an existing hosted platform that has baked in capabilities to distribute your content within its community, gather audience and cross-pollinate, it definitely becomes a much harder challenge to figure out to gather a sustained audience. To be honest, it’s one of the biggest things to solve for a successful blog. And I have not solved that yet.

There are definitely a bunch of ways and ideas though. For one, I could always cross-post keeping my own blog site as the canonical, to start seeding some community presence and feedback. It’s a common pattern, and I believe many communities, such as Dev.to, encourage that (I absolutely adore what Dev.to is and stands for). Over time, I definitely plan to add more capabilities to my blog to subscribe readers, share, and engage them.

It takes some time to create good content, surface that (be it on dedicated communities or search engines) and start getting people to talk over it. It’s not easy, but neither unthinkable. Existing on a hosted platform does not solve that magically as well. It’s hard and a much longer battle, but people have done that time and again. And it’s a topic that I’ll want to talk about in more detail as well in future sometime.

---

So that’s about it today.

Phew, that was one long article! And I genuinely appreciate you if you’ve read all through it and come this far!

Feedback and opinions welcome!