| > It's quick and easy to get started with frameworks, but you inevitably try to do something that's very difficult to figure out how to do. Instead of just writing code that does it, you have to search the docs of the framework to figure out how to do it the way the framework wants. The problem with this mindset is that yes, its quicker to just bash out some code that does what you want it to but what happens when another developer has to work with that same code later down the line? They are going to have to spend time to figure out how you've structured everything. One of the advantages of using a framework is to follow a standardized structure. That way a developer only has to learn the framework's structure once, as opposed to learning the individual preferred structure of each and every colleague he collaborates with. > You end up reading docs more than writing code. I would say that this the reality of being a software engineer. A good software engineer spends more time reading docs, researching design patterns, reviewing existing implementations and considering the implications of different solutions than he does writing actual code. > You usually can't just read the code to understand how the app works. This isn't my experience with frameworks. Since pretty much all frameworks follow the MVC pattern its usually clear where everything goes. |
For professional development, when someone is paying you, sure, this is absolutely correct. But in the case of banging out a side project, it makes much less sense.
I went frameworkless on an mvp last year. I was able to code and implement features using raw apis quickly. I reached MVP status and launched. One year later, no users and I'm closing the site. I'm sure glad I didn't waste a lot of time learning a new framework who's complexity and standardization I never needed!