At Bitovi, we work with React on lots of client projects, and we like its straightforward API and using JSX for templates. Redux is common in the React community, and we know it’s not the right solution for every project.

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.

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.

In this tutorial, we will migrate a CanJS app to CanJS 3 using can-migrate, a CLI codebase refactoring tool that automates a large portion of the work required to upgrade a 2.x codebase to CanJS 3.

In our previous post, we talked about how to improve an app’s performance and user experience by incrementally updating our app’s UI as we received a stream of data from our API. Our example app was built on the Fetch API and can-ndjson-stream to get a ReadableStream of NDJSON and render the stream in our app.