PEAR vs. Zend Framework

PEAR vs. Zend Framework

Now that the Zend Framework is ready for ‘prime time’, I’ve been considering the Pear framework with regards to how it now fits in the PHP world.

zend framework logo

NOTE:

Several picky nerds have pointed out that PEAR is not a framework – check out the comments below. OK, I would agree, technically speaking, PEAR is not a framework. That said, this is what the PEAR people say on the home page of their web site:

‘PEAR is a framework and distribution system for reusable PHP components. You can find help using PEAR packages in the online manual and the FAQ.’

Anyway, that is an argument of semantics and nerd-details … not the point of my article.

… Back to my article:


Both Zend and Pear are frameworks but how are they different?

I would say that the Zend Framework attempts to create a comprehensive whole – a consistent set of components that are designed to work together in a unified manner.

… That is one of the reasons for a framework in the first place.

Though unified, one of the cool things about the Zend Framework is that you can just pick and choose what components you want to use – you don’t have to buy the whole cake to take advantage of all that juicy object oriented PHP code.

About PEAR:
pear-framework-logo

With the Pear framework, it is more of a hodgepodge/motley of assorted components. Pear is widely used (and useful) but it does cross over (in terms of functionality) with what we have in the Zend Framework. So the question that comes to my mind is:

Do we still use Pear, if we have the Zend Framework?

The simple answer is found in the version of PHP you are using:

If you are using PHP 4, you will have to use PEAR since the Zend Framework depends on PHP 5. Remember that PEAR does predate the Zend Framework.

And on the flip side, if you are using PHP 5, you might as well favor the Zend Framework since it is a comprehensive unified framework.

While considering this question (PEAR vs. ZEND Framework) I struck up a conversation with Jonathan about this … I thought it was worth including here:

Hi,

I was wondering what you thought about Pear given that Zend is out?

… Is there cross over or does Zend leverage Pear?

Thanks,

Stefan

Jonathan Lebensold wrote:

From what I’ve seen there’s no dependency with Pear in Zend. Although Zend appears to be a higher-level functional replacement for Pear. (Pear kinda sat between what you would expect php to provide you in extensions and what would facilitate a developer in writing applications. That distinction is now made through extensions / PECL (C libraries) and Zend)

J.

From what I can see, if you are using PHP5, Pear is no longer needed because of Zend – would you agree?

Stefan

Jonathan Lebensold wrote:

I think that pear will be deprecated since it was unreliably deployed on webhosts (which led people to dumping instances of the whole PEAR framework into their applications.. mind you that’s what people are doing with ZEND).

I would say that PEAR is on the downward slope, but a lot of legacy code depended on it (especially from PHP4 era). newer applications should look towards independent classes (like the ones at phpclasses.org) or solutions provided in frameworks (like smarty / zend / cake / etc…)

j


Conclusion:

We’ve developed a couple of Web 2.0 applications with beta versions of the Zend Framework and I think we made a good choice:

… Even with that early version of the framework, we found it to be very useful and worth implementing.

Another bright spot, was that we got new developers productive with the Zend Framework rather quickly. A nice change from what I had to deal with during my Java days! Did I say Web Objects sucks?

:)

Anyway, I’m excited to explore the latest releases of the Zend Framework and to write more about it as time permits.

Thanks for reading,

Stefan Mischook


This entry was posted on Friday, March 14th, 2008 at 12:20 am and is filed under Advanced PHP, Zend-Framework. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

