I tend to agree with the view that if your code reached a level of complexity where you begin to develop your own framework, then you should just use an existing one.
Hopefully the knowledge gained getting to this point also means you now know enough to pick the right one!
Striving to become a master Go/Cloud developer; Father ๐จโ๐งโ๐ฆ; ๐ค/((Full Stack Web|Unity3D) + Developer)/g; Science supporter ๐ฉโ๐ฌ; https://coder.today
When you reach that stage there is no going back to a framework, the change would be too costly with minimal ROI. Its a decision you should make before writing code.
I tend to agree with the view that if your code reached a level of complexity where you begin to develop your own framework, then you should just use an existing one.
Hopefully the knowledge gained getting to this point also means you now know enough to pick the right one!
When you reach that stage there is no going back to a framework, the change would be too costly with minimal ROI. Its a decision you should make before writing code.
Which is fine when you already know why you want to choose a particular framework and that it will do the job you need.
I also hate being locked in to an approach which means your future options may be constrained.
There may be benefit in us refactoring as a training process and because the early apps really have some weaknesses!
But I get your point, maybe in the end we'll just switch to "the final solution" for the next iteration of development.