"often just ways of excusing a failure to think for yourself"
This is a very good thing!
Otherwise, you have to spend years of studying to do anything of significance. Or if you want to go into an area you haven't studied before, frameworks make it easier to do this.
So yes "think for yourself" but not all the time because you'll get less done.
I would hate to see a world without frameworks because the barrier to programming something useful would be higher and deter people from entering the field.
I would hate to see a world without frameworks because the barrier to programming something useful would be higher and deter people from entering the field.
I feel its the opposite and youre maybe missing the point of the post.
In my view, the barrier to entry of programming looks worse than it is because of frameworks.
Look at the code Dave posted. It's not complicated or hard. The point he is making is the barrier to entry is already low, if you look past the hype of FOTM frameworks and just study the basics.
It's just there is a perception that you cant do something "real" unless there's a framework. Learning frameworks is so much harder than learning the fundamentals.
I agree you can do a lot without a framework. But you can do something more "professional" with a framework faster at least initially. To get to that uncomplicated code probably took years of experience. Most people even if they know the basics write bad code and it takes years to make it good and uncomplicated. A framework at least guides you along until your good enough to do those on your own. The real problem comes when trying to throw away the framework when you don't need it any more.
Abstractions are hard to get right. And an abstraction that has been vetted by a community and implemented in code is hard to beat.
Too right they are! Abstracting away a database - awesome. Abstracting away the underlying bytes of an HTTP response - I'm a fan.
But what does, say, Angular abstract? What is the underlying entity that is abstracted by Ruby on Rails?
In my opinion, they are not abstractions at all. They're tarballs of multiple abstractions, an attempt to generalize certain business requirements. I think you'll get so far with this, but in the end (as you rightly say):
The real problem comes when trying to throw away the framework when you don't need it any more.
I would love to see a discussion about what frameworks have a good off ramp when you have out grown them. Do they exist? Or what are some techniques to do so? Or which frameworks are the most flexible and let you interchange the pieces?
"often just ways of excusing a failure to think for yourself"
This is a very good thing!
Otherwise, you have to spend years of studying to do anything of significance. Or if you want to go into an area you haven't studied before, frameworks make it easier to do this.
So yes "think for yourself" but not all the time because you'll get less done.
I would hate to see a world without frameworks because the barrier to programming something useful would be higher and deter people from entering the field.
I feel its the opposite and youre maybe missing the point of the post.
In my view, the barrier to entry of programming looks worse than it is because of frameworks.
Look at the code Dave posted. It's not complicated or hard. The point he is making is the barrier to entry is already low, if you look past the hype of FOTM frameworks and just study the basics.
It's just there is a perception that you cant do something "real" unless there's a framework. Learning frameworks is so much harder than learning the fundamentals.
I agree you can do a lot without a framework. But you can do something more "professional" with a framework faster at least initially. To get to that uncomplicated code probably took years of experience. Most people even if they know the basics write bad code and it takes years to make it good and uncomplicated. A framework at least guides you along until your good enough to do those on your own. The real problem comes when trying to throw away the framework when you don't need it any more.
Abstractions are hard to get right. And an abstraction that has been vetted by a community and implemented in code is hard to beat.
Too right they are! Abstracting away a database - awesome. Abstracting away the underlying bytes of an HTTP response - I'm a fan.
But what does, say, Angular abstract? What is the underlying entity that is abstracted by Ruby on Rails?
In my opinion, they are not abstractions at all. They're tarballs of multiple abstractions, an attempt to generalize certain business requirements. I think you'll get so far with this, but in the end (as you rightly say):
I would love to see a discussion about what frameworks have a good off ramp when you have out grown them. Do they exist? Or what are some techniques to do so? Or which frameworks are the most flexible and let you interchange the pieces?
Now that is a great question. I think you could dip your toes by Googling 'How I migrated Angular to React' to get some idea.