17 Responses to “PEAR vs. Zend Framework”

  1. Michael Gauthier says:

    I don’t think PEAR will be going away any time soon.

    All new packaged proposed to PEAR must be PHP5 and there are many packages available in PEAR that are not available in Zend Framework. Additionally, the pear installer tools let you easily pick-and-choose what components you want and it also handles updates, dependency resolution and installation.

    In my ideal fantasy world, the components of Zend Framework would be packaged and distributed over its own PEAR channel as separate packages with interdependencies. I think that’s already been discussed several times on the mailing list so I’m not holding my breath.

  2. Vincent says:

    PEAR has been flawed from the beggining. There are some really nice packages in PEAR, however, they are tied with the heavy PEAR.php and some general components, which makes using these sometime lightweight packages a pain to deploy and a performance hog.

    PEAR has also been very hard to deploy. Don’t tell me the command line package management is something reliable.

    Now when I look at external components, I always try to find some standalone components or some PECL packages.

    I can even write my own component, just for not having to deploy the whole PEAR stack with my application.

  3. Ken Guest says:

    from what I’m lead to believe with Zend you install all-or-nothing, and this is also implied in Michael’s comment, whilst with PEAR you only need install what is necessary….

  4. Wil Sinclair says:

    I think there may be a little confusion between runtime dependencies and packaging. We package ZF as single tarball, and that is currently the only Zend-driven distribution mechanism. That said, many of our contributors have created alternate distribution mechanisms and channel- even a PEAR channel (although AFAIK it doesn’t break ZF components down in to separate packages). But you don’t have to use all of these components in your app. We keep them loosely coupled so that including files from a particular component won’t include the entire framework; most of our user drop the whole thing in to place and include what they need. Ultimately, a few extra MB’s on a hard drive is not a big deal for most developers/sys admins. But you can always pull them apart yourself as necessary. It should be fairly easy if you iterate through a ‘remove stuff, test it’ loop a few times. I hope that sheds a bit of light on that topic.
    As far as ZF replacing PEAR? I really don’t see Zend replacing PEAR- or any other PHP framework/library- any time soon. The PHP world is huge, and there are enough devotees of each framework to keep them going. I personally think this is great- we end up with the right solution for the right people/problems and we can cross-pollinate some ideas to make the PHP world a better place in general.
    BTW, our current take on a PEAR channel is that we would love to see one and we’d love to host it eventually, but currently we do not want to add the overhead to our release cycle. We want the release process as lean and mean as possible so we can release early and often. I have said multiple times on the mailing list that if someone from the community were to establish one and show some dedication to keeping it updated, we would talk to them about hosting it.
    Thanks for the great comparison/discussion. Hope to see some of you on the ZF mailing list soon!

    ,Wil

  5. Stefan Mischook says:

    Hi,

    “Ultimately, a few extra MB’s on a hard drive is not a big deal for most developers/sys admins.”

    I would agree with that entirely. Disk space is cheap …

    My liking the decoupled nature of the Zend Framework (a great design decision IMHO) has nothing to do with disk space, but rather with being locked into a bunch of stuff I don’t want to use.

    Other frameworks I’ve used in the past, forced you to eat the whole meal … sometimes its’ cool to be able to grab what you want (and leaving the rest) at the buffet table.

    Stef

  6. One of the big things I love about ZF is that I can use Zend_View without pulling in Zend_Db or Zend_Controller.. this has saved me when trying to extract an alternate view of an application, or simply rendering my pages as static content from a command-line php application.

    PEAR has a lot of momentum, however I think a lot of the weaknesses come from a lack of understanding from web hosts. I know that most PHP developers started their development from the incredible wealth of comments and samples on the php.net site for each method. I love being able to do an “I’m Feeling Lucky” search with ‘substr_replace php net’ and get over 100 different samples on how to apply substring replace plus derivatives using regex and a 2 year history of practical examples.

    PEAR has none of this and I think it leaves a lot of developers a little wanting. It’s interesting to look at the history of the Zend Framework and how during the RC days, it had a similar model, where you would load in the Zend.php file and it was an aggregate root into the Zend Framework. It’s really nice to see that the Zend Framework architects moved away from this model. Regardless, I’d still like to see further decoupling for things like Zend_Layout and Zend_View (I know there’s a strong Smarty community out there). While Zend_Db is miles ahead of doing straight SQL through a $db object, I still would like to see Hibernate (a Java persistence layer) fully integrated into a Zend frontend, and sufficient community / documentation to support this kind of integration.

    PEAR always seemed to me to be a one-size-fits-all solution, with projects gaining steam and then fading for months at a time (PEAR’s server-side form implementation comes to mind…)

    j

  7. Mohammad Elkersh says:

    I do not think that PEAR can be replaced.
    for example
    the package HTML_QuickForm is the best ever package for building forms and i do not know any comparable package (Except Symfony Form Helper which is bundled with symfony)

    If you campare it to zend_form you will find that zend_form is still in the very early stage

    I think that when i start using ZF i will only use the MVC functionality (Zend DB, Zend_View, Zend_Controller)
    and use pear for every thing else

  8. » News Updates Flusensieb says:

    […] PEAR vs. Zend Framework […]

  9. Jon Lebensold says:

    Mohammad,
    I don’t think a replacement for PEAR will come anytime soon, however HTML_QuickForm is a dying project. According to their own PEAR site, HTML_QuickForm has now been superseded by HTML_QuickForm2 and they’ve gone from 6 maintainers to 2. Matthew’s Zend_Form contribution, while young, has a lot of demand and the Jira tracker is buzzing with comments and improvements. While I’ve developed applications using HTML_QuickForm in the past, personally, I wouldn’t bet my next client’s money on it.

  10. […] My favorite Zend Framework related article this week was Pear Vs. Zend Framework I don’t agree with everything in th article but I do think the Zend Framework was misnamed it should have been Zend Repository. Actually I find some good in both , I just don’t think inclusion in either is automatic commendation from the best practices gods. The comments on this article How Zend Framework is Losing the wrong war leaves me wondering even more is it a framework or not? It kinda sorta is but not. […]

  11. Daniel O'Connor says:

    I have to say, I’ve dabbled with both PEAR and Zend Framework (albeit in the early days, leaving just prior to 1.0).

    I didn’t find a compelling reason to switch to Zend Framework. Infact, as an early consumer of Zend via the PEAR channel; then having it go away all of a sudden, I was quite a bit disgruntled.

    I also found the CLA (http://framework.zend.com/framework_cla_1.0.pdf) a bit of an affront – why do I need this when I have BSD style licences? Why do I have to fax it in?
    I know the answers to these questions, but I don’t agree with or like them.

  12. Lothar says:

    I come across PEAR now for the first time. And i’m surprised by this discussion because i had a total different understanding of PEAR the
    “PHP Extension and Application Repository” which has nothing to do with a framework other then that it may contain a few frameworks.

    Looking at it like RubyGems, CPAN or Python Eggs.

    So i do not understand this discussion.

    My first impression about PEAR is unfortunately that it is very broken and unprofessional (well like 95% of PHP). Documentation is bad and the installation on windows is in just one word insane – and there i don’t mean faulty but from a damaged brain.

  13. Stefan Mischook says:

    Lothar,

    I would agree, technically speaking, PEAR is not a framework. But this is what the PEAR people say on the home page of their web site:

    ‘PEAR is a framework and distribution system for reusable PHP components. You can find help using PEAR packages in the online manual and the FAQ.’

    Anyway, that is an argument of semantics and nerd-details .. not the point of my article.

    I also agree that RubyGems is cool.

    All that said, I think that PHP is a number one web application development language when all things are considered. Yes, Ruby is a cleaner looking language and ColdFusion is easier to learn. But again, PHP overall has the most to offer IMHO.

    Want to see good OO PHP projects? Check out:

    Zend Framework
    Wordpress
    PHP Cake

    … and there are more. There are also nice procedural based PHP projects:

    – Drupal
    – Punbb

    So yes, PHP has a legacy to contend with. But the new breed of PHP projects and programmers are good.

  14. Jon Lyles says:

    One of the things that makes PHP easy to learn is there are so many places to get information.

    One of the most frustrating things about PEAR in my point of view is the scarcity of information.

    I predict that unless PEAR becomes more user friendly it will slowly fade away as new developing opt for easier to use frameworks and repositories.

  15. Josh Ribakoff says:

    Technically a framework is not the same thing as a toolkit, one is abstract, tools for making tools, the latter are just tools. An analogy would be a saw is a tool, but a jig that sets up “programs” for cutting complex patterns autonomously would be a framework. That being said I agree PEAR is a MESS. <3 ZF

  16. Aryashree Pritikrishna says:

    I am support to ZEND framework. Its better than PEAR framework.

  17. Chris Code says:

    When we looked at PEAR it seem as if anyone could submit code into the repository, and after looking at some of it, we were very dissapointed; we never used PEAR.

    However, ZF is by Zend, who “invented” PHP – and therefore we can hope that best (industry) practices will be used across the framework, including of course Security.

Created By Stefan Mischook  |  Top of page  go to top of page