That's a lot of words to extol building your own framework for each project you start. I know the articles ends with saying this isn't what is being suggested... but it looks like it.
With regards to the stated drawbacks of frameworks:
> comply with their API
Is a fair point I guess. It's also the obvious tradeoff that everyone is willingly accepting. It also isn't strictly true either In most frameworks, like React, there are escape hatches to do things however you want. I've written React components that hand over control of the rendered element to some pure JS code to do some animation with a library that doesn't speak React for example.
> upgrades are effectively forced
I guess so. These updates often come with perf improvements, new features and only rarely do they remove existing API's. Not having to maintain an impromptu custom framework means someone else is focusing on optimising for me while I focus on business logic.
> train to learn how they work
Isn't this exactly the same as bringing in a new developer to work on your custom web app build that does everything differently to everyone else? he has to learn your strategies for routing, caching, state propagation, etc, and has no external resources to help him.
> compromise with the drawbacks implied by delegating control
I think this is a good point for web apps with a very high performance requirement. I don't see the problem with almost everything else though.
> lose skills. A number of developers either don’t know much about the lower-level APIs (because they always used the framework layer instead) or live in the past
This has been true since before all of the big web app frameworks became popular. I don't see the frameworks themselves being responsible for lazy developers.
With regards to the stated drawbacks of frameworks:
> comply with their API
Is a fair point I guess. It's also the obvious tradeoff that everyone is willingly accepting. It also isn't strictly true either In most frameworks, like React, there are escape hatches to do things however you want. I've written React components that hand over control of the rendered element to some pure JS code to do some animation with a library that doesn't speak React for example.
> upgrades are effectively forced
I guess so. These updates often come with perf improvements, new features and only rarely do they remove existing API's. Not having to maintain an impromptu custom framework means someone else is focusing on optimising for me while I focus on business logic.
> train to learn how they work
Isn't this exactly the same as bringing in a new developer to work on your custom web app build that does everything differently to everyone else? he has to learn your strategies for routing, caching, state propagation, etc, and has no external resources to help him.
> compromise with the drawbacks implied by delegating control
I think this is a good point for web apps with a very high performance requirement. I don't see the problem with almost everything else though.
> lose skills. A number of developers either don’t know much about the lower-level APIs (because they always used the framework layer instead) or live in the past
This has been true since before all of the big web app frameworks became popular. I don't see the frameworks themselves being responsible for lazy developers.