[treehau5]

> The second your application grows in an unexpected way, you need to augment the entire framework to suit

The second you need to do something your framework doesn't, the same rule applies. Frameworks are really good for covering most things, but almost everyone runs into that last 5-10% or so that it doesn't do. That ends up being the most difficult, in my experience.

[jakub_g]

To be a devil's advocate: That's true, but still it's the last 10% that is hard when using a well-known framework, compared to 100% when you handcraft everything in a basement.

If you use a well-known fwk, you can tell junior devs and new devs to google stuff when in need (as a first line of help), otherwise, you need to write a ton of documentation and/or devote hours per week on support, at the times when you have the least will to do that.

There's no one-fits-all solution, depends on the project, team, constraints etc.

[treehau5]

> To be a devil's advocate: That's true, but still it's the last 10% that is hard when using a well-known framework, compared to 100% when you handcraft everything in a basement.

I am saying they are about the same. The last 10% is about as much work as bootstrapping a specific solution.

The new junior dev point is irrelevant if you stick to plain vanilla javascript, and hire junior devs that actually know javascript. Your devs should know how to read code and tests.

> otherwise, you need to write a ton of documentation and/or devote hours per week on support, at the times when you have the least will to do that.

No I don't.

Junior dev: "hey how does this work?" Me: "Did you run the tests?"

[dismantlethesun]

Whilst this may be true in general, I find that when it comes to Javascript, things are already so sandboxed and reliant on the DOM api, that there's little you can do to shoot yourself in the foot.

At worst, your site won't be cross-browser compatible, but it's not like it's serverside where the framework is legitimately doing heavy lifting in a high performance environment.