Prefer Blessed Ecosystems
Throughout my time as a software developer, I’ve noticed a pattern with the language and framework ecosystems that I tend to enjoy working with most; they generally operate as “blessed” ecosystems.
What is Blessed?
When I say “blessed”, I’m referring to two properties that these ecosystems possess:
- The components are explicitly designed to work together.
- The components are designed so that they can be swapped out for alternatives.
In essence, the creators of the primary component(s) of these ecosystems have explicitly “blessed” other components as being a good default choice.
Examples of Blessed Ecosystems
My favorite example of a blessed ecosystem is the Django Project. The project consists of a web framework that is meant to handle everything, including: database access, templating, authentication, and administrative tools. And while many of the components you need to build a web application are “batteries included”, you can often swap them out if they aren’t suiting your needs.
Not finding the Django Template Language flexible or fast enough? Swap it out for Jinja2 instead. Unhappy with making your users create another account? Swap the User model implementation to use OAuth instead.
These components have been abstracted enough such that one can safely swap them out and expect the rest of the ecosystem to behave just fine. The Django Admin doesn’t have a problem if you decide to use Jinja for rendering your templates, for example.
Another instance of a blessed ecosystem in the frontend framework world is VueJS. Vue is maintained as a set of quite a few different packages, all designed to work well together, which can be swapped out if necessary.
Unhappy with how Vuex does state management? Swap in MobX or Redux. Unhappy with the way Vue Router handles transitions? Swap in Page.js. Vue even has a blessed set of testing utils that will take you pretty far.
Why Prefer Blessed Ecosystems?
There are a few reasons why I tend towards blessed ecosystems, why I think they are a great choice for new projects, and why I wish more ecosystems would adopt a blessed model.
It should not come as a surprise that blessed ecosystems tend to work together better than the alternative. By my own definition, a blessed ecosystem has components that have been designed to work together. This means that they are likely tested together to ensure they work. Since these components are designed to be swappable, they also tend to be more modular and isolated. A common consequence of this modularity is simplicity, specifically the kind that Rich Hickey describes in his talk Simple Made Easy. These components tend not to be too intertwined with other parts of the ecosystem.
In some cases, blessed ecosystems ensure that a set of projects get the required funding and attention, by consolidating maintainership. Vue-router and Vuex are maintained by the same group that maintains Vue itself, which means they’re not likely to become unmaintained or to lack available resources to fix issues. This consolidated maintainership also means that these projects can get the benefits of having the same code standards and processes for accepting changes. This makes it easier for others to contribute.
In these ecosystems, the blessed components are often either the defaults, or the recommended defaults in documentation. This results in a large set of users using this particular configuration of components. Most Vue users use Vuex for state management and Vue Router for routing. This means that when dealing with bugs, or searching for an answer on Stack Overflow, you’re more likely to find a useful result than if you were trying to figure out why a particular view library isn’t playing nicely with a given routing library.
Lastly, I think the biggest reason to prefer a blessed ecosystem is that it allows you to defer making many decisions until you really need to and likely have a better understanding of what trade-offs to make. When starting a new project, it can be paralyzing to have to answer questions like, “What state management library should we use? Or what templating library should we use?” Often, you won’t even have the necessary information up front to make a very informed decision. Will you be rendering templates that have to transform many objects for display and will be hot paths? That’s probably not a question you can answer until your project is fairly far along.
If you choose to work in a blessed ecosystem, when you do discover the characteristics of your application and its data, you will be able to swap out components that don’t satisfy your needs.
Golden Path?
One of my favorite posts about technology choices is Charity Major’s SOFTWARE SPRAWL, THE GOLDEN PATH, AND SCALING TEAMS WITH AGENCY. If you haven’t read it go check it out. In it, she outlines how to manage the complexity of multiple programming language ecosystems/tools while still maintaining developer agency. Her proposal is that an engineering organization should create a recommended list of default components, called the Golden Path, and commit to fully supporting those components. Individual teams may choose to deviate but they must support those deviations on their own.
Choosing a Blessed Ecosystem is like already having a Golden Path laid out for you. No need to worry about the unsupported interactions of disparate components; the ecosystem has committed to ensuring that they are fully supported.
I hope that more ecosystems see the value in providing a blessed set of options to their users and I encourage them to move in this direction.
