Wouldn't it be easier to draft a set of design principles for the project? What I mean is if you really need a single page application, and usually you don't, that can be accomplished easily with turbolinks. If you really need to build DOM elements on the fly, that can be done really easily with raw JavaScript, which is fairly powerful on its own these days.
I just don't see it.
> Wouldn't it be easier to draft a set of design principles for the project?
Isn't this what a framework gives you out of the box? Hiring should become easier if you can simply hire another Angular dev to join your large team. I'm assuming that your in-house design principles won't be as thoroughly battle tested as something like Angular or React is which has received tens of thousands if not millions of man hours of testing and refinement over the years.I'm not really advocating for or against, since I've never used a large framework like this in a team environment, but there must be benefits. Lots of smart people aren't using it because they are dummies that can't do better.
I think the companies that are doing it are fighting over the space the same way operating systems do. Android, iOS, Windows. Potentially apps could start being developed for Angular and React and so on, in the future which are tied to licensing contracts for users.
All the smaller frameworks are people trying out a few things, none of them corporate or free are really necessary.
I'm not a front-end developer either (so my JavaScript experience is a bit limited), but with the back-end code that I work on with my team, enforcing policies can be a bit tricky. It's pretty easy for things to slip through in a pull request that are against policy, and it's kind of hard to automatically check for policy violations. When forcing someone to use an API, at least you can somewhat guarantee that the API follows the policy.
[1]: http://jlongster.com/Removing-User-Interface-Complexity,-or-...