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)
This should be an obvious and automatic hype-temperer, but for some reason it isn't.
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.
That's not the tone we go for on HN.
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.
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.