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.
FYI: Yehuda and Tom talked to us about "stability without stagnation" and other philosophies behind Ember 2.0 in episode 131 of The Changelog: http://thechangelog.com/131
If the new tools and techniques were actually good, they would be enough for a while, and people wouldn't feel the need for even newer tools and techniques the next week.
This should be an obvious and automatic hype-temperer, but for some reason it isn't.
Interesting that the same problem (high churn) leads to two polarly opposite conclusions - i.e. the article suggests going with many specialized libraries, whereas Ember is on the camp of incorporating the latest and greatest into a single framework when it makes sense.
My opinion is that some types of features are better off bundled in a ready-to-go package. For example data binding and ajax almost always go together and just plopping a CDN link to Angular is a lot easier than installing NPM, setting up a file watcher and who knows what else to get React's JSX running (and you still need to go decide what you're going to use for AJAX).
Other less "core" types of features are better off as standalone libraries because their depth of usage can vary from not being used at all to requiring very domain-specific features (e.g. accounting.js is a good example of this). I don't agree with the author's premise that micro-libraries are easier to swap. I'd be very doubtful if anyone were to claim that it's trivial to convert a React codebase to Knockout, for example. You'd likely be hard-pressed to swap even things like moment.js because you probably chose the library based on it being better than its alternatives to begin with.
But having these types of features be standalone libraries does provide some benefits, e.g. being able to opt-out of a breaking release in a more granular fashion, trial-and-error-oriented development, etc.
Additionally, in this case wycat's points are highly relevant to the topic at hand; the article is about churn, and wycat talks about how he addresses that problem in the context of a JS framework.
The last time I talked on Hacker News about Ember was in the comments about Ember 2.0. Before that: months ago. Most of my recent comments have actually been about Rust, not JavaScript at all!
It can be difficult to not self-promote when you feel strongly about the utility and quality of something you work on.
And, we being somewhat to relatively smart people, can forgive the unmasked market-speak to appreciate the value of the personal experience wycats is sharing.
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)