My experience with Wisp.blog - Part 2

Thu Sep 18 2025

Enthusiastically I started writing part 3 (which was part 2 then) about my experience implementing Wisp. To me everything was clear about what I had written so far, but I of course knew the stack I was working with. So today I'd like to take some time to explain the stack I'm working with and why.

The basis

This site is built in React, on the NextJS framework. I didn't do any extensive research or make comparisons of pros/cons compared to other frameworks. It's just what I'm used to working with. For this project the goal wasn't to learn a new framework or language, but to build a blog. So trusted technology seemed the way to go.

Make it look nice

First off, I'm not a frontend developer. I know what CSS is and how to use it, but that's about it. With the same mindset as my framework choice, I picked something I'm familiar with. So I am using Tailwind for the styling.

Since I'm not a frontend developer, you might guess I'd use ShadCN to build my application, but I actually decided against it. It would save time and make my life easier. Instead I decided to also take this opportunity to get more comfortable with Tailwind myself. My workflow normally is: make it functional, pass it over to a frontend engineer. Being able to do the basics at least might save some time in the long run for both of us.

Backendless

I'd love to spend a few weeks to think up a fun backend architecture and build it. Besides being fun it would also be a colossal waste of time for a simple headless blog. The content besides the blog can be hard coded as I have nothing to place there yet.

Hard coded content?

In the previous entry I talked about my idea to implement Wisp next to the Storyblok CMS, why would I hardcode the content instead of fetching it from Storyblok? And again simplicity is the answer, this exercise is first to implement Wisp. If I put a bit of thought into that implementation it should end up as a plug-and-play feature, and use it in a Storyblok website once I need to.

Over complicating the project

One thing this project surely doesn't need to be is a Monorepo, still I decided to make one anyway. This wasn't really an architectural choice about keeping future scope increase in mind, but another fun exercise for myself. I've done research in different Monorepo tooling like NX or Turborepo, but neither fully satisfied me. So as a challenge, I wanted to implement it myself to learn how they work.