The main point of frameworks/libraries is to set coding guidelines for the team. It's fine to go off and invent your own framework but this causes maintenance issues for the people coming in next. Most likely, there are no docs or examples for the code you just wrote (especially the framework bits). When a framework which has a community is chosen, these boring things like docs/examples/references/blog posts get fixed over time. So it's best to pick one so that the code is easier to maintain in the long run. Besides, the focus should be on the app and not the framework/library and writing your own is just distraction.
>When a framework which has a community is chosen, these boring things like docs/examples/references/blog posts get fixed over time.
Not in my experience. I've seen frameworks come and go like that over the span of 15 years and teams rewriting for the new "hotness".
So, one year they do Angular, then Angular 2 comes out, invalidating a lot of their code/experience, then they get to React, then they're told that they should structure it like Flux, then Redux comes along, and who knows what in 2 years.
Just imaging that merely 5 years ago Backbone was the preferred edge JS framework. In fact wasn't even that at that point -- it was only just released 5 years ago...
Release of a new framework doesn't render all existing code based on an older framework useless. Nobody mandates moving all existing Angular 1 codebases to Angular 2.
But eventually they'll bit rot, and all the new features, and community support will move to 2 -- and you're stuck with the worst of both worlds: a framework with stuff you don't need AND with few left to maintain it.
