The State of JavaScript in 2015

Are you referring to the point about dedicated libraries? If so, I agree, but it doesn't solve the problem. We have *so many* libraries out there already that are tailor-made for a specific purpose, but what if you want to combine those libraries? What if I want to use selector library Foo with CSS polyfill Bar? I either have to fork the project and use Foo, or I have to use whatever library Bar chose. That brings us back to the Reddit comment that was quoted earlier in the article, you're at the mercy of whomever wrote that small library to either provide extensions points for you to swap out a dependency (good luck), or you have to go with a larger framework so that you don't have to worry about the author not updating their library because obscure dependency X just had a breaking change. We had that with jQuery, in a way. jQuery has enough built-in that you can write any number of purposeful libraries against it, each filling some niche. But since jQuery is a big monolithic project, doesn't that make it bad? I'm not convinced that's true. Just because Angular screwed the pooch and a whole bunch of work now has an end-of-life slated for 2015, doesn't mean that every large-ish framework will do the same. So what I propose is that we need more medium-sized libraries. We need some of these small projects to graduate. They need unit tests and documentation and pull requests from the community to fix bugs. This provides support so you can be confident in choosing the library, but not be at the whim of a corporation with things other than your productivity and happiness in mind. I'd love to hear what some others have to say on this article. @gingemonster @buzzdecafe @graham_kane @awgreenarrow08

So I wonder then if the safe bet, regardless of the size of the MV* framework, is the one that allows you to separate your application code from the plumbing code as much as possible. I get the feeling that that isn't quite as easy to do in Angular 1.x as some people would like, and that may be what makes the shift to 2.0 that much more painful. This is mainly from what I've picked up in the blogosphere and my limited foray into Angular, I could be completely off base. However, bringing up Durandal again, I found that most of my plumbing code, while specific to knockout (due to ko.observable), was mainly limited to plumbing code. I was able to easily import my application/business logic as services into my viewmodels whenever I needed without having to put much thought into it at all. Nothing in my services depended on any part of Durandal.