In programming, choosing a reliable and unexciting technology stack can have numerous advantages. Recently, someone asked me for advice on creating their own blog platform using Angular for the frontend. My response may have been poorly received, but it remains an important point: if your goal is to create a successful blog, it’s best to use an off-the-shelf solution rather than spending valuable time developing and tweaking the infrastructure.

The technology you choose should not be a hindrance; rather, it should seamlessly support your content creation process. Otherwise, you’ll find yourself spending more time on the blog platform itself (which, let’s be honest, no one else really cares about) instead of focusing on producing high-quality content. The infrastructure behind your blog is not what your audience is interested in.

Consider, for example, making a video. Are you going to build your own YouTube clone capable of handling 100 million simultaneous visitors? This is comparable to aspiring game developers who get stuck building complex physics engines instead of actually finishing their games.

Personally, I use Hugo, a static site generator. One of the main reasons I find it appealing is its focus on blogging and markdown. Hugo is deliberately designed to be dull; its templating language is unremarkable. In fact, it’s so uneventful that I often find myself falling asleep when I have to make tweaks. But that’s precisely why I love it.

Hugo’s top feature is its speed, which is largely thanks to its underlying technology, Go. Although speed may not seem exciting, it is crucial for an efficient blogging platform.

You might be tempted by the fancy and shiny allure of tools like Gatsby, but in my opinion, they shift the focus away from the actual outcome. React and GraphQL might be thrilling for developers, but excessive excitement can lead to overcomplication. A prime example is Redux and its “time travel” demo, which, although an amusing feature, isn’t necessarily vital for everyday coding. Some developers end up needlessly complicating their applications just for the sake of using a trendy technology.

Let’s take prefetching as an example. Is it truly necessary for a static site that is already inherently fast? Are your blog visitors specifically requesting prefetching? Moreover, what risks and drawbacks does it entail?

It’s important to remember Murphy’s Law: “Anything that can go wrong will go wrong.” I once spoke to someone who started a blog using Gatsby, only to discover that they hadn’t enabled server-side rendering as they had mistakenly believed. This mistake rendered their blog nearly invisible to search engines like Google. Although search engines can sometimes execute JavaScript, it’s best to stick to reliable server-side rendering when it comes to blogging.

On an average blog, you can expect an average of 1.1 to 1.2 page views per user. This means that the majority of users will visit your site, likely through search engine referrals, skim the content, and move on. Do you truly need to prefetch all your links? Why waste valuable resources and data?

While I appreciate Gatsby as a tool for creating websites and apps, I believe that for a simple blog, you probably won’t need 80% of its capabilities. Opt for a simpler tool specifically designed for blogging instead. And under no circumstances should you attempt to build your own blogging platform.

This principle also applies to more complex applications. Should you stick with the technology you’ve been using for the past decade, or should you jump on the bandwagon of a hot new technology that everyone is talking about? Should you choose Rails or Elixir? TypeScript or Reason? C, Go, or Rust?

Countless hours are lost when we collectively switch from old libraries to new ones and from outdated frameworks to shiny new ones. Think about jQuery, Backbone, and Ember, along with all the other frameworks that came before or after them. Consider the transition from AngularJS to Angular. Reflect on the “NoSQL revolution” that tempted us away from MySQL toward fancier and more flexible database systems. Yet, despite all the hype, SQL remains a robust and enduring choice.

“Just use MySQL, the boring tech revolution is here.” This insightful remark was made by Marty Weiner, Reddit CTO, in 2016. It’s important to recognize that many industry-standard tools are created by colossal companies like Google and Facebook, and while their needs align with those of small teams or individual developers on occasion, it’s crucial to question whether their needs accurately reflect your own or if they are merely driven by peer pressure, hype, or clever marketing tactics.

Consider whether your goals can be effectively achieved using plain JavaScript and the DOM APIs. Is it truly necessary to rewrite your entire application using React and spend days wrestling with Webpack? Sometimes, opting for the less glamorous DOM APIs can result in a faster and more efficient application. While others in the engineering community might dismiss this approach as a messy choice, you might surprise them by delivering a product in a fraction of the time with significantly improved performance.

Ultimately, the key is to understand the pitfalls of your chosen technology stack. It’s easy to imagine that alternative platforms are perfect, but reality is often different. The devil lies in the details—details that you may have mastered over years of investing in a stack that now seems mundane to you. As an engineer, you may enjoy challenges and the opportunity to learn new things, and there’s nothing wrong with that.

Don’t be afraid to experiment and create side projects. However, when it comes to critical platforms (such as your blog), opting for the boring yet reliable technologies is usually the smarter choice. Embracing this concept is an essential part of becoming a senior developer.

Tags: programming, technology stack, blogging, infrastructure, Hugo, Gatsby, React, GraphQL, server-side rendering, performance, static site generator