In regards to missing deadlines, etc, if you don't use frameworks: No, it would actually be faster, and the code would be smaller, because you can design it intentionally (more on this in a bit).
There is skill in knowing when (for each thing or at each layer) to use a well designed tried and true library versus rolling your own, but in either case that's about composable units that you use to fill in holes of meaning (aka abstractions) in your program.
With frameworks, it's the reverse: You fill in the holes of something that's not the thing you are designing (how could it be?), and which must deal with 1000 other things that do not apply to your project, but affect what you get and how you must use it.
In either case, the software being developed exists solely to model and enact some specific human value, which must inevitably be designed and delivered.
So the real problem is actually not about frameworks per se, but that that design is rarely ever direct or intentional. Instead you get (in either case) a mess of mechanisms & patterns from which the desired model/behavior is supposed to emerge (e.g. by slicing it up among these things and rigging it to trigger in some clever way). It doesn't have to be either a bunch of kooky pattern(s) and mechanisms or a framework that does it for you. Just regular old programming paraphernalia, and good old abstractions of the actual human value.
Any decent program can be built on a simple foundation of abstractions that are fairly 1:1 with the human understanding of what the software is, and what it does (which are two separate things, btw). And those upon lower level abstractions, etc. But at each level, you are making components that compose like libraries, NOT a framework, and not a clever wire-up of a bunch of "patterns" (e.g. AOP).
But as soon as you break any of those rules, you get an incoherent mess. And unfortunately this stuff (which should be basic fundamentals) is not taught or understood very well, and many programming languages, paradigms, patterns, tools, and frameworks violate and/or encourage you to violate one or more of these.
And so frameworks only solve an artificial problem, while making it more impossible to address the fundamental problems they fail to solve, because the backbone of your software is now this framework instead of a codafied model of the value it's supposedly designed to deliver.
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.
In regards to missing deadlines, etc, if you don't use frameworks: No, it would actually be faster, and the code would be smaller, because you can design it intentionally (more on this in a bit).
There is skill in knowing when (for each thing or at each layer) to use a well designed tried and true library versus rolling your own, but in either case that's about composable units that you use to fill in holes of meaning (aka abstractions) in your program.
With frameworks, it's the reverse: You fill in the holes of something that's not the thing you are designing (how could it be?), and which must deal with 1000 other things that do not apply to your project, but affect what you get and how you must use it.
In either case, the software being developed exists solely to model and enact some specific human value, which must inevitably be designed and delivered.
So the real problem is actually not about frameworks per se, but that that design is rarely ever direct or intentional. Instead you get (in either case) a mess of mechanisms & patterns from which the desired model/behavior is supposed to emerge (e.g. by slicing it up among these things and rigging it to trigger in some clever way). It doesn't have to be either a bunch of kooky pattern(s) and mechanisms or a framework that does it for you. Just regular old programming paraphernalia, and good old abstractions of the actual human value.
Any decent program can be built on a simple foundation of abstractions that are fairly 1:1 with the human understanding of what the software is, and what it does (which are two separate things, btw). And those upon lower level abstractions, etc. But at each level, you are making components that compose like libraries, NOT a framework, and not a clever wire-up of a bunch of "patterns" (e.g. AOP).
But as soon as you break any of those rules, you get an incoherent mess. And unfortunately this stuff (which should be basic fundamentals) is not taught or understood very well, and many programming languages, paradigms, patterns, tools, and frameworks violate and/or encourage you to violate one or more of these.
And so frameworks only solve an artificial problem, while making it more impossible to address the fundamental problems they fail to solve, because the backbone of your software is now this framework instead of a codafied model of the value it's supposedly designed to deliver.