I’ve been building things on the web for a long time. My very first websites — now lost on a discarded hard drive — probably predate WordPress, which was released in 2003. Along the way, I’ve tried dozens of languages, frameworks and content management systems.
Broadly speaking, there are roughly three "eras" of build tooling I can remember.
The first was the CMS era — WordPress, Movable Type, Expression Engine. We’d run on LAMP stacks, rendering pages live from a database.
The second was the static site generator era — Jekyll, Metalsmith, Middleman. We realized our websites actually didn’t have anything that varied per request, and it was more efficient to just render all the pages ahead of time.
But that’s only half the story. The proliferation of single-page apps has resulted in a way better developer experience. React’s component model is a significant improvement over the nested templates we were using before. CSS modules make it much easier to encapsulate elements. Having the entire npm ecosystem at your fingertips is incredibly convenient. And using linters to check your markup for a11y issues is just good for the web!
What if you could have the (lack of) runtime footprint from the static site generator era without giving up the tooling improvements from the single-page app era?
All of which is a long way of saying: I built a static site generator! It’s called Radish.
Let’s face it: web developers making static site generators is a bit of a meme. It’s a fun personal project until they get the crazy idea that it might become the next Jekyll. Why would this be any different?
Maybe it won’t be! But there are a couple reasons I’ve been really enjoying building sites with Radish:
Radish is Based on React
“Traditional” static site generators like Hugo — which I’ve used a lot and do really like — work with templates. You write HTML with placeholders for your data, and there might be some clunky ways to add logic like loops or conditions. Composition happens via “partials” and “shortcodes”, which are just nested templates. There’s no real encapsulation, especially when it comes to CSS.
With Radish, all your pages are just React components. You can keep logic in your JSX or extract it to helper functions to organize it. Composition is seamless: just import any other other components. You can write in MDX, which means you can even use components within your content. CSS modules come baked in; there’s no worrying whether two components accidentally share a class name.
At this point, you might be wondering why not just use something like Gatsby. I’ve used it before, and although it’s a bit too heavy for my taste, I could probably have gotten over that. But there’s actually one big difference…
Radish Has No Runtime
When you load a Gatsby site, you’re actually downloading a full React app to run in your browser. That’s fine if you’re building a big app with a lot of complicated UI interactions, but it’s overkill if you’re just making a small website.
More generally, I want Radish to help developers fall into the pit of success when building websites. I want a11y lining so I know I’m following best practices with regard to accessibility. I want a service worker so my site can work offline. I want the page to preload critical assets like fonts. And most critically, I don’t want to jump through hoops or go out of my way to enable these things.
As someone with a deep love for the web, I really like the Remix philosophy of learning a framework and learning the web platform at the same time. Radish isn’t a framework, but it tries to follow the ethos. There’s no magic — just HTML, CSS and a dash of web features that help your website be the best it can be.
If all that sounds interesting, please check out Radish! I really like it, and I hope you do too.