Before we go any further, let’s check with Wikipedia:

Software bloat is a term used to describe the tendency of newer computer programs to have a larger installation footprint, or have many unnecessary features that are not used by end users, or just generally use more system resources than necessary, while offering little or no benefit to its users.

So what I need to provide is contra arguments that Zend Framework doesn’t do those.

“Large installation footprint”

25.8 MB and 2338 files. This is how much ZF weights and this is usually quoted as the main factor of bloatedness. First of all, 25.8 MB is a joke – full application takes maximum 50 MB. So unless you want to squeeze in 100’s of projects into a shared hosting, size of ZF shouldn’t matter at all. Price of hard-drive and RAM (for APC caches) is so low nowadays, that I don’t even remember last time I checked how much space my project takes up.

Same applies with files count – why would anyone even care how much files it has? As you probably know, PHP doesn’t compile your project into one binary, thus making it a big file. What it does, is it loads external code using include/require statements. Hence, from those 2338 you usually going to use around 300 (based on my tests). One can argue that this is still a lot of files, but this big number of files comes from ZF extensibility. A lot of functionality is separated into plugins, adapters etc.

“Unnecessary features”

ZF has massive amount of functionality: starting from web framework components and finishing up with services classes (I have written more about this here). There is a big chance that you are not going to use all of them, but because all components are decoupled (as much as possible) and as mentioned above, you don’t even notice them if you don’t include those files.

I’m one of those people who think that ZF has too much components, but this is rather my own personal preference rather than a problem. Nevertheless, I haven’t used only a few of available components as once you need something, it’s always very quick to just use it. No need to download anything more or look for available components. For serious components like Doctrine, you probably want to look around, but just for some regular code Zend provides all required features.

“Use more system resources”

This one is hot topic in ZF world. But the point here is that “features = slow”, especially in PHP. This happens because PHP as a language is not that fast and as you start adding more features and code, you get slower code. This where framework’s benchmarks are born, but as Pádraic mentions in his post about benchmarks:

To create a positive benchmark, you need to understand that all frameworks were born as festering piles of unoptimised stinking crap. They were all born bad and get worse with age. This sounds quite sad, but actually it’s an inevitable compromise between performance and features. It’s also a compromise between performance and ease-of-use

It’s inevitable to provide those features that ZF provides and still work faster than other frameworks. So considering the speed of development you need to know how much performance you actually need. Maybe rapid development is much more important? At least it’s for me, and by sacrificing some tenths of a second I can roll out projects in a few days. And as “bloated” definition states, something is not bloated if it provides benefits while using more system resources.

How to make it not bloated?

If you still consider ZF as bloated framework, let me give you some ideas how to make it work for you. First of all – profile, profile, profile! I keep mentioning this every time I talk about performance, but don’t judge performance of something without actually knowing why it’s not performing well. Xdebug helps here as it can provide profiling data, which you then can use to detect slow parts of code. From my experience this is usually I/O – DB calls, file reads etc. Get rid of those and you have some decent performance increase.

A lot of other performance factors come from knowing how framework works internally or really reading manual. For example Zend_Application is kind of slow, but it can be easily optimized by just getting rid of it. But this is only needed if you are running very big application, where every millisecond of execution matters, for normal application you’d hardly get any benefit. This is very ZF’s decoupled components start to shine, as you can just use those which work well and add some special sauce for other parts.

Conclusion

I use Zend Framework extensively, so I’m biased a lot here, but having this much of experience, I can at least judge it objectively (up to some degree). And what I can say is that ZF is not bloated, it can be slower than some other available frameworks, but widely popular method to judge its performance by the number of files it has is just wrong. Of course it’s not the easiest framework to get working with (and get it to perform efficiently), but don’t get put off just by archive size it comes in.

History

First time I have actually built an application with Zend Framework was about a half year ago, if I remember correctly version 1.8 was already around. Although my first applications were more than two years ago, but hey were more than tests and playing with at that time new features. So as I said above, not that long ago I switched most of my company’s code to use Zend Framework, contributed some code and have also started working as Zend Framework consultant (drop me an email if interested), so I think I have a pretty decent experience to judge it.

Before diving in to the analysis, I would like to clarify, that the reasons why I’m not using other frameworks are mainly caused by the fact that I didn’t had a chance to do that. Since I’m usually working with projects lasting more than 3 months, I need to be confident enough to know that after 2 months I don’t need to throw everything away and start from scratch. Also to test a framework for me is not to create a Hello World application, I need to build something serious to know what features are missing and what problems can be a big issue. Nevertheless, I’m planning to do some research sometime.

