In This Series: Stable and innovative code bases
CanJS’s mission is to make sure the code you write today is valuable years in the future. This starts by ensuring CanJS is thriving despite constantly changing techniques and technology. We’ve learned a lot managing CanJS’s 10 year old codebase. This is the first of many (possibly 7!) articles highlighting techniques the DoneJS core team uses to keep CanJS stable and innovative within a constantly changing technology landscape. While CanJS’s code base is used as an example, these techniques apply to any code base.
Specifically, these articles will cover:
- The current technology environment and how it has shaped CanJS's priorities and goals.
- The tactics used to achieve CanJS's goals including:
- Put everything in its own repository and package.
- Remove side effects.
- Coping with stateful code.
- Integrate with other libraries. (article pending)
- Using codmods to transition to new APIs. (article pending)
This article covers the current technology environment and how it has shaped CanJS's priorities and goals. Look out for the remaining articles in the coming days.
Environment
You have to know where you are to know how to move.
Surrounded by more popular frameworks backed by much bigger companies, CanJS finds itself in a particularly challenging environment. Like an invasive species, CanJS has to be willing to do something different to succeed. This means prioritizing one thing over another.
Most popular open source libraries prioritize the following:
1. EASE OF USE
2. Innovation
3. code stability
This makes a lot of sense. Most open source libraries are community driven. They need people to use the library to eventually be able to contribute back. Making it easy to solve common problems is a great way to attract new users and fuel the success and popularity of a project.
Innovation is also important if the project is going to survive in our constantly changing technology environment.
While every open source developer cares about stability, most are willing to sacrifice it to the gods of usability or innovation.
For much of CanJS's existence, these priorities were never clearly defined. We cared about some priorities sometimes and others priorities other times. It left us poorly defined, and unable to fill a particular niche in the larger JS community.
For CanJS 3.0, we did some soul searching and arrived at our new priorities, which flip traditional priorities:
1. CODE STABILITY
2. Innovation
3. ease of use
We also arrived at our new mission statement:
CanJS's mission is to minimize the cost of building and maintaining JavaScript applications by balancing innovation and stability, helping developers transcend a changing technology landscape.
Our first priority is code stability. Code stability means that the code users of CanJS write will stay valuable as long as possible.
Ease of use is not our first priority. We will continue to make our APIs as friendly as possible, but not if it conflicts with code stability or innovation.
We are focusing on the long-term users of CanJS, hopefully creating a rewarding experience that will have them keep coming back.
We’re not sure this strategy will work. We will see. But for now, please read on to see what we're doing to create a more stable and innovative code base:
- Put everything in its own repository and package.
- Remove side effects.
- Coping with stateful code.
- Make libraries useful to others. (article pending)
- Using codmods to transition to new APIs. (article pending)
Previous Post