A) There are people that love frameworks.
B) There are the ones that don't.
The type A ones just gave up to the complexity and bury it with foreign frameworks.
The latter ones invent their own ecosystem. And are very productive with it. It's fast and beautiful. And you know every screw and bolt. There is a feature request? No problem, you know immediately how to solve it. I know many of them. And nearly all of them are the best I have ever known.
But here is the big "but". Would programmer type B want to work with a 2 year old project from another type B programmer? And there you have your answer why there is such a hugh appretiation for frameworks. Its easier to throw 10 programmers of type A onto the same project.
> The latter ones invent their own ecosystem. And are very productive with it. It's fast and beautiful. And you know every screw and bolt. There is a feature request? No problem, you know immediately how to solve it. I know many of them. And nearly all of them are the best I have ever known.
You're forgetting type C that don't know anything about existing frameworks so decide to reinvent the wheel by writing an unmaintainable mess of spaghetti code... I'm guessing type Bs are very rare. Once you've seen enough untestable jQuery soup you'll learn to appreciate frameworks.
I would go so far as to say that to a new programmer on the team, Type B and Type C programmers' code looks much the same.
I'm a type B. I've written entire systems from scratch that fit me like a glove. I could fix any problem in no time flat, and it was very stable.
But when it came time to have other people work on it, it didn't fit them like a glove. It barely made any sense to them at all. They eventually got up to speed, but they were never as productive in it as they would have been in a decent framework-based system.
I was actually quite happy when they decided to rewrite the whole thing... And then it turned out I left about a year later, so it was a good thing they did.
> Would programmer type B want to work with a 2 year old project from another type B programmer?
Sure!
A homegrown javascript ecosystem doesn't grow up in a vacuum. It may include smaller libraries that aren't as opinionated as this year's popular framework. It may draw inspiration from Backbone or Flux without using either outright. And it should follow familiar design patterns.
Now, the answer you probably expected was "I'd want to see it first." And that's true, but that's also true with a framework. The things that make a project pleasant to work on - good architecture, docs, clarity - aren't guaranteed with a framework.
So frameworks matters because they define a set of development practices to get interoperability between project members, to allow different people (in terms of development practices) to do work together.
Seems like it's mainly a matter of balance between collaborative work easiness and individual work flow quality.
There's also the work avoided by not having to test code on different environments but after reading this thread looks like it's a minor advantage of frameworks.
The type A ones just gave up to the complexity and bury it with foreign frameworks.
The latter ones invent their own ecosystem. And are very productive with it. It's fast and beautiful. And you know every screw and bolt. There is a feature request? No problem, you know immediately how to solve it. I know many of them. And nearly all of them are the best I have ever known.
But here is the big "but". Would programmer type B want to work with a 2 year old project from another type B programmer? And there you have your answer why there is such a hugh appretiation for frameworks. Its easier to throw 10 programmers of type A onto the same project.