In my opinion, the complexity comes from a backwards understanding of design patterns: a lot of frameworks codify patterns into classes that you as a developer are supposed to use to write your code in a prescriptive way. I think this is somewhat arrogant and unfortunate because the framework basically assumes the responsibility of figuring out what is the best design pattern for the job, and developers get brain damaged thinking whatever the framework chose is the one-true-way(tm).
With that being said, non-native APIs do have their place: virtual DOM templating engines have no browser equivalent and there have been a few articles here on HN explaining lately explaining how they help with dynamic UIs without adding a ton of cognitive load. Promises have been shown to be a powerful tool to handle asynchronous data flows , but the native equivalent (ES6 Promises) are still in draft stages.
With my own framework Mithril ( http://lhorie.github.io/mithril ), I'm trying to get out of the developer's way as much as possible, by providing these kinds of tools and allowing them to implement the right design patterns for the job with just simple and plain javascript.