The idea is that frameworks are generally designed to be used by other people, leading to greater focus on documentation, developer ergonomics, community support and generally more versatile code (scales with number of contributers/users; many will report obscure bugs and edge cases you may never consider testing but would impact your end users). Another huge benefit is you don't have to rewrite an entire system from scratch, saving time and mental load.

I'd say there's quite a bit "special" about all of these attributes, at least enough to warrant careful consideration.

Until $framework decides to rewrite everything too, and now you're stuck on an old unmaintained version or waste time migrating to the new version.

s/$framework/$any-coding-project-written-ever

Don't let bad frameworks represent all frameworks. That is a faulty generalization [0].

[0] https://en.wikipedia.org/wiki/Faulty_generalization

Just because something is designed to be used by other people doesn't mean it's good. There are lots of things designed to be used by other people, leading to all of the features you list: documentation, community, other people finding bugs, yada yada yada... languages, operating systems, libraries... and many of those things still suck. There is nothing inherent about being designed for use by other people that makes things suck less, and there is nothing magical about "frameworks" that makes them suck less than all the other stuff designed to be used by other people but still sucks.

If you qualify this advice to the point where it actually becomes useful it turns into, "Use code written by other people that doesn't suck." And that, of course, is indeed a good idea, but it's a lot easier said than done.

Absolutely; most frameworks will not fulfill their design goal. Most ambitious open source programming efforts tend to wither away due to loss of interest, a failure to gain contributors, lack of experience, lack of time or energy and many other factors.

But despite that caveat, there do exist frameworks out there today that speed up development for some developers. Whether one has the time or energy or will to audit them to find one that works best for them (or learn that none of them do) is up to the individual.

I bring this up because many of us on this website are at times infected by NIH syndrome and think we can do better than a dedicated team of experienced front-end developers. And it's likely true for many frameworks, but not all. Additionally, we may want to extend that attitude to our workplace where our peers and bosses likely value development speed and cross-project consistency over code performance.

I used to eschew any and all frameworks, but now I realize that my values have changed. Projects like Svelte give me hope for a better future for front-end development.

> But despite that caveat, there do exist frameworks out there today that speed up development for some developers.

Of course. But there also exist frameworks that will slow development down. For any X in {frameworks, languages, operating systems, libraries} there exist X's that will be helpful and X's that will not, and so "use an X" by itself is not helpful advice for any X. You have to use a good X, but that isn't helpful either because it just begs the question.

Absolutely true.

I just intended to push back against the notion that frameworks should not be considered.

I'll address both your comments here if that's alright,

It's not about code quality at all, it actually doesn't matter that much if the framework is excellent or just okay to reap the main benefit, which is knowledge diffusion through the team and having a set of agreed upon idioms that there's no need to bike shed over. Not every team has a software architect skillset so it's a bit of a risk hedge as well.

There's no need to argue over implementation details, you waste less time onboarding new staff and you have that rich ecosystem of docs and community of solved problems.

That's all. There are great reasons to build your own software but if you're working in a team I feel it's an easier experience to use a known framework. Also a bit more responsible from a business risk management perspective, since you don't have as big of a "bus problem". Only your business logic is trapped inside your org.

That's a sound argument under certain circumstances. If you're building a standard product using relatively unskilled labor then yes, using a framework -- any framework -- can be helpful. But if you're doing something where rewriting an existing code base is even an option you would consider then you almost certainly are not operating under those circumstances. For starters, you probably have people on your team who are plausibly capable of rewriting the existing code, and under those circumstances, hemming those people in with a bad framework can do a lot more harm than good. So I stand by my original statement: "Use a framework" is not good advice in general. It can be the right thing under certain circumstances, but the art is in recognizing those circumstances, not in the use of a framework. Blindly following "use a framework" with no further qualification is a PHB move.