Frameworks are a whole discussion about the topic of complexity, switching cost, sunk cost, incentives, personal preference, market position and job security.
I built enterprise B2B applications for several years, saw a lot of frameworks come and go. Worked on technical evangelism for many developer products, hardware + software.
Job Security:
- The internal framework architect / maintainer is unfireable
- Building a framework is high prestige, worth potentially millions (contracts, books, consulting) if it catches on (see: Ruby on Rails)
- Successful frameworks spawn massive industries (React training, anyone?)
There are tremendous market incentives to try to build and market a framework. Even if you fail, you learn a lot by trying. For the most part; the act of Building a framework is nearly always a good idea for career purposes. This is part of why there are so many of them. And it’s fun.
Programmer Preference:
- I have rarely seen two programmers agree, or be happy about the most basic decisions in same code base: capitalization etc.
- Programmers are highly particular, the odds two programmers will love each others code is close to zero
Thus: A framework represents one programmers attempt to fully encapsulate their entire vision of “how it ought to be done.” This vision is often non-transferable.
Complexity:
A program of any size involves thousands of decisions that form an interlinking network. Largest application I have written was 100,000 lines of C. Relied on many external libraries, user experience and design decisions.
Altering a framework by swapping out a single component can have cascading effects throughout entire system and to the user of the framework. Who is going to train everyone to go from Objective-C to Swift, for example?
This makes frameworks highly brittle. Which leads to topic of sunk cost / switching cost.
Switching cost:
Once a framework changes or a new framework arrives, programmers must make an economic decision. Switch to new framework (lose time and money) or keep going switching is painful.
Meanwhile, new crop of learners focusing on new framework get ahead learning that. Too bad for you: Your experience in Spring doesn’t translate to new framework XXX.
Anyways:
I can talk about the sources of the problems, but it is unlikely to ever get solved by humans writing code. Programming is just a complex field.
Inevitably, popular frameworks address this by making themselves so configurable that you can use them however you want... defeating the purpose of using a framework in the first place.
I built enterprise B2B applications for several years, saw a lot of frameworks come and go. Worked on technical evangelism for many developer products, hardware + software.
Job Security: - The internal framework architect / maintainer is unfireable - Building a framework is high prestige, worth potentially millions (contracts, books, consulting) if it catches on (see: Ruby on Rails) - Successful frameworks spawn massive industries (React training, anyone?)
There are tremendous market incentives to try to build and market a framework. Even if you fail, you learn a lot by trying. For the most part; the act of Building a framework is nearly always a good idea for career purposes. This is part of why there are so many of them. And it’s fun.
Programmer Preference: - I have rarely seen two programmers agree, or be happy about the most basic decisions in same code base: capitalization etc. - Programmers are highly particular, the odds two programmers will love each others code is close to zero
Thus: A framework represents one programmers attempt to fully encapsulate their entire vision of “how it ought to be done.” This vision is often non-transferable.
Complexity: A program of any size involves thousands of decisions that form an interlinking network. Largest application I have written was 100,000 lines of C. Relied on many external libraries, user experience and design decisions.
Altering a framework by swapping out a single component can have cascading effects throughout entire system and to the user of the framework. Who is going to train everyone to go from Objective-C to Swift, for example?
This makes frameworks highly brittle. Which leads to topic of sunk cost / switching cost.
Switching cost: Once a framework changes or a new framework arrives, programmers must make an economic decision. Switch to new framework (lose time and money) or keep going switching is painful.
Meanwhile, new crop of learners focusing on new framework get ahead learning that. Too bad for you: Your experience in Spring doesn’t translate to new framework XXX.
Anyways:
I can talk about the sources of the problems, but it is unlikely to ever get solved by humans writing code. Programming is just a complex field.