[scarface74]

And then someone else has to come behind you to support your custom framework.

I can’t count the number of times where an “architect” has evolved their own custom framework because they thought their problem was a special snowflake. It’s usually worse, less document and less tested than the popular alternative.

[bob1029]

> 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.

[dwohnitmok]

> 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)

[ivanhoe]

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.

[teg4n_]

This makes no sense. Frontend web frameworks don’t do anything for security besides escaping HTML occasionally.

[scarface74]

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.

[dakna]

> It’s usually worse, less document and less tested than the popular alternative.

That's often true, but the situation is not much different to framework stagnation.

"Popular" frontend frameworks I have worked with throughout the years, which are all more or less obsolete now:

Dojo, KnockoutJS, ExtJS, Backbone.JS, AngularJS, Angular 2+, Ionic

Web frontends are replaced every couple of years, often triggered by new feature development using the shiny new framework, and the cost of supporting the old, now unpopular framework.

Focusing on the actual web standards instead of another framework abstraction has long term value. For example, being able to query a DB using SQL is as relevant as it was 30 years ago, despite the numerous ORM/QueryGenerators on top of it.

[scarface74]

And yes when I started web development CSS didn’t exist. Knowing web standards doesn’t keep you from having to learn.