The MicroPHP Manifesto

Most mega-frameworks pat themselves on the back with examples that declare "See, you can write an entire CMS in 10 lines of code!" That's impressive except you can't write anything else and extending the CMS requires that you read and understand 100 pages of framework API entangled with assumptions and design tradeoffs that expertly fit the author's needs and not necessarily yours.

The problem is that the ideal framework requires zero lines of code because it already solves your exact problem. The worse framework requires more lines of code than coding your application from scratch. So, the key is finding a framework that satisfies 80% of your needs easily and doesn't get in your way for solving the other 20%.

The movement toward smaller, decoupled and interoperable libraries in the PHP community is in general a good thing.

But without a widely adopted PHP package-management system using many micro libraries becomes more complex to manage than a big all-in-one framework. We need something like NPM for PHP. Maybe PEAR 2 can get us there.

I agree that for big jobs, you can't prioritize pretty over featureful, but, respectfully, I think you are overstating your point here: "doesn't ever work." That's simply not true. Have you really never written a working program without a full featured framework?

I think one of the points that isn't clearly enough articulated in this article, but is very significant for me, is code understandability. Probably my biggest issue with CakePHP (what I use) is that when you step outside the standard use cases you fall down a rabbit hole of complexity and peculiar idioms. The result here is that one becomes a "Cake developer" rather than a "PHP developer"; there is a high degree of lock-in and switching the entire toolset becomes difficult and impractical. So the idea being suggested is allow people to switch out tools one by one rather than start over with a new, incompatible set if they need some lower level change.

What I see in this post that I agree with is the idea that PHP tools should be more modular and decoupled, so you can grab a full stack bundle if you want, but can use modules piecemeal if you don't. Currently, the latter option is lacking in PHP. I don't think anyone's saying "down with frameworks" as much as "hey, let's get some do-one-thing-well tools as well, so the piecemeal/modular option is also there."

It seems to me that what he is trying to do is something like setting up a simple contact form using Java, Spring and Hibernate, and by this I don't mean that he codes silly stuff at all, but that if he feels this way he's just picking the wrong tools for the job.

I don't know anything about music but I also think that the analogy he used is wrong. Black Flag may do great music with much less equipment, but I doubt that with that drum kit the drummer would be able to do the same sounds or have the same precision as the drummer with the huge kit would.

Does OP know why Neil Peart needs all that stuff? I assume Neil wouldn't be able to play the same things in a minimalistic set up.

If you don't know what all the framework's "boilerplate" is for and you just want to get your application running, why are you using a framework in the first place? A framework is supposed to do stuff for you that you would have to otherwise do manually. If you don't normally do the stuff the framework does for you, don't use it.

There are plenty of quotes in there that I strongly disagree with (the commitment stuff mostly), but I think I can sum it up with saying that just because you can do great things with less it doesn't mean that having more is bad. Just learn to pick the right tool for the job.

edit: jrockway is spot on regarding code quality.