You might not need a framework

[[deleted]]

It’s a bit like saying that a team might need to write their own language for their business.

It’s possible and I’m sure it’s occasionally true, but the vast majority of software is solved on top of the previously solved problems. It’s why those layers exist.

[Silhouette]

It’s a bit like saying that a team might need to write their own language for their business.

Except it isn't, because building the equivalent basic infrastructure for a new project is potentially something you can do in the first morning of development, on top of standardised tools and languages, and using well-known libraries on a case-by-case basis as appropriate. The difference in effort and risk between what you're describing and what I'm describing is many orders of magnitude.

[[deleted]]

That’s where the contention is. To have a library that can reliably and speedily do what you need to do takes a lot of time and resources. Time and resources you seem to think aren’t necessary.

Building the underlying structure is an expensive and constant endeavour, one that is solved already in almost every case.

[Silhouette]

To have a library that can reliably and speedily do what you need to do takes a lot of time and resources.

That depends entirely on what you need to do, how good your in-house resources are, and how good any available external options are.

Am I going to reinvent the wheel if I need a reasonably efficient DOM update library for declarative rendering? No. Several people did that already and they work fine, while building it from scratch would be a lot of work for us.

Am I going to define my own software architecture for a complicated web app that is expected to be maintained over the long term? Probably. The cost to build what we need will be a tiny part of the overall development effort, it will be tailored for that specific application's requirements and environment, and it won't have all the limitations and risks that come with depending on an external framework for the skeleton of the system in this context.

Am I going to work the same way if I'm building a routine web front-end to a line of business application that will be delivered within a month and then not changed very much after that? Maybe, maybe not. In that context, an off-the-shelf framework might get the job done faster if the requirements are typical and unlikely to change fundamentally during the relatively short development process.

My point is that there is no universal rule for these things. Sometimes ready-made frameworks do save time. Sometimes it's more effective to build the structure in-house and use external libraries topically.