Starter Kits: Making the case

Keith Strickland
Geek Culture
Published in
6 min readDec 27, 2021

I’ve long been a proponent of learning as much as possible about the technologies I’m currently using. In order to facilitate that goal, I’ve found it useful to put together a starter kit for that technology. As the I learn more, I keep adding features that I think will be useful to have when starting a new application.

So, what is a starter kit? Just so we’re speaking the same language I define a starter kit as:

A repository or application that provides a way to spin up a new functional application in a very short amount of time that includes some useful features.

Over the years I’ve created many starter kits for many different technologies: Lotus Notes/Domino, Backbone, Marionette, React, Angular, node/express and probably others. Some have been more useful than others but they all provided a way to learn that particular technology and a playground of sorts to try out ideas.

Benefits

The obvious benefit of a starter kit is the ability to create a new application from the starter kit and be up and running in a matter of minutes. This removes the need to get all the boilerplate in place, creates base features and fast tracks environment setup so you can actually start creating, which is the part we all love about this industry.

We also get the features we added right off the bat. This prevents copy/pasting or re-implementing something from a different project. By maintaining the starter kit and adding new features as we learn more, this alone can justify the time of creation and maintenance.

A starter kit will provide a place to try new things. If you have an idea for building a caching service or a dynamic loading spinner, global error handling or whatever, an instance of your starter kit is the perfect place for this experimentation. Once you’re happy with the implementation, add it to the starter kit. This keeps the code fresh and makes your starter kit more useful in the future.

It’s a great place to keep thoughts, ideas, lessons learned, etc. This benefit is not only for you. If you share the starter kit with your team or peers they also get to learn the lessons and use your efforts in their projects. Better yet if you can get them to contribute to the starter kit.

If you’re a content creator, it provides a place to flesh out article/video ideas. Most of the code I provide in my articles on medium start out in a starter kit of some kind. Simply because I can get a working environment up and running in a very short amount of time.

Depending on the technology, a starter-kit is a great place to store common components, utilities, style sheets, scss mixins and functions all in a single place.

Disadvantages

A starter kit does have it’s disadvantages as well. The biggest is if it’s not maintained. Due to the fast pace of the JavaScript world, it can quickly fall behind. Some effort must to be provided to keep it up to date before it falls so far behind it’s just not worth upgrading. At this point, the starter kit is pretty much useless.

Another disadvantage is that technology can die. I was in the Lotus Notes/Domino world for a very long time. The starter kit I developed was used for years. However, Lotus Notes stopped being used in the corporate world and that starter kit was no longer used or needed. While we did get our money’s worth out of it, our recent additions were never used. We had also developed other starter kits in different technologies for communicating with Lotus Notes/Domino. When Lotus Notes died, while those other starter kits were still kind-of relevant going forward we had to remove the Lotus Notes communication portions of the starter kit.

One of the tedious disadvantages is having to remove unused or un-needed features from the starter kit. In the example I laid out above, communication with Lotus Notes/Domino was the reason behind one of our Node/Express starter kits. While some of the tools and features we had built into that starter kit are still useful today, the Lotus Notes features are not. We had to remove those features without breaking the whole thing.

Thing to consider

When developing your starter kit, you’ll want to take a few things into consideration:

  • Keep it generic — Try not to include your opinions on UI libraries, styles, etc. You want this thing to be useful in a wide variety of circumstances. If you decide to use say the Angular Material UI component library. What happens if you need it for a project that wants to use say Bootstrap or something else instead.
  • Keep everything reusable — Try to make your features as reusable as possible. Maybe you’re not starting a project from scratch but still want a logging infrastructure from your starter kit. Try not to tie that feature so tightly into the starter kit so it’s easy to implement elsewhere.
  • Document it — While you may understand everything right now, what about in 6 months or a year? Document everything you can and if relevant your reasoning around the feature. Include readme files in directories for complex implementations
  • Make it easy to remove features — While a lot of features are handy, sometimes they’re not needed or are just a hassle. Ensure you can easily remove that feature without breaking other things.
  • Don’t get carried away — It’s easy to get carried away making all kinds of pages, demos and component libraries. Resist this urge! It’s more stuff you’ll just have to remove when you want to use the starter kit.
  • Give credit where credit is due. If pieces of your starter kit come from something you found online that isn’t yours, be sure to include a link to the original. Doing this ensures a documentation link to how to use the original. It’s also just courteous to do so.
  • Keep it useful — Try to include things that will be useful in a new application. Do not include experiments, failed implementations or things that may be seen as clutter when you want to use the starter kit.
  • Test it — Ensure unit tests are present and passing and maintain those tests. Test the usage as you add new features to ensure you don’t break existing features.

Tools of the trade

You’ve developed your starter kit but now, how do you provide an easy means of distributing or using your efforts? Of course it will reside in a repository, but you have some of the following choices in distribution. Some of these choices will require you put some thought into the structure of the starter kit to accommodate the nuances of the distribution technology.

  • Cloning the repository: While this is a relevant means of distribution, it does make it easy to inadvertently add or remove things from the starter kit with an errant push.
  • Github Templates: Github allows you to define a repository as a template. I’ve found this is one of the better ways to use a starter kit. It removes the disadvantages of cloning.
  • NPM: This is an excellent way to share apis, tools, etc. But a starter kit? This is where some thought will need to be put into the structure of your starter kit. The main concern here is that the instance of the starter kit will reside in node_modules instead of the root src directory. So figure out how it will be used and if that use case is more trouble than it’s worth.

Conclusion

Hopefully I’ve shown that starter kits have their place in your tool box. They can be handy as long as they are maintained. Also, starter kits are a great learning tool. They let you learn a technology at your own pace and you end up with something useful.

Below I have linked some of my starter kits and others I have found over the years. Looking at other starter kits is an excellent source of ideas and can teach you some valuable lessons in whatever framework or technology you’re attempting to learn.

Until next time…. Happy coding!

--

--

Keith Strickland
Geek Culture

I am a software engineer who has been addressing corporate software needs for 20 years using multiple technologies and techniques.