Strategies for Creating a Web Application Starter Kit
There are so many decisions to be made. Which frontend framework do I use? Should I lint my code? How is the project going to be built? How am I going to fetch my data? What architecture should I be incorporating? What about testing?
If you find that you are constantly making these decisions and have a high volume of projects with the same set of technologies and tools, a starter kit could be a worthy investment.
Benefits of a Starter Kit
A starter kit provides users a base of technologies and tools that they can expand to fit the needs of the project. It allows for projects to be created consistently and efficiently since they already have the technologies that will most likely be integrated and an example of how to use them. It is quick to setup and allows for developers to hit the ground running.
Here are some of the benefits that come with using a starter kit:
- Consistency across all project code bases
- Quickly start a new project without the initial burden of setup
- Quality coding standards are automatically enforced
- The starter kit can be used as an example or platform for testing new potentially integrated technologies
- The starter kit can be consistently updated to reflect current needs
Sounds great, right? We thought that a starter kit was something our organization should be utilizing so I was given the opportunity to create our organization’s starter kit. I found the entire process to be both challenging and fulfilling. From my experience, I was able to identify general strategies to keep in mind when creating a starter kit.
Things to Keep in Mind
A starter kit is unique
On the outset of creating our organization’s starter kit, I wasn’t sure where to begin. I was familiar with several popular starter kits, such as ReactBoilerplate and React Slingshot, but I wasn’t convinced that any of them would fit our organization’s specific needs.
That’s when I realized that starter kits are not “one size fits all.”
There are many great starter kits available online that may fit your needs, but I think creating your own starter kit using what you’ve seen as inspiration is the best option. It allows your starter kit to have its own special ingredients making it unique while still incorporating flavors you like from others. You also have the opportunity to really understand every piece of technology being incorporated.
Be opinionated, but not too opinionated
“There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare
How generic should my starter kit be? Should it include an architecture or should it be flexible? Should I add a testing framework or allow users of the starter kit to decide that?
These are a few of the questions that ran through my head while creating our starter kit that I continually found difficult to answer. I found that I wasn’t sure how opinionated a starter kit should be, but I did know that if the starter kit was too generic, it wouldn’t be useful since there would still be too many decisions for the developer to make. I also knew that if the starter kit was too opinionated, there wouldn’t be flexibility to leverage new technologies and the starter kit wouldn’t be usable for a wide enough set of potential projects.
So what was the answer to the question of opinion in a starter kit?
The important thing is striking the right balance between having a strong opinion and being transparent.
For example, if your plan is to incorporate testing into all of your projects (which it should), definitely add a testing framework, but if you think server side rendering may only be used once in a while, don’t include it in the starter kit. By including the technologies that will always be used, the starter kit becomes more opinionated and you avoid the need to remake simple decisions which each new project and by not including technologies that only apply to a specific use case, the starter kit remains flexible to live and grow.
Collaborate with your team
“You can’t have great software without a great team, and most software teams behave like dysfunctional families.” – Jim McCarthy
If you’re creating a starter kit for your organization, make sure to collaborate with your team. The starter kit will be more useful and easily adopted if everyone is involved in the planning process and there is clear agreement on the technologies chosen. Sure, there may be some friction between team members when deciding ESLint configuration settings or application folder structure, but it’s all a part of the process and it only yields a starter kit that is a better fit for the entire team.
Don’t try to include every technology out there
“Simplicity is prerequisite for reliability” – Edsger Dijkstra
Everybody wants their app to be state-of-the-art. You want to include every useful technology possible because the more the merrier right? Not quite. It sounds like it’d be great to use every technology possible that can help your application, but it’s important to remember that simplicity is important in a starter kit. If you include every technology possible, it could lead to a garbled mess and the starter kit may be too complex for some users. In addition, it may become a necessity to remove several technologies every time the starter kit is used.
Be diligent in choosing technologies
“Think twice, code once.” – Waseem Latif
React vs. Angular vs. Ember for frontend frameworks, Jest vs. Mocha for testing frameworks, TypeScript vs. Flow for static type checking, ESLint vs. some other linting tool for linting, Webpack vs. Browserify for bundling, Relay vs. Apollo for GraphQL client.
As you can see, there is a decision to be made with each piece of technology included in a starter kit. Choosing the best technology for your starter kit is not an easy task and I would suggest being diligent in each choice. Choosing a technology based on npm downloads and popularity may work out, but
Really doing your research and choosing the technologies that make sense in terms of your starter kit’s goals is better for the long term.
For example, our starter kit uses Jest/Enzyme as our testing framework since we selected React as our frontend framework. Try different options out, research trends and usage, and see which technologies will most likely advance in the direction you want to follow. You’ll be able to make better choices for your starter kit while learning a lot in the process.
Include an example application
Who doesn’t love examples? Including an example application in your starter kit showing how to leverage each technology is helpful for all. Advanced users or starter kit maintainers (more on that in a bit) can use the example application as a base point for testing new or alternative technologies that could be adopted into the starter kit while new users can use the example application to learn the technologies already included. It can also be used to make sure that there aren’t breaking changes when upgrading dependencies to the newest versions. Our starter kit includes a simple Todo Application as a demo.
Upgrade and maintain
“Most of the effort in the software business goes into the maintenance of code that already exists.” – Wietse Venema
If you’re interested in creating your own starter kit, feel free to use ours as inspiration. Fork our repo on Github https://github.com/codazen/react-relay-graphql-starter-kit
Feel like I’m missing anything? Please comment below!
— Posted by Kasey Muketake, Software Engineer
About the Author
Kasey studied Computer Science and Electrical & Computer Engineering at Oregon State University before earning a Master’s Degree in Computer Science at UC Irvine.
He currently works for Codazen as a software engineer. He enjoys snowboarding, playing music, and watching sports.