Declarative vs Imperative Programming: Which one is better? 🤔

Written on 01/03/2025 by David J. Allen

The more programming I do, the more I realize that creating systems can be tough. I've never really given it much thought why though until I took some time out to finally create this site (which still needs a makeover btw). Anyways, one thing I noticed right away (and from doing NextJS tutorials) was that building the web interface was much easier and faster especially over just using plain Javascript. I also noticed that the way I typically write code is different from how sysem administrators write code.

Let me explain.

Declaritive: Building the UI for This Website

Usually, I write code that describes how something should be done where as sys admins write code that do things. I think that difference is probably rooted in (bash) scripting which I usually try to avoid when possible. Scripting involves using pre-built tools and calling them do things, like processing JSON output with jq. This would be declarative programming.

Now, when the tools are great, declarative programming is just absolutely fanatastic. And, that's the joy I realized I was having creating the web site's UI with tailwind CSS (with a couple of hiccups). I thought it was ironic at first because I absolutely dispise CSS, and there's nothing anyone could ever say to convince me otherwise ever. But, I never understood why other than getting super pissed at trying to align a <div>. I think not having to define the classes myself alleviated maybe 80% of the pain I was having with CSS.

However, that other 20% made me feel as if tailwind wasn't quite answer although it gets close. I think some of the other React libraries and frameworks help here, like MUI, but others can be an absolute mess to work with which brings me to my experience trying to get this blog how I want it.

Imperative: Building a Service for This Blog

If I had used a static site generator like hugo, making this blog would have been trivial. However, I wanted to have more control over how the blog was constructed. Still, I thought putting the pieces together would have been as simple as a loading a markdown file and passing it to a React component and maybe load a few plugins...but that would've been too easy! No...instead I ended up having such a bad time trying to integrate remark plugins that I started to write a backend that does most of the work in Go.

That brings me to the how the blog is being built. Because I got fed up with how crappy plugin integration is, I'm now taking matters into my own hands by saying, "This should not be this difficult." In my mind, I have a clear vision of how the blog should work, and it is dead simple. I shouldn't have to struggle for days or read a bunch of tutorials to just convert markdown to HTML with a little bit of extra formatting. Instead, I want to be able to conjure up a post like this:

in --> service
service --> out

[!NOTE] The code block above should be rendered mermaidjs. It probably isn't display correctly at the moment.

Creating a service lets me have A LOT of control over the rendered content and let's me build different frontend's on top. But, having that control means that I have to invest more time into it's design and it won't be tested throughly or reliable starting out. I think I'll eventually have a dedicated blog post about it, but that's for another day.