I think you've got some really good ideas about a few things, and you've also missed (or not yet come to see) the problems that frameworks solve.
Writing everything from scratch is a great way to learn how things work. Maybe you want to understand what really goes on during the request-response lifecycle, or you want to write raw SQL queries instead of using a heavy ORM. The understanding that you get from doing this is super valuable, and every developer should certainly do it on some level. Also, because you have a deeper understanding of a concept it lets you debug other people's code more easily.
I think there are more and bigger downsides to writing everything from scratch though.
Writing from scratch is reinventing the wheel. Sure, you might come up with a better way to do it (maybe, but I probably won't, and definitely not the first time I do it). But practically every web application has a need to send requests and handle responses, and communicate with a database in some way or another.
Because these tasks are so common, people have written code to do the work for them. They have developed methods of dealing with them. You can think about the tasks as "problems" - they're things that need to get done in order for your application to work.
Using someone else's solution to handle requests and database queries just means that you're going to focus on solving different problems. The ones that your application has specific needs for, whatever that might be.
Learning how to solve these problems is valuable, but once you've built many applications, you may be tired of solving the same problems over and over again. This is why frameworks were developed.
Various frameworks might solve the same problems in different ways, but ultimately they do it so that you don't have to. Yes, you're limited to the choices the framework authors made, but in many cases that's okay because you're focusing on solving other problems. Yes, you have to learn how that framework solves those problems, but that's true every time you use code that you didn't write.
The main advantage I see to frameworks is standardization. this matters on bigger teams. You can hire someone that says "I know django and angular" and they can be productive on your project because they've already been exposed to the patterns that django and angular apps follow. They don't have to learn any new paradigms, they only have to learn your project's specific business logic.
I would also argue that frameworks (generally) scale better - not necessarily in terms of performance, but definitely when talking about code organization and design patterns. Having iterated and developed standards over time helps with this a ton. Working on a gigantic rails project is tough (though manageable), but working on a gigantic custom framework involves much more cognitive overhead, especially early on.
Anyway, no matter what you use, you're going to be solving problems. Which ones do you want to spend your time on?
If I want to correct one idea in this it's the idea that not using a framework means that I'll be reinventing the wheel. A lot of what you say about avoiding the duplication of effort applies to libraries. I like libraries. But why don't I like frameworks?
Use libraries so you're not 'reinventing the wheel' of HTTP message parsing. Maybe you'll use an ORM library to manage your database. Maybe you'll use a thin wrapper over SQL. But if you've abstracted the persistence layer correctly then you'll be able to change your mind depending on your needs and not the capability of the framework.
I agree that's true if you have the need to change things like that later. But in my experience, you have to go incredibly far down the road or have really extreme/specialized needs to not be satisfied with an off-the-shelf solution.
Your TODO-MVP has several good examples of how you can do some of these things with little code. I will posit an alternative - you can save yourself a ton of time by using a framework. You'll end up with more total code (maybe), but you'll also have more time to focus on other things.
You seem to be ignoring the time it can take to determine how a framework wants you to solve a given problem. We've spent considerable time on a CakePHP project trying to find the "right way" to solve a handful of problems which could have been solved with vanilla PHP in an hour.
I shy away from strong opinions because I'm as green as one can be in this field (green... field... mwahahah) but I'm guided by an excellent team and honestly, even when we develop in Rails, there are times when requests ought to be written in SQL, which is not only super educational but also makes (some) things faster, depending on how heavy the task is the gain can be huge. And I think that even using frameworks, knowing what's going on and having a curious/ tinkering mindset can allow you to slim down things a lot of times, avoid adding unnecessary components and such. I think what gipsydave5 says is not all theory. Again, a noob's two cents.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think you've got some really good ideas about a few things, and you've also missed (or not yet come to see) the problems that frameworks solve.
Writing everything from scratch is a great way to learn how things work. Maybe you want to understand what really goes on during the request-response lifecycle, or you want to write raw SQL queries instead of using a heavy ORM. The understanding that you get from doing this is super valuable, and every developer should certainly do it on some level. Also, because you have a deeper understanding of a concept it lets you debug other people's code more easily.
I think there are more and bigger downsides to writing everything from scratch though.
Writing from scratch is reinventing the wheel. Sure, you might come up with a better way to do it (maybe, but I probably won't, and definitely not the first time I do it). But practically every web application has a need to send requests and handle responses, and communicate with a database in some way or another.
Because these tasks are so common, people have written code to do the work for them. They have developed methods of dealing with them. You can think about the tasks as "problems" - they're things that need to get done in order for your application to work.
Using someone else's solution to handle requests and database queries just means that you're going to focus on solving different problems. The ones that your application has specific needs for, whatever that might be.
Learning how to solve these problems is valuable, but once you've built many applications, you may be tired of solving the same problems over and over again. This is why frameworks were developed.
Various frameworks might solve the same problems in different ways, but ultimately they do it so that you don't have to. Yes, you're limited to the choices the framework authors made, but in many cases that's okay because you're focusing on solving other problems. Yes, you have to learn how that framework solves those problems, but that's true every time you use code that you didn't write.
The main advantage I see to frameworks is standardization. this matters on bigger teams. You can hire someone that says "I know django and angular" and they can be productive on your project because they've already been exposed to the patterns that django and angular apps follow. They don't have to learn any new paradigms, they only have to learn your project's specific business logic.
I would also argue that frameworks (generally) scale better - not necessarily in terms of performance, but definitely when talking about code organization and design patterns. Having iterated and developed standards over time helps with this a ton. Working on a gigantic rails project is tough (though manageable), but working on a gigantic custom framework involves much more cognitive overhead, especially early on.
Anyway, no matter what you use, you're going to be solving problems. Which ones do you want to spend your time on?
If I want to correct one idea in this it's the idea that not using a framework means that I'll be reinventing the wheel. A lot of what you say about avoiding the duplication of effort applies to libraries. I like libraries. But why don't I like frameworks?
Use libraries so you're not 'reinventing the wheel' of HTTP message parsing. Maybe you'll use an ORM library to manage your database. Maybe you'll use a thin wrapper over SQL. But if you've abstracted the persistence layer correctly then you'll be able to change your mind depending on your needs and not the capability of the framework.
I agree that's true if you have the need to change things like that later. But in my experience, you have to go incredibly far down the road or have really extreme/specialized needs to not be satisfied with an off-the-shelf solution.
Your TODO-MVP has several good examples of how you can do some of these things with little code. I will posit an alternative - you can save yourself a ton of time by using a framework. You'll end up with more total code (maybe), but you'll also have more time to focus on other things.
You seem to be ignoring the time it can take to determine how a framework wants you to solve a given problem. We've spent considerable time on a CakePHP project trying to find the "right way" to solve a handful of problems which could have been solved with vanilla PHP in an hour.
I shy away from strong opinions because I'm as green as one can be in this field (green... field... mwahahah) but I'm guided by an excellent team and honestly, even when we develop in Rails, there are times when requests ought to be written in SQL, which is not only super educational but also makes (some) things faster, depending on how heavy the task is the gain can be huge. And I think that even using frameworks, knowing what's going on and having a curious/ tinkering mindset can allow you to slim down things a lot of times, avoid adding unnecessary components and such. I think what gipsydave5 says is not all theory. Again, a noob's two cents.