A (fond) farewell to Zend Framework
alexhudson.com
alexhudson.com
The sole strength of php is that you can drop a file with the literal words "hello world" in your web root and there you are.
Yes, you'd want to impose some structure as your application grows beyond that, but if your application ever needs this level of structure you better hope you aren't writing in php to begin with.
You can do the simplest page or a complex MVC application, with the same language on the same server stack.
That said, I completely agree with you on ZF2 being a complete mess. If you've ever used Magento, which is built on the Zend Framework and who partners pretty close with Zend, you'll see some of these ridiculous development practices in reality. At some point, the cognitive load of keeping track of all the various files and object structures has really got to outweigh any benefit of flexibility you might have. And what's really scary is there is some good, useful code locked away inside of these nightmarish libraries.
I would suggest looking at Symfony. They are taking a modular approach that lets you pick and choose the bits from the framework that you want, rather than having to take everything. You might find it kind of refreshing.
Thankfully I haven't had much exposure to Magento, but your comments chime with things other people have said - one cynical wag I know declaring that it seemed to be specifically designed with the consultancy business in mind. I have had exposure to SugarCRM, and I could say the same things you just did about cognitive load and development practices effectively being a barrier to entry to some actually quite nice code.
Yes, but the above roughly translates to: "if you look at Java OUTLIER frameworks, it's not so bad".
I had a similar reaction when reading the intro to Symfony this morning. One of the first things you come accross is:
"Namespace X", "Use Y", "request->query(...)"
Which looks one hell of a lot like C# [1]. So is that what these frameworks essentially are there to do - make PHP more Java / .Net like? And if yes, what does PHP bring to the table that those platforms don't (aside perhaps for ubiquity, a big plus if you are planning to distribute your software)?
[1] And I guess Java, but I don't know that at all.
I, as a heavy PHP user, do not like the path taken by frameworks such as ZF or Symfony. It goes against PHP, and what it is meant for. Creates PHP programmer who think every application needs DI, or whatever fancy pattern these frameworks push left and right. And that's not good.
I don't really see the point of building atop a PHP framework anyway, most of the advantage comes from using the ORM and in that area you already have the choice of Doctrine / Propel.
For smallish apps/sites it's easy to write a custom router that will fit your application better than a large unwieldy one built into a framework.
For larger projects you should probably consider not using PHP anyway.
http://www.enrise.com/2012/02/zend-framework-2-performance/
In ZF's defense, the ZF team has stated that they're aware of the performance problems and that they'll look at those at a later stage. However, that, combined w/your review, combined w/the complexity I see every time I view a profiled call stack of a ZF app in KCacheGrind, really make me want to start rolling my own framework. I've done just that w/my JavaScript, and I'm loving the net positive in simplicity and speed. The growing complexity of ZF makes me want to go that direction with my PHP code as well (though I'll probably look at simpler frameworks first, like Lithium) .
In regard to the following line of ZF2 code cited in the post ...
$message = $this->getRequest()->query()->get('message', 'foo');
That line in ZF1 would look like ...
$message = $this->_getParam('message', 'foo');
Not much of a difference, but I wonder what was wrong w/ZF1's less verbose alternative?
That said, it really does seem to me like ZF suffers from a general lack of engagement. There are surprisingly few developers involved in it, and those that are there quite obviously have their heads screwed on the right way around. It's a rare post from mwop that isn't useful/insightful in some way.
I've watched a little from the sidelines, in IRC and lurking the dev list, and it did seem like all the goals were exciting and progressive. So, having come into the game a bit late, I don't really get where it went wrong.
I didn't want to throw out names of alternative frameworks in the article, people are obviously mentioning Symfony and that's clearly high quality, but LoicProcrast's work on Photon has me tremendously excited. It's undeployable for me (right now), but in side-by-side comparison to ZF2 it makes many of the ZF issues exceptionally stark.
I'm really not that demanding when it comes to the performance of a server side language. PHP + APC has been proven to be almost as fast as C++ (well, Facebook's Hip Hop, which is written in C++), and I'd argue that the biggest bottle necks in a web app are always the network latency and the database, so that's where I spend most of my performance tuning.
Might have wanted to reduce the API surface for the `this` (by removing extra methods which can be reached indirectly).
Awesome phrase.
Shame to see Zend 2 gone even further in this direction, I'll be happily sticking with CI.
The ugliness of the escape-character-abuse for namespaces (what were they thinking?!) and the evolution of the Zend Framework 2.0 is what made me look at the ruby and rails stack.
I do not agree with the microphp manifesto for several reasons, but the sheer amount of boilerplate code in ZF2 is getting in the way of "getting things done".
Php's reputation in the enterprise world is not as bad as it used to be, but still has a "Gschmäckle". Why should use php / ZF when I can sell a Spring MVC application?
(note : i'm not related to Zend. We were using ZF1 since the beginning and we are now experimenting with ZF2. And we will not hesitate to contribute :)
Look at how it translated to real project usage.