CanJS, for better or worse, allows a near endless variety of design choices. If you like MVC, MVVM, centralized state management, etc, you can build your app that way. Enabling this level of flexibility is difficult, especially because we don’t know what sorts of things people might want to integrate into CanJS.
In this article we will: Learn why stateful packages challenge stability See an example of a stateful package Identify CanJS’s stateful packages Provide strategies that minimize the problems with stateful packages
In this article, we will: Learn about modules with side effects Understand how CanJS removed side effects in plugins See a preview of how plugins in views might work
The first, and most important step to supporting stability and innovation within CanJS's codebase has been breaking up CanJS into individual repositories, each with its own npm package and semantic version number. In this article, we will discuss: The benefits of independent repositories. How we manage a codebase split across many repositories.
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.