< Back

New Static Site Generator, Who 'Dis?

January 5, 2020 14:03   ~4  minutes

The other day I took a look at this site and, realizing it hasn't been touched in a while, decided to update it. Unfortnately I was using a Gatsby template at the time, as opposed to a theme which caused updating to be much more of a pain than I thought it would be so I impulsivley scratched everything (thankful for backups!) and started over.

Since I was up and running pretty quickly last time I didn't think updating would be an issue but as I got into things, I scratched everything again and went with a different static-site generator all together- react-static. I'm glad I did!

Although I still appreciate Gatsby for what it is and is capabilities, the main issues I had with it stemmed from it being a bit over-kill for my needs.

Hear me out

My needs for this site are minimal at best: use react, render markdown. That's it. I know where my markdown is located and how I want them rendered and with react-static I was able to declare my posts with a single line and even format it with a custom renderer thanks to Dan Webb's awesome tool jdown.

const data = await jdown('content/posts', { renderer });

That's it. There's an initial template for rendering each entry but other than that, I was able to hit the ground running without the need of setting up addional queries with GraphQL. Which brings me to my next point.


I can admit I'm not the best at GraphQL. I can get the job done, seeing as the previous iteration used it and I've used it with other projects, however I felt it was unnecessary for the time being and I didn't feel need to use this site as a project to refresh my knowledge (I can always build something else ;)).

I simply wanted it updated, deployed, and out of the way so I can move on to other todo items, and going the GraphQL route would have taken much longer because my curiosity and need to understand it all each step of the way would have gotten the best of me. I'm all for learning through hands on experiences, but in this case I opted to trade refreshing skills for speed which was an even trade off I'd say since I'm not completely in the dark when it comes to GraphQL. In fact, I would it was a better trade off because not only was I up and runner faster, I was lighter.

Light as a Feather

I think another selling point react-static had that made me migrate over was the lack of dependencies! Right now, looking simultaneously at my package.json files, the gatsby implementation of this site required about 17 gatsby specific dependencies... react-static requires about 5.

Regardless, it reaffirmed my appreciation for minimal overhead and simple setups where I'm able to add as needed as opposed to getting everything and utilizing only a small portion.

In theory, I shouldn't have the same issues I faced updating last time and if I do, hopefully it's easier to track down and resolve.

Nothing's Perfect

I can't say everything was great during the migration, and I definitely still ran into some issues along the way.

At times I was taking shots in the dark because the documentation was either not there since the project is still young compared to other generators, or I just had to restart the dev server that was left running longer than it should have.

Those are the only two issues I've had and I'm planning on contributing to the project because of how much I enjoyed working with it- and you know how much I love technical writing ;).


You can find further details on how react-static works in Tanner Linsley's medium article. Everyone's use case is different and like I said before, my requirements for this site were minimal. I'm sure there are cases where Gatsby would be better suited but I'm glad I didn't go with it this time around.

Besides, it's always refreshing to try something new.

Brian Ngobidi

Hi! I'm Brian Ngobidi, a technology consultant and security researcher based in New York. Thanks for reading!