A (fond) farewell to Zend Framework(alexhudson.com)
alexhudson.com
A (fond) farewell to Zend Framework
http://www.alexhudson.com/2012/03/24/a-fond-farewell-to-zend-framework/
13 comments
It's funny you keep referring to Java as the example for over-engineered code. That's true if you look at the built-in stuff, but if you look at frameworks like Play, it's not so bad.
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.
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.
Just to be clear; I realise my comments alluding to Java were extremely lazy short-hand - I did specifically call out Play right at the end as an example of a Java framework for which over-engineering wasn't really the case.
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.
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.
>It's funny you keep referring to Java as the example for over-engineered code. That's true if you look at the built-in stuff, but if you look at frameworks like Play, it's not so bad.
Yes, but the above roughly translates to: "if you look at Java OUTLIER frameworks, it's not so bad".
Yes, but the above roughly translates to: "if you look at Java OUTLIER frameworks, it's not so bad".
And honestly, if I wanted to program Java, I’d use Java.
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 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.
This. If you want some "real PHP", look into the MicroPHP manifesto (http://microphp.org) and the libraries/frameworks associated.
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, 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 looked at ZF a few years ago, it appears that most of the components are fairly loosely coupled so there's no reason to use the whole framework.
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.
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.
You know, from the get go one of the goals of ZF2 was simplicity, though it sounds like it's regressed in that area. Speed was another goal. Though at the present, that's regressed as well:
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?
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?
It feels a bit trite of me to make many of these criticisms when the "proper" way, really, would be to get involved with the project and attempt to engage developers directly. Unfortunately, I don't really have the time to contribute in a meaningful way (i.e., code), and I'm very much of the opinion that people who write the code get to make the decisions.
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.
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've never used ZF as a full stack framework, exactly because of its complexity, but I've plenty times used selected components from it. It makes a very fine component library in that sense - I just hope they don't mess that up with ZF2.
Agreed, I've done the same. That's also why I don't shy away from the idea of rolling my own framework. I've had to take some ZF components, like Zend_PDF and Zend_Mail, and add them to my own code before. It's easy, and obviously relieves the stress of having to roll such components on my own.
> Not much of a difference, but I wonder what was wrong w/ZF1's less verbose alternative?
Might have wanted to reduce the API surface for the `this` (by removing extra methods which can be reached indirectly).
Might have wanted to reduce the API surface for the `this` (by removing extra methods which can be reached indirectly).
If you want great performance, consider writing an Nginx module in C. It's reasonably easy to get started!
Well, my mention of ZF2's performance drop was more so to supplement a seemingly regressing nature of ZF2.
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.
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.
Hiphop is not the same as writing your application in c++. nothing like, not a useful comparison.
They are your latency bottlenecks, but your throughput bottleneck is almost certainly PHP.
> Injecting the plugin broker for controller plugins into the action controller for use by all controllers that extend it
Awesome phrase.
Awesome phrase.
Awesome, indeed. What does that mean, though?
I'm guessing — but that's really a guess with no knowledge of the thing — it's some sort of middleware thingie: the "plugin broker" is used to register plugins, and in this case any controller inheriting from `Zend\Mvc\Controller\ActionController` will get the same broker, therefore all plugins registered into `Zend\Mvc\Controller\PluginBroker`. I'm guessing it also handles calling the right plugins at the right moment in the controller's lifecycle. Something like that.
It was this kind of over complicated, verbose nature that turned me off Zend 1 when I was first looking into frameworks, and ultimately led me CodeIgniter.
Shame to see Zend 2 gone even further in this direction, I'll be happily sticking with CI.
Shame to see Zend 2 gone even further in this direction, I'll be happily sticking with CI.
Like the author, I tried to like ZF2.0 - I failed for almost the same reasons.
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?
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?
ZF2 might be bloated but it is supported by Zend and have a lot of great and stable components. Stop trying to make a framework by yourself and start contributing to make things change ! (moreover, you don't even need to sign a CLA to contribute to ZF2).
(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 :)
(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 :)
Looking at things like the Doctype class is not the best way to evaluate a framework. How often do you set a doctype? Once. And seeing how many site have a broken doctype because the developers tried to be smart... probably not the worst idea.
Look at how it translated to real project usage.
Look at how it translated to real project usage.
Does anyone still remember back in the days they were marketing Zend Framework as "Extreme Simplicity"? ;) http://fredwu.me/post/19888742513/zend-framework-from-extrem...
Zend seems to be created by people who hate web technology so much that they abstract themselves away from it. Developing on it is like fighting against a windmill.
Man, this looks like Zope 3, err, BlueBream.
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.