Yes, it is all an ad-hoc framework. There are no large frameworkless projects. Programming languages don't come with enough abstraction to model a large domain (unless you're using a 4gl, but those are semi-frameworks). You always end up building or reusing additional abstractions, and those collectively are a framework. The framework can be procedural, functional, declarative, oop, mvc, or any of dozens of additional buzzwords, but you cannot avoid having one.
Anyway, my point is that if you're working on a non-trivial solution in a problem domain that other people with good design skills have built frameworks for (like web dev, the most oversolved domain in software, aside from text editing), it doesn't make economic sense to roll your own. Even if you have the rare trait of good design, the productivity benefit for yourself by having a more closely adapted framework is washed away by the cost of building it and having to bring other people up to speed on it. I've had the experience of lots of home-grown framework code, and rolled my own quite a few times, and the longer i've had to observe other developers working on that code the more convinced i've become of NIH being a programming anti-pattern. It can make sense to roll your own, but for the majority of web dev programming it doesn't. There may be categories of software dev where the statement inverts though, i'm not going to generalize too far.
What i however also think is that many of today's frameworks are overengineered and force you to write too much code to solve a problem. They suffer from tdd-induced design damage, as dhh would describe it (the recent discussion between fowler, beck and dhh was enlightening). Many frameworks have optimized for secondary goals like orthogonality or compliance to design patterns instead of primary goals like fitness for purpose, speed of development, maintainability, and usability of the resulting product. However, i'm of the opinion that even given all that, for general web dev and for most people, it's better to use one of the common ones than to roll their own. They'll build a more maintainable solution in less time.
Anyway, my point is that if you're working on a non-trivial solution in a problem domain that other people with good design skills have built frameworks for (like web dev, the most oversolved domain in software, aside from text editing), it doesn't make economic sense to roll your own. Even if you have the rare trait of good design, the productivity benefit for yourself by having a more closely adapted framework is washed away by the cost of building it and having to bring other people up to speed on it. I've had the experience of lots of home-grown framework code, and rolled my own quite a few times, and the longer i've had to observe other developers working on that code the more convinced i've become of NIH being a programming anti-pattern. It can make sense to roll your own, but for the majority of web dev programming it doesn't. There may be categories of software dev where the statement inverts though, i'm not going to generalize too far.
What i however also think is that many of today's frameworks are overengineered and force you to write too much code to solve a problem. They suffer from tdd-induced design damage, as dhh would describe it (the recent discussion between fowler, beck and dhh was enlightening). Many frameworks have optimized for secondary goals like orthogonality or compliance to design patterns instead of primary goals like fitness for purpose, speed of development, maintainability, and usability of the resulting product. However, i'm of the opinion that even given all that, for general web dev and for most people, it's better to use one of the common ones than to roll their own. They'll build a more maintainable solution in less time.