[jordache]

What about maintainability? You want everyone who touches your code to figure out your custom solution for data binding? Or you could just follow the conventions established by an industry popular framework that is instantly consumable by another developer?

[johnnyb_61820]

But that's just the problem with the modern proliferation. Finding a developer who is proficient enough in all of the frameworks you might be using is difficult. It's not enough just to have a JavaScript developer, you have to specify about 20 frameworks that you are using. It's not possible to train everyone in all of these, so then, even your framework system becomes personal, because it is setup to your personal choices (much like a custom function!). Since new people can't reasonably be required to fully understand the totality of the system, they will still come up with personal hacks, precisely because the set of things to know is too large.

Remember, they don't know which part of the framework you are using or not, or which parts are important or not, so even if you are using it for one little thing, they probably have to learn most of it to understand how it interacts. Since so many frameworks overload standard functionality, it is impossible to know how a framework interacts with your code until you know all of these things.

Using 20 frameworks is about as efficient use of your time as having one you built yourself. The sweet spot for a medium-sized application is using 2-4 (maybe a few more if they are really standard or do really specialized functionality - i.e., a PDF library) for the most critical components, and still maintaining the remaining quirks yourself.

So, for example, Ruby-on-Rails + Bootstrap + JQuery goes a very long way, and doesn't put an undue burden on people trying to get to know your code.

[zzalpha]

Seriously?

If your application become sufficiently complex that it can't be easily grokked by a decent dev, that's when you know it's time to switch.

Until then it's just over engineering (which the JS community admittedly loves).

[greg5green]

Very few teams have the opportunity to switch later on, and if they do, it's at the expense of the job of the person who chose to go without a framework.

[ChoHag]

If you've allowed your code to grow so far that refactoring is impossible, you have bigger problems to fix than a messy codebase.

[johnnyb_61820]

Everyone has to refactor into new frameworks later on. Going without a framework early on doesn't add an expense, it actually just subtracts one. It is only if they had chosen the framework (and other code decisions) with perfect future vision that this cost would be mitigated.

I estimate that every 20% that a codebase grows it needs some amount of refactoring. Definitely anything that moves from skunkworks to production will need some pretty heavy rewrites, and will probably need a framework that better meets its newer needs. The question is how much cost was sunk in getting there. The refactor will have to happen no matter what.

[jordache]

what is that complexity threshold? Self determined no doubt.

Guy A believes his custom design is simple enough to comprehend by anyone. Guy B doesn't agree.

It doesn't really matter at the end of the day. If you work in a team environment, the toolset will be pre-determined already. You don't have a choice.