I completely agree with this post that there is churn fatigue. Part of that is in libraries, but an even bigger part of it is in the tooling that people use to build JavaScript applications.
It's easy to see all of these new things flying by, combined with changes to JavaScript itself, and feel completely overwhelmed. To be honest, over the past two years, even as a maintainer of Ember, I have experienced very serious hype fatigue.
This is a large part of the reason behind Ember's philosophy of finding and implementing strategies for stability without stagnation. On the one hand, people (including us) are tired of the constant barrage of new tools and techniques. On the other hand, it would be terrible to get beaten by a competitor that discovered a wonderfully productive new solution. The Ember team has spent the last few years honing a process for dealing with these conflicting desires.
That process involves:
* six-week release cycles, so every new change is incremental and adds value on its own
* canary, beta, and release channels (just like browsers), so that people will more appetite for churn can help test out features, and get them stable by the time they ship as part of a final release
* SemVer, so upgrading across final releases is relatively painless and the biggest part of our community can take advantage of the improvements as they roll out
* having each member of the core team build apps that we care about and maintain, so that we can feel the competing costs of maintenance and keeping pace with the latest and greatest first hand
The core ideas come from shipping browsers, which have had to deal with requirements of very strong stability with an increasing desire to "go fast". The pace of new browser features has been so good, in fact, that they have been used as an argument in favor of completely breaking things and starting over.
Ironically, the browser instead shows us that if we want to avoid stagnation, we are going to have to have strategies for bringing people along. Stability without stagnation is not a paradox; it's a recipe for success.
(we talked a lot more about the nitty-gritty technical details in the previously discussed Ember 2.0 RFC: https://github.com/emberjs/rfcs/pull/15)
It's easy to see all of these new things flying by, combined with changes to JavaScript itself, and feel completely overwhelmed. To be honest, over the past two years, even as a maintainer of Ember, I have experienced very serious hype fatigue.
This is a large part of the reason behind Ember's philosophy of finding and implementing strategies for stability without stagnation. On the one hand, people (including us) are tired of the constant barrage of new tools and techniques. On the other hand, it would be terrible to get beaten by a competitor that discovered a wonderfully productive new solution. The Ember team has spent the last few years honing a process for dealing with these conflicting desires.
That process involves:
* six-week release cycles, so every new change is incremental and adds value on its own
* canary, beta, and release channels (just like browsers), so that people will more appetite for churn can help test out features, and get them stable by the time they ship as part of a final release
* SemVer, so upgrading across final releases is relatively painless and the biggest part of our community can take advantage of the improvements as they roll out
* having each member of the core team build apps that we care about and maintain, so that we can feel the competing costs of maintenance and keeping pace with the latest and greatest first hand
The core ideas come from shipping browsers, which have had to deal with requirements of very strong stability with an increasing desire to "go fast". The pace of new browser features has been so good, in fact, that they have been used as an argument in favor of completely breaking things and starting over.
Ironically, the browser instead shows us that if we want to avoid stagnation, we are going to have to have strategies for bringing people along. Stability without stagnation is not a paradox; it's a recipe for success.
(we talked a lot more about the nitty-gritty technical details in the previously discussed Ember 2.0 RFC: https://github.com/emberjs/rfcs/pull/15)