Advantages

For me the most important piece of software: how customizable it is. As you might have noticed from the posts like this, I usually work with complex web application and would like to have ability to built it from ground up. Zend Framework was perfect for this, because everything is just a collection of building blocks, literally (or loosely coupled in proper terms). I really liked that there is no default or even worse required structure and everything can be configured very easily.

Because I’m also in a position responsible for a whole project, quality for me is very important. I don’t know how other frameworks handle this, but Zend is pretty serious with what’s in framework and how the code is maintained. Starting from requirement to sign Contributor License agreement (known as CLA) and requirement of 80% unit-tests coverage, ending with bug hunt days. Somehow it helps me to have a confidence to rely on the framework, and backwards compatibility has never been an issue (it’s surprisingly good).

Variety of components and libraries makes development faster because I do not need to search for another library (there is also coding standards problem and a lot of smaller libraries are just a bunch of files, without any clear structure). As of today, I probably have used more than 90% of available components and because they tend to share the same configuration style or just work style, it didn’t took long to start using them. For example, just last night I converted whole application to use custom routes (one custom route per action) in about 4 hours, without having done it before at all.

Community is number one best thing of Zend Framework. Apart from contributors, there are thousands of people willing to help and share their knowledge. Usually I hangout in twitter (here), but there are also IRC channels, mailing lists, forums and many more. I’m subscribed to hundreds of PHP blogs and from what I can see, Zend Framework articles are most common and usually in a very good quality. For me web applications development is not just writing code, so having a wonderful community really helps.

Disadvantages

Hard to learn. This is not a problem (any more) for me, but can be tricky when working with others, especially with things like form decorators. Even though Zend Framework has a very good documentation, I would say, that used techniques are sometimes not straightforward for starters and can lead to a very bad code. As with example with form decorators, once you get them, work with forms will be a joy, however at first they seem as pointless complication. I guess the best thing is just read the manual properly (RTFM in more rude words) – you will benefit later.

For some an issue can be that Zend Framework has no scaffolding. In short, scaffolding is a user interface and logic generation based on database description and business logic definitions. If you have used frameworks like Django (my favorite for Python, has perfect scaffolding), you will miss these things and it can be a first “brick wall” for your learning. Zend Framework has Zend_Tool component which provides basic project generation (you can customize it easily), but this is pretty much everything.

Connected to the both issues outlined above, Zend Framework in general is sometimes too much loosely coupled. Because all the components are just separate classes and out of the box you don’t get any sort of web application, one might have problems trying to understand what to do with all this stuff at all. It’s a great feature for me, but for someone not having any experience with Zend Framework it is probably impossible to build application without a help of blogs, books or (my recommendation) manual.

As you might have guessed, the fact that Zend Framework has lots of components also means that there should be enough developers to support them. However, this is not always the case and some components are really lacking new features or updates. For example Zend_Pdf is quite out-dated and not moving as fast as a lot of us would like to. But hey, it’s an open-source framework, so if you have ideas of how to improve things – you are free to do, believe me, it’s a great fun to contribute to such a influential software application. Nevertheless, always evaluate available components and choose what’s best for your project.

There is also the funny part – misconceptions and myths. I’ve just started working on a new article about these, so expect some interesting things very soon.

Conclusion

I hope it’s clear, that most of the advantages and disadvantages are coming from the same root – depending on what experience you have and what you are looking for Zend Framework can be a good or absolutely awful choice. For me it’s a perfect tool and currently I have no plans (even though Symfony is in my todo list) to use something else, and if you look at things which are coming in version 2.0 of both Doctrine and Zend Framework (yes, they will have integration)… Simply a good solution for serious work.

I have been using Zend Framework for some time now, and found that only possible way to use XmlRpc Server package is to delete all functions signatures checking. My production server has Zend Optimizer installed and it just breaks Reflection functionality.

For tests I created simple reflection example:

/**
 *  My Class
 */
class test { }
 
$oClassReflect = new ReflectionClass("Test");
print $oClassReflect->getDocComment();

First time script outputs:

/**
 *  My Class
 */

Next times there is no output at all – all comments are gone (in Optimizer’s cache). I still can get methods of class (source code is not gone), but I cannot use comments to mark params/return types and later use them to validate I/O.

I don’t know yet if it’s a problem with my production server, but Zend manuals are not very clear and I can’t find any information about comments stripping issue. Has anyone had similar problems?