> I don't think giving an opinion such as "I don't like frameworks" without any concrete source code of non-trivial projects is productive discussion.
Fair enough, even though it's hard to point to a specific piece of code when talking about such abstract concepts. And I'm not working on any open source projects.
My go-to example is dependency injection and ASP.NET Core. For the most part, I really like the features and it's mostly okay as a framework, even though I'm not sure why it has to be one. When I started taking clean code and DI more seriously, I learned that ASP.NET Core gets these things wrong in a subtle way that turns the whole idea of DI into a bit of a farce. This post explains it really well:
I wish there was an easy way of removing the "framework" aspect from that thing and just have a bunch of libraries for handling HTTP requests, rendering pages, dealing with security and so on.
> A good framework that fits the problem domain does a lot of low-level gruntwork that frees the programmer to focus on higher-level tasks.
I agree that this is a noble goal, and I'm sure there are plenty of frameworks that are good enough. But sometimes you don't have a lot of choice, and in the worst case all of the useful libraries for your domain depend on a framework that you don't really want to use.
> It's not libraries OR frameworks. Real-world complex applications can use both.
I think they'll be using libraries either way. But they do have a choice whether to be completely dependent on a framework, and that's a pretty serious choice to make if it's a long-term project.
> My previous comment about "unnamed invisible frameworks"
I don't have a lot of experience with JS other than playing around with it every few years and discovering that none of the things I used last time are in use anymore. It scares and confuses me. But yes, if you write a lot of similar software projects, a framework is probably the way to go if you want to avoid writing the same low-level stuff that has been better written and definitely better tested by the framework people.
And yes, writing my own "invisible" framework is a bad idea, in my own experience too!
But that's why I'm trying to move away from the whole concept of having my code in some sort of harness in the first place. A lot of the repeat-y stuff can be handled by libraries just fine!
Fair enough, even though it's hard to point to a specific piece of code when talking about such abstract concepts. And I'm not working on any open source projects.
My go-to example is dependency injection and ASP.NET Core. For the most part, I really like the features and it's mostly okay as a framework, even though I'm not sure why it has to be one. When I started taking clean code and DI more seriously, I learned that ASP.NET Core gets these things wrong in a subtle way that turns the whole idea of DI into a bit of a farce. This post explains it really well:
https://blog.simpleinjector.org/2016/06/whats-wrong-with-the...
I wish there was an easy way of removing the "framework" aspect from that thing and just have a bunch of libraries for handling HTTP requests, rendering pages, dealing with security and so on.
> A good framework that fits the problem domain does a lot of low-level gruntwork that frees the programmer to focus on higher-level tasks.
I agree that this is a noble goal, and I'm sure there are plenty of frameworks that are good enough. But sometimes you don't have a lot of choice, and in the worst case all of the useful libraries for your domain depend on a framework that you don't really want to use.
> It's not libraries OR frameworks. Real-world complex applications can use both.
I think they'll be using libraries either way. But they do have a choice whether to be completely dependent on a framework, and that's a pretty serious choice to make if it's a long-term project.
> My previous comment about "unnamed invisible frameworks"
I don't have a lot of experience with JS other than playing around with it every few years and discovering that none of the things I used last time are in use anymore. It scares and confuses me. But yes, if you write a lot of similar software projects, a framework is probably the way to go if you want to avoid writing the same low-level stuff that has been better written and definitely better tested by the framework people. And yes, writing my own "invisible" framework is a bad idea, in my own experience too! But that's why I'm trying to move away from the whole concept of having my code in some sort of harness in the first place. A lot of the repeat-y stuff can be handled by libraries just fine!