There are more books, stack overflow posts, blog posts, and open source repos on the most popular libraries. This is often a very useful supplement to the official docs.
Developers building apps will hit road blocks. The decisions they make to solve their problems, will have varying degrees of elegance, readability, testability, and reusability. The most widely used and talked about framework at this point in time, is arguably Angular. The frameworks and libraries that are growing the most rapidly right now, are React and Angular 2. Ember has a fraction of the users and Backbone has been losing traction for years. Choosing a framework that has been widely adopted by the community means your team will be able to find other people who have experienced similar problems and potentially find solutions quicker and easier.
Ease of Use
Building your app with web components and ES2016 may help you get the most out of the time you spend in development, in the long run.
At times the most valuable thing is using a tool that's easy to grok. In these cases, tools such as Vue, Aurelia, and Polymer may seem the most interesting. The latest and greatest frameworks won't be around forever, and sometimes we want to convince ourselves that we can future-proof our code by adopting drafts that will possibly become specifications.
Time to first paint of content (with service workers)
React - 1004ms
Angular 1.5 - 2500ms
Angular 2 - 294ms
Ember - 414ms
Sharing code can be in the form of a hybrid app, reusing most of the same code and deploying it in a browser without the address bar. A lot of solutions build a core business of this, and bring together the UIs and deployment with Cordova. Some interesting solutions include Ionic and Ionic 2, and also Onsen UI which can be used with Angular, React, or Vue. Another way to reuse some code is to deploy to Angular Native and React Native. This will use the native device UI, but because it's not deployed in a browser the app will feel like a native app.
Take into consideration what the implementers are bringing to the table, and where they want to go.
Another very important factor will be the implementers. Find out what is their recent experience, and what do they want to learn. It could be tough getting a team of engineers excited about building an Ember app, when they've been working on React and Redux apps for some time. When we're starting greenfield we can consider all options. When we're extending an existing codebase we may think twice about the technologies we choose.
One Size Doesn't Fit All
The best solution will always combine a number of technologies and solutions.
The best solution for one project is the worst for another. Before deciding which technologies will work we have to take all factors into consideration. Most of the time our teams will have multiple products which use different technologies.
Not Just Development
Deploying your application involves solutions for dependency management and managing environments and releases.
Using ES2015 and ES2016 means having to use a transpiler to convert our code into ES5 compatible code. Deploying your code to production will mean determining how you want to serve your code. The current trend has been to serve multiple packages and use code-splitting.
In addition to your framework or library, you will also want to figure out dependency management. Popular solutions include Rollup, Webpack, Browserify. You'll want to use NPM to manage your dependencies, unless bower is a better choice, such as with Polymer apps. You will need a build tool, probably Gulp if Webpack and NPM can't handle all your needs. When you're working with legacy apps you will need to understand older technologies such as RequireJS and Grunt.