This blog post was originally posted on medium.com/micah-walter-studio. I work with Micah Walter Studio on various web application projects for museums around the world.
Part 1: How a starter kit keeps your app healthy
A strong building depends on a strong foundation. Before you build a single wall, you need posts and joists and concrete slabs. A robust web application has similar needs. Before you serve a single webpage, you need server technologies and software libraries and a framework to tie it all together. In both of these fields, a good foundation should be simple and rock solid. It should just work™. You don’t usually want to spend time designing the foundation, you just want to get straight to the meat of your project.
Fortunately for software developers, building such a foundation is a mostly solved problem. There are many free open source projects to choose from. These app foundations come in all shapes and sizes: some are minimal, some are feature rich; some are just a recipe of tools with documentation; some are what we call “boilerplate” templates, which are like prefabricated copies of a generic foundation. But for a robust application, I think the best choice is a starter kit.
Many developers have advocated the use of starter kits in recent years. A starter kit gives you more than just boilerplate code to copy — it gives you a fully maintained project which compiles and configures boilerplate code for you. In other words, if a boilerplate is like a prefabricated foundation, then a starter kit is like a mini factory which builds your foundation. This might seem like a small difference at first. But it can be a big difference over time. Because years later, this starter kit “factory” can also rebuild your foundation, keeping it healthy and up to date.
A web app foundation is made up of many open source components. After time, these components will get old and will need updates. For example, some components might need security patches. Updating a single component is easy. But, updating one component might cause compatibility issues with other components. And this might require further updates as well as configuration changes. This can be a big headache. The New York Times developer team illustrates this well in a blog post about their starter kit.
“Typically, you’ll need the following configurations: transpiler, server build, client build, test, style and script linting and several scripts to tie those tools together. To make matters worse, configuration can lead to a complicated matrix of dependencies, where one minor change can cause bugs with cryptic errors and waste hours of time spent on debugging and searching the internet.”
Yikes! Now, if you used a boilerplate to start your project, you will have to make all these updates manually, carefully testing each piece. Whereas, if you used a starter kit, most of that legwork is handled for you by the open source community. This is a huge win. Why should everyone struggle independently to fix their own copies of the same foundation? A starter kit project lets us all work together to maintain one shared “foundation factory”.
Okay, I’ll admit I might be over simplifying just a little; updating your starter kit might take more than one-click. But, I have found it to be drastically easier than updating by hand. I recently merged in a starter kit update with hundreds of lines of code updates and it ran without a hitch. With just a few tweaks, my application ran exactly the same on top, and my new foundation ran smoothly underneath.
Part 2: Finding a starter kit that checks all the boxes
Now that I’ve (hopefully) convinced you to use a starter kit, let me help you choose one. Here are some reviews of the various options I recently evaluated. I’ll focus specifically on kits for web apps using node, express, and react.
My search for the ideal starter kit had some pretty stringent goals. I needed it to be all of these things:
note: non-developers can gloss over this list
- Well maintained.
- Well documented and simple to understand.
- Feature complete but not a framework: The separation between starter kit and application should be fairly clear. The starter kit should build, test, and serve the app. The app should do the rest.
- Extensible. The configuration should be customizable.
- Performant, with support for static builds and/or universal rendering: It should either compile a static build of everything, or it should support universal rendering — i.e. application code should run on the server or the client browser. Ideally, it should do both when it can. It should be accessible, performant, and SEO friendly. (It should work without javascript, load quickly, and use canonical urls tied to proper html.)
- It should keep supporting my application for years.
- It should come with a simple manual.
- It should just work™. It should focus only on the foundation, and it should stay out of my application’s way.
- It should let me customize little things if I need to.
- It should make my app load fast for everyone, and then dynamically update as needed.
TLDR: Your web app probably wants a starter kit.
I hope this post illustrated the benefits of using a great starter kit: It will save you time and keep your app healthy. And it gives you out-of-the-box benefits like static rendering and/or universal rendering, which are critical for web accessibility, SEO, and performance.
I’m looking forward to make use of these starter kits on many future projects. I plan to use React-Static on projects like presentational websites which are well suited to static pages. I plan to use Razzle or KYT on more dynamic websites — for example, search-based websites with unique urls for each search filter combination. It’s important to me that these projects stay active and well maintained over the years. So I hope to contribute pull requests and I will gravitate towards projects with active communities.
My time spent exploring these starter kits has been well spent, and I hope others can also benefit from discovering these great foundations for your web applications.
