>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.
Totally agree. But that's because of poor design in CakePHP (I used it too).
>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.
Actually, it's not. Take a look at Zend Framework and you'll see that you have a TON of modules for doing all kind of stuff and if you want you could use just the core ones and ignore the rest. It works so well that I even use components in non-Zend Framework projects.
Re:The MicroPHP Manifesto
by josegonzalez on Tuesday January 03, 2012 @03:19PM
(#3421143)
Please explain reasoning behind CakePHP having a poor design. I'm curious as most people that say a framework or tool sucks actually are just using the framework/tool in an incorrect way, and there is frequently an elegant way to tackle their issues. This applies to more than just CakePHP, mind you.
Sure, but you don't always have the time to figure out what that elegant way is. This is the reason people complain about the complexity of frameworks.
symfony2 (which the OP picks on a little bit) has taken exactly this approach, there's much more emphasis on the components than the framework as a whole.
Re:The MicroPHP Manifesto
by OstiaAntica on Tuesday January 03, 2012 @06:08PM
(#3421752)
Even better, other PHP projects, like Drupal, are planning to use Symfony2 components. Symfony2, with its "bundle" concept, holds huge promise for the PHP community and eco-system.
The problem I see with this is that it only has benefits for huge apps. If you're just getting something off the ground, debugging a 100-line stack trace for every little issue starts to kill your flow real fast.
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."