> And then someone else has to come behind you to support your custom framework.
Are you asserting that developing an understanding for a vanilla web codebase is somehow worse than figuring out how to upgrade an Angular2 project to Angular8?
The biggest reason we use "custom" framework is because all the "standard" frameworks change too rapidly to support our business model. They also fall out of support before our B2B contracts expire, creating very difficult situations at due diligence time. We sell software to banks, so we don't get much room to work with regarding our 3rd parties.
> Are you asserting that developing an understanding for a vanilla web codebase is somehow worse than figuring out how to upgrade an Angular2 project to Angular8?
That depends on the details of the vanilla web codebase no? There's no bright line between "vanilla web" and "custom in-house Angular-like framework we created from scratch that stymies new developers." It's all a matter of how the vanilla codebase is developed.
(but sure there are certainly reasons to do something without a pre-built framework, especially if you have certain support commitments)
On the other hand mainstream frameworks have a big community behind them, while the custom framework's support is only you - thus making it:
1) far more likely that you have undiscovered vulnerabilities in it,
2) actually a lot more work to keep it up to date and properly secured over time, since it's all up to your team (and this becomes exponentially harder with every 3rd party lib that you use).
Not implying it's the case with your company, of course, but most of B2B companies that I've seen that use custom frameworks solve these 2 problems by simply ignoring them and not updating anything - hoping for the best and relying primarily on security through obscurity for protection.
I’m asserting that as the needs of your website expand and grow, you’re going to need to add cross cutting concerns that are not core to your business logic and you will inevitably end up creating your own framework.
See also: custom ORM, custom logging framework, custom authentication, etc.
Are you asserting that developing an understanding for a vanilla web codebase is somehow worse than figuring out how to upgrade an Angular2 project to Angular8?
The biggest reason we use "custom" framework is because all the "standard" frameworks change too rapidly to support our business model. They also fall out of support before our B2B contracts expire, creating very difficult situations at due diligence time. We sell software to banks, so we don't get much room to work with regarding our 3rd parties.