> Frameworks are most often a bad idea. Use libraries instead.
People say this a lot, and it makes me wonder if they've ever worked on a team working on the same codebase. And if they do, what secret sauce they're drinking to not go insane.
In my experience, when people on a team use libraries at their whim, the coding styles diverge wildly from feature to feature. One person decides they're going to write all their AJAX callbacks in an anonymous function; another likes to reference a function directly; another likes to both; and yet another uses promises.
And as soon as someone needs to fix someone else's project, they do some combination of (a) getting wildly frustrated with this other coding style, (b) rewire their mental model to adapt to this new style, (c) spend a week rewriting it in their own style, (d) introduce a ton of bugs in the process, or (e) by some miracle, get it to work perfectly.
So to combat this, the team works out coding standards and a style guide. You must tab with two spaces! You must pass a real Javascript function to your callbacks! You must separate your state from your view!
And of course, once your style guide is big enough, lo and behold: you have your own hand-rolled framework. And hopefully it's tight enough that everyone writes in the same style, but is still expressive, and is still simple enough for a new team member to learn quickly.
So if you're just starting a codebase, it makes complete sense to pick a framework on the outset because people have already gone through that headache for you.
Absolutely, I'm beginning to lose patience repeating the frankly blinding-obvious-at-this-point-argument you just had to make, but I'm glad others like yourself haven't.
The 'don't use frameworks, use libraries' argument is naive, and just does not hold up in the real world of teams trying to build things.
And I have found the "you're just writing your own framework" point needlessly repeated over and over, despite having never run into it in practice. Choosing a large framework does not insulate you from the concerns of the grandparent. You still must come up with a style guide, and a way of using the tools. The win is not obvious, imo.
The style guide is surely longer when using a toolset with fewer conventions?
If I'm using Backbone over Ember, my style guide has to cover things that would be covered by Ember's own docs, for example how to compose views, how to do nested routing, how to represent computed properties ...
Your longer style guide is defining code patterns for those use-cases. Your longer style guide is a framework, just more verbose because you aren't actually abstracting away those patterns.
I don't think that a framework is a good substitute for a style guide or the processes like reviewing, documenting or factoring code that lead to consistency and readability. If your team members feel like they have to "rewire their mental models" or spend weeks rewriting code rather than adapting to it, the team has a problem that you should deal with in another way than pigeonholing your projects into frameworks.
I generally disagree with the sentiment that collections of libraries are somehow inherently a better solution than frameworks, though. I just think that it is probably a poor solution to the problem you describe here.
I'm moving towards the library approach for some toy projects for both client and server.
There is no perfect framework and by choosing one you're usually stuck with its warts for the long haul. I usually find that I'm bending my code to fit into the framework conventions that I don't necessarily agree with.
With ExtJS for example, the framework conventions dictate your project should be organized into folders like this:
controllers/
models/
views/
...whereas I prefer controllers, models, and views, which are coupled, to be located in the same folder and models which are intended to be shared to be explicitly in a shared folder.
Another example (still ExtJS!) is that I never agreed with ExtJS's MVC implementation - where its controllers were global for all instances of a view. It took Sencha several years before they fixed this by adding "ViewControllers" in ExtJS 5.
If ExtJS was not an all-encompassing framework I would have liked to use its UI components with a different MVC library (or simply vanilla JS) organized into my preferred project structure. I suppose it's still possible to do this but with frameworks you tend to not want to deviate too much from the framework conventions or things start to go wrong.
People say this a lot, and it makes me wonder if they've ever worked on a team working on the same codebase. And if they do, what secret sauce they're drinking to not go insane.
In my experience, when people on a team use libraries at their whim, the coding styles diverge wildly from feature to feature. One person decides they're going to write all their AJAX callbacks in an anonymous function; another likes to reference a function directly; another likes to both; and yet another uses promises.
And as soon as someone needs to fix someone else's project, they do some combination of (a) getting wildly frustrated with this other coding style, (b) rewire their mental model to adapt to this new style, (c) spend a week rewriting it in their own style, (d) introduce a ton of bugs in the process, or (e) by some miracle, get it to work perfectly.
So to combat this, the team works out coding standards and a style guide. You must tab with two spaces! You must pass a real Javascript function to your callbacks! You must separate your state from your view!
And of course, once your style guide is big enough, lo and behold: you have your own hand-rolled framework. And hopefully it's tight enough that everyone writes in the same style, but is still expressive, and is still simple enough for a new team member to learn quickly.
So if you're just starting a codebase, it makes complete sense to pick a framework on the outset because people have already gone through that headache for you.