[patricklouys]

That's not true. I've worked on large applications with frameworks (CodeIgniter, Symfony) and without frameworks (but with composer packages). In the beginning you might spend a little more time on wiring things together, but on a large enough application your framework will always get in the way somehow and you will have to find workarounds.

For large projects, I strongly prefer a frameworkless approach. If you do throwaway apps for an agency, then a framework is probably the better choice.

[ubernostrum]

You chose a set of libraries. You installed them. You used them. And by "used them", I mean you wrote code which called into them and which wired together all the various pieces to make a coherent web application. I know you did this, because if the libraries had come with a magical "make all these things work together" function for you to use instead, you would have dismissed that as a framework.

You don't want to call that combination of libraries and in-house wiring-together code a framework. I get that. But that's what it is, whether you want to call it that or not.

And I'm sure that you don't see it as a maintenance burden right now. It never feels like a framework or a burden at first, because it's all made up of this code that you wrote and that you understand and that you control, and it feels great! For a while, at least.

But sooner or later you will realize you have built your own in-house web framework, and that now part of your business is to be a web-framework developer, instead of a whatever-your-company-actually-needed-to-make developer, and that being a web-framework developer is not a very fun business to be in.

And you will hire more people, and they will have to be trained on this thing-you-refuse-to-call-a-framework, but they'll recognize the patterns sooner or later, and will wonder out loud why it's missing this or that feature that the off-the-shelf frameworks have out of the box, or why this particular part of its API is so weird and cumbersome (it made sense back when the codebase was much smaller and only a couple people worked on it, you'll tell them, sheepishly).

And maybe some of them will roll up their sleeves and try to add what's missing or clean up the historical weirdness, and maybe some of them will get tired of working on this thing that won't add to their résumé and leave, and others will just do their best to get work done, but at a much slower pace because they're working with a framework built by people who hate frameworks, and still others will start to agitate for just going and getting a proper framework off the shelf and using it already, and you will end up having some very interesting and perhaps very heated team meetings, and you'll realize that you're spending way too much time as a team talking about tools and technologies and not nearly enough talking about products and bugs and features and this is not going as well as it was back when everything seemed so simple and easy in the world of "frameworkless" development.

This is the iron-bound web developer's counterpart to Greenspun's Tenth Rule, and in my experience there is no escaping it.