> In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with.
And that's perfectly valid. In fact, it's one of the best reasons to use a framework.
If I hand-roll my application with a cobbled-together framework, I am the only one who understands how it works. Even if I'm a pretty great developer and write very clean code, there is an inherent complexity cost to any code—whoever comes on board will have to learn how I'm tracking state, managing the DOM, etc.
On the other hand, if I just wrote it in React I could be fairly confident that another web developer could pick up the project and easily understand how things are working with minimal effort. They've likely already paid the complexity cost of understanding React.
That's what the article and OP entirely miss. We don't use frameworks to improve the speed of the application. We don't even use frameworks to improve the speed of development. We use frameworks to improve the speed of understanding.
My point was solely that rewriting code--whether to a framework or for any other reason--is no reason to judge the original code as suspect.
Every team has their own reasons. You have yours, I have mine, but they’re the team’s reasons.
By the way...
> If I hand-roll my application with a cobbled-together framework
That is an interesting claim, but I do not find it to be a universal experience. Sometimes people--including myself!--do cobble together ad hoc frameworks, and in the long run a popular framework is almost always a better choice.
But sometimes, people just write a single app that does just what it needs to do without a lot of abstraction and indirection. They are ruthless about YAGNI. And the result is very easy to understand, because the cognitive load of reasoning about an app that is just an app is no greater than the cognitive load of reasoning about an app sitting on top of a framework you have internalized.
The problem is when people build their own framework and then build an app on top of their own framework. Sadly, this is usually the case, as they fall in love with building infrastructure in the hopes that future features can be added with just one line of code or dropping one file in one place.
That kind of thing is quite properly the domain of a framework, and very, very few teams should be writing frameworks.
tl;dr Let’s not set imply a false dichotomy between writing your own framework and using an off-the-shelf framework.
And that's perfectly valid. In fact, it's one of the best reasons to use a framework.
If I hand-roll my application with a cobbled-together framework, I am the only one who understands how it works. Even if I'm a pretty great developer and write very clean code, there is an inherent complexity cost to any code—whoever comes on board will have to learn how I'm tracking state, managing the DOM, etc.
On the other hand, if I just wrote it in React I could be fairly confident that another web developer could pick up the project and easily understand how things are working with minimal effort. They've likely already paid the complexity cost of understanding React.
That's what the article and OP entirely miss. We don't use frameworks to improve the speed of the application. We don't even use frameworks to improve the speed of development. We use frameworks to improve the speed of understanding.