Articles
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?
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
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.
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.
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.
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.
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.
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.
