Earlier last month CanJS 4.0 was released bringing a load of new features. We heard early (while 4.0 was still in prerelease, in fact), that DoneJS users wanted to upgrade. Once 4.0 was out we had to answer a tough question: do we wait on a new breaking StealJS release, add other features, or release a DoneJS 2.0 right away?

The DoneJS team has been debating for a long time on how often we should make major version releases. Slowly we have come to realize that releasing early and often is the way to go. It was an easy decision given all of the feedback we got from developers eager to check out CanJS 4.0!

That being said, we were able to squeeze a few other exciting features into this DoneJS release:

Easier setup of Continuous Integration and Continuous Deployment.
Several bug fixes for incremental rendering in done-ssr, increasing its stability.
Improved debugging of DoneJS applications with the inclusion of can-debug.

If this is your first time checking out DoneJS, try out our Quick start guide to quickly learn about DoneJS.

CanJS 4.0

The biggest driver to releasing DoneJS 2.0 now was that we wanted any developer starting a new DoneJS project to get CanJS 4.0. You can read about all of the CanJS 4.0 changes in the 4.0 release article.

On the DoneJS side we are excited about making it easier to debug applications. With that we have included can-debug in all DoneJS apps. It's imported in new applications in the app.js module:

import 'can-debug#?./is-dev';

If this syntax looks new to you, it is using steal-conditional to conditionally import can-debug only when running in dev mode. This means the module won't be included in your production build.

Improving debugging is something we are starting to work on in StealJS and done-ssr as well. The top vote in the recent community survey was for improved error messages and handling, so look for more in this space soon.

Simplified CI and Deployments

Automating testing and deployments helps to increase the efficiency of your team. Instead of taking the time to figure out how a bug got into production, continuous integration helps prevent that from ever occurring; and if it does, continuous deployment makes fixing it quick and painless. In 2.0 we've made setting up these processes much simpler in DoneJS.

Continuous Integration

DoneJS users understand the importance of testing. We've long developed testing tools such as FuncUnit and Testee, and the modlet workflow was designed with testing in mind. In DoneJS 1 we included Continuous Integration (CI) into our suite. CI takes testing one step further by ensuring that all branches pass your test suite before being accepted into the master branch.

In DoneJS 2.0 we've made setting up CI easier with the donejs-travis generator. To use simply run donejs add travis, which will get you all set up:

Deployments

DoneJS supports deploying to Heroku as the host of your server-rendered apps. In 2.0 we made this process easier with donejs-heroku. To set up simply run:

donejs add heroku

And when you’re ready to deploy push to the heroku remote:

git push heroku master

Continuous Deployment

We've also made it easier to set up Continuous Deployment (CD). Like CI, CD runs in a specialized server. Instead of running your tests, it actually deploys your application. With DoneJS this includes:

Deploying static assets to a CDN (Firebase).
Deploying the server application (used for server-side rendering) to a hosting provider (Heroku).

This is achieved with 2 more generators, donejs-travis-deploy-to-heroku and donejs-travis-deploy-to-firebase. These connect your existing Travis integration with Heroku and Firebase, giving you deployments for your static assets and your server.

Easier Upgrades

Upgrading apps from one major version of a framework to another is never going to be easy. When the framework is modular, as DoneJS is, knowing what versions of which packages to upgrade becomes even more difficult.

In DoneJS 2.0 we are adding a new command to the DoneJS CLI, donejs upgrade. Using this command will upgrade all of your packages to the most recently released DoneJS versions, and will run can-migrate to codemod your source files. After you've installed donejs@2 you can upgrade your apps with:

donejs upgrade

Incremental Rendering

Incremental rendering is a new HTTP/2-powered server rendering technique we developed as part of DoneJS 1.1 . Server-side rendering has 2 primary use cases; to provide content that search engines understand (SEO), and to help with the perceived performance of your application.

DoneJS' default server-side rendering technique provides all HTML up-front. This solves the SEO scenario but means a slightly slower first-paint for users.

Incremental rendering is like traditional client-side rendering, but with a head start. Instead of waiting for the HTML and JavaScript to reach the client, incremental rendering starts rendering on the server immediately and incrementally sends mutation instructions to the client. By the time the client's JavaScript has run, most of the page's HTML has already been rendered.

Although incremental rendering was part of DoneJS 1.1, it has gotten quite a bit better for DoneJS 2.0. We now have a Server Rendering React guide and a couple of examples apps (a DoneJS app, and a DoneJS + React app).

In done-ssr 2.0 there are several important bug fixes we've done as well. We are excited about incremental rendering as the future of our server-rendering technology and are considering making it the default in 3.0. If your team is interested in developing streaming apps, we'd love to help.