Articles

Chasen Le Hara

Help Us Improve CanJS, StealJS, and the Rest of the DoneJS Family

posted in on September 19, 2017 by Chasen Le Hara

The DoneJS team wants to hear from you. What do you love and hate about CanJS, DoneJS, and StealJS? What can the core team work on to make you grow fonder of these projects?
Justin Meyer

Coping with Stateful Code

posted in CanJS, stable-and-innovative on September 14, 2017 by Justin Meyer

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
Matthew Phillips

HTTP/2 in DoneJS

posted in HTTP/2, DoneJS on September 12, 2017 by Matthew Phillips

The DoneJS core team has been experimenting with HTTP/2 for the past several months and the outcome is strong HTTP/2 support in DoneJS! HTTP/2 contains some exciting new features that we've previously gone over in the article Utilizing HTTP2 PUSH in a Single Page Application.
Justin Meyer

Removing Side Effects - some juice isn't worth the squeeze

posted in Development, CanJS, stable-and-innovative on September 11, 2017 by Justin Meyer

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
Justin Meyer

How to Manage Code Across Many Independent Repositories

posted in CanJS, stable-and-innovative on September 7, 2017 by Justin Meyer

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.
Justin Meyer

Stable and Innovative Code Bases

posted in CanJS, stable-and-innovative on September 7, 2017 by Justin Meyer

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.
Chasen Le Hara

August 2017 DoneJS Community Update

posted in Open Source, CanJS, StealJS, DoneJS on September 6, 2017 by Chasen Le Hara

Lots of notable releases, community projects, and technical content were released in the DoneJS community last month! This post outlines some of the highlights from August 2017.
Bianca Gandolfo

Tutorial: Automate Your Upgrade to CanJS 3 with can-migrate

posted in Open Source, CanJS, javascript on August 15, 2017 by Bianca Gandolfo

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.
Adri De La Cuadra

Tutorial Part 3: Documenting a Stylesheet in a Living Style Guide

posted in Design, tutorial, style on August 10, 2017 by Adri De La Cuadra

The heart of creating a LSG is the ability to put your documentation right where it belongs: in the source code. Chances are that you are already documenting your code, which is a great opportunity to take it to the next level by using a style guide generator that can turn those comments into an organized site, letting others (and yourself from the future) know why and what has been done in the code.
Adri De La Cuadra

Tutorial Part 2: Creating Pages in a Living Style Guide

posted in Design, tutorial, style on August 10, 2017 by Adri De La Cuadra

While the bulk of your LSG documentation will come from special comments that you add to the source code, you can also create standalone pages where you can host other types of content that are not specific to the code (think of design principles, accessibility guidelines, or pull request guidelines). This gives you the advantage of centralizing your documentation in one place: your application living style guide.