The Future of Zend Framework is Solar

I have said it before and I’ll say it again now: If you want to see the future of Zend Framework, look at the Solar Framework for PHP 5.

FYI: This is a cheerleading post. Some will be annoyed by it or find it “unfair”. Others may find it informative and enlightening. I make no apology for advocating what I think are the good things about Solar, especially when other projects appear to be mimicking those things.

I noticed that Matthew posted the ZF 2.0 roadmap yesterday:

Solar is already doing most of what is described as the future for Zend. Let’s go over this, shall we?

Unified constructor. All constructors will (optionally) accept an array of options or Zend_Config object as the first argument. This allows for more flexibility to add new arguments to the constructor, have variable numbers of arguments, and allow “named” arguments. Additionally, it’s a good technique for allowing Dependency Injection.

Solar has had a framework-wide unified constructor for years now. As far as I know, Solar is the first PHP framework to demonstrate this design pattern and give it a name. You can have a unified constructor right now with Solar.

In addition, we already have a unified dependency injection and service locator implementation, via the unified configuration mechanism and a lazy-loading registry. You can have DI/SL right now with Solar.

Options. In ZF 1.X, the various components which accept options accept a variety of formats: some expect underscore_separated keys, others expect camelCasedKeys, others expect UPPERCASEDKEYS, and some expect lowercasedkeys. This leads to confusion for many, and also leads to difficulties debugging. Our goal in ZF 2.0 is to standardize option keys to correct this situation.

Currently, we are leaning towards all_lowercase_underscore_keys.

Solar has already standardized on its config keys as lowercase-underscore. You can have standard config keys right now with Solar.

Exceptions. Each component will have an Exception marker interface, with exceptions defined for discrete exception types thrown by the component. The concrete exceptions will either extend the global Exception class or an SPL Exception, and also implement the component Exception interface.

Solar provides a unified exception mechanism already. This is not quite the same thing as described in the ZF2.0 document, but if the idea is to have a unified way of throwing and recognizing exceptions, Solar is already doing it.

Design By Contract.

OK, we don’t really do this. Solar tends to use adapters, plugins, class stacks, and duck typing, not interfaces.

Elimination of most singletons.

Solar doesn’t use singletons. We use the registry and, occasionally, unified static-method-collection classes. You want two or more database connections? Mark them for lazy-load in the registry, and set your config file to use the appropriate service locator keys for whatever objects may need them. You can have this right now with Solar.

Creation of components for general-purpose, cross-functional actions. A number of components duplicate code, and we want to push the duplication areas into discrete components that the original components may then consume. Some of these include:

  • Plugins/Helpers/Strategies (seen currently in Zend_Controller_Front, Zend_Controller_Action_Helper, Zend_View (helpers and filters), Zend_Form (validators, filters, and decorators), etc.). Plugin discovery and loading could benefit from a common API.
  • Decorators (seen currently in Zend_Form; other areas could benefit from the pattern)
  • Factories (seen currently in Zend_Db, Zend_Navigation_Page, Zend_Auth, Zend_Translate, Zend_Cache, etc.)
  • Caching (seen currently in Zend_Translate, Zend_Locale, Zend_Queue, Zend_Paginator, Zend_Feed_Reader, Zend_Db_Table, etc.)

Solar already has a standardized factory mechanism and a standardized adapter approach. With the lazy-loading registry and DI/SL mechanism we can inject a cache object into any other object that’s ready to receive it. You can have these right now with Solar.

(In fairness, we don’t use decorators much, and the plugin systems are more a standard approach using class stacks than an encapsulated system.)

Usage of new language features within plugin architectures.

Solar isn’t on 5.3 yet, but then, neither is Zend Framework.

Autoload-only. We will move to using autoloading throughout the framework. This solves a number of performance issues, as well as simplifies coding dependencies (particularly exceptions).

Solar is already autoload-only. You can be autoload-only too right now with Solar.

Namespaces. PHP namespaces benefit frameworks and libraries more than any other code bases, and ZF can benefit from it greatly, particularly with components such as Zend_Search_Lucene and Zend_Controller.

Solar already has first-class support for PHP 4/5 style namespaces (i.e., pseudo-namespaces) and supports mixing of multiple “vendor” prefixes in projects (and supports cross-vendor fallbacks across library hierarchies). Solar expects that you will be working within your own pseudo-namespace already, and so is poised to use 5.3 namespaces proper with little effort. You can have namespace-like support right now with Solar.


As with “new language features” above, Solar isn’t on 5.3 yet, but then, neither is Zend Framework.

MVC Implementation: Our current MVC implementation is increasingly adding overhead to the dispatch cycle, slowing down the request cycle. While you can squeeze additional performance out of it via stripping require_once calls and using autoloading, the fastest requests are still far short of other, slimmer frameworks …

Solar‘s dynamic dispatch cycle is much faster than the one in Zend Framework, and has been for years; see these benchmarking posts:

You can have a much faster dispatch cycle right now by using Solar.

Models and Master-Slave

One more thing that Zend Framework doesn’t have, that Solar does, is an integrated model system. Zend Framework recently dropped the idea of having their own, and expect to depend on an external system for reasonable model/record/collection support. Solar has an integrated model system right now with support for single table inheritance, various relationships, unified saving of object graphs, automatic data filtering, automatic form generation, calculated columns, collection methods, automatic data caching and clearing, and much more.

Yet another thing: we also provide support out-of-the-box for master-slave MySQL replication, with no changes needed to the codebase. Change your config file from the single-server connection to the master-slave connection, and you are done. (Well, you might have to wrap some parts in transactions, but after that, it will work on both single-server and master-slave setups.)

You can have robust models and master-slave support right now with Solar.


There is one significant thing that Zend has that Solar doesn’t: narrative documentation. Our API docs are second to none, but the tutorials are lacking. We’ve been spending our time making the framework great, not writing about the framework. You can help with that if you like by adding to the wiki.


The point of all this is not to belittle Zend, Zend Framework, its developers, or its contributors. The point is to ask Zend Framework adopters: why wait for ZF 2.0 when you can have all those features and more, right now, by using Solar?

(Let the ZF apologists begin their comments right now. 😉

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

35 thoughts on “The Future of Zend Framework is Solar

  1. I find that the way Zend Framework (or Symfony) take to move PHP community forward is just wrong. Zend Framework is over-engineered, uses too heavy object oriented model. Developers behind Zend Framework try their all best to satisfy Java developers. But PHP is all about a simple, light weight approach to web development. Making PHP less fun, more complicated is just wrong by any mean. They just forgot how PHP dominates the world.

    SolarPHP, CakePHP 3, Kohana 3 are good PHP frameworks. But I think that Solar is smarter and more innovative.



  2. bu bu but but but….Solar doesn’t have a stable release yet.

    Yes, I’m aware that Solar is “stable enough” but “Alpha” tends to scare people away. Label it “Beta” and people will come in droves. Afterall, on the web “Beta” means Google awesomeness. 😉

  3. In one really important area Solar is far behind to ZF and that is community. My opinion is that community matters more than any technical details.

  4. it’s almost like saying that the future of home depot is starbucks if tomorrow they start selling coffee and muffins. Or the future of mercedes is bmw because both of them have all the features you’d expect from a car. A framework is defined by more than its features, making posts like this indeed just a cheerleading attempt. In my humble opinion, and so on…

  5. It’s cool your framework has a lot of stuff ZF is going to implement, it means you’re probably going in a sane direction if others are doing the same.
    Still, when people consider a framework they consider more then just the features, they also consider things like ease of use, quality (unittesting+documentation), and most importantly for a lot of companies, how easy it is to find new developers that know the framework.
    With Solar compared to ZF I’d say that last one will be very hard for you guys, but I wish you best of luck, competition is important.

  6. First thing: I am not using any of the mentioned framework while at Ustream I created a highly optimized framework, but I am mainly familiar with both framework as I checked more times their source code. I always liked Solar, but I think this post is a little pointless: the mentioned features are not too unique, they are part of a natural evolution. I think even symfony could say that it is the future of ZF (or other frameworks which are already on a higher level). But why are you even developing a PHP framework while Rails has already this features? And the other things is that you did not mention that features that ZF has and Solar not.

  7. Isnt a bad practice if all classes inherit from same parent? Protected becomes public this way.

  8. You can have namespace-like support right now with Zend Framework too.

    “why wait for ZF 2.0 when you can have all those features and more, right now, by using Solar?”
    because, right now, in ZF you have some other features which you don’t have in Solar??

    Seriously, I’m not using neither Solar, neither ZF, but this post is kinda “low”, would be better to invest the time spent on it into writing some narrative docs 😉

  9. Why wait for ZF 2.0 when you can have all those features and more, right now, by using Solar?
    Because of large amounts of code already written, using ZF 1.x
    I am not happy with the current state of ZF, but the codebases that I’m maintaining (two large projects) are too large to switch to another framework, so I’m waiting for ZF 2.0 (and ensuring everything works with PHP 5.3 in the meantime)

  10. As impressive as Solar is, Zend Framework still has far more readily available libraries such as Zend_Search_Lucene and Zend_Service_Twitter which aren’t available in Solar.

    I agree with pcdinh, Zend Framework is too Java-like and is over engineered. What ever happened to its original marketing pitch – “extreme simplicity”?

  11. Wait, Zend Framework has no Model component and will never have, and Solar neither have it. What can be included is a Data Mapper that addresses the need for persisting objects in a relational database. What Zend Framework is going to support is Doctrine 2, a real Orm that let the developer use POPO for entities instead of subclassing. It will be a shared standard with Symfony (a la Hibernate).

  12. I’m far from convinced that unified constructors are a good idea, especially with 5.3.

    The fact that framework code has to interface databases/memcache/etc means it is not that unified.

  13. Overengineering is a soft target. Remember that the ZF deliberately avoids a degree of simple coupling (aka Full-Stack) in favour of a looser component architecture. The result has been an evolution of a) duplication and b) integration. The two combined feel overengineered but on a component basis the overengineering is not so visible. It’s never more obvious than in the MVC area – something the roadmap already notes as needing improvement. As with all software, the ZF has been moving forward. Zend_Application was a huge step, and there are doubtless others waiting in the wings that will hit ZF 2.0.

    Actually, I think Paul’s post is quite right to point out Solar’s advantages. There is far too little prodding, questioning and criticism around frameworks in my opinion. Many developers forget that the ZF is not a “new” framework. In software years, it’s positively ancient! Of course there will be a long list of improvements badly needed, and Paul’s post does nothing more than point out a few of them that (on a positive note) the ZF 2.0 roadmap identifies at an early stage.

    I will take issue with the Model mention though ;). Creating a generic Model layer (not a project specific layer) is insanely difficult and requires a massive amount of man hours. The Zend variant was dropped for some very good reasons. Benjamin was working on it alone (no help). It’s a massive undertaking. Database expertise (i.e. all RDBMSs) is rare in the ZF developer group. Maintenance was going to be an unforgiving bitch. And Doctrine 2 was simply well ahead, in existence, has amazing support and adoption, and just fits really well into the equation. There is nothing wrong whatsoever with recognising a weakness and resolving it with a third party external.

    So with that one aside – can we lay off Paul? His points are valid. If a developer thinks they are upsetting, then sign up as a ZF 2.0 developer so you can chant nanananana at Paul in a few months ;).

  14. I don’t think being bitter is going to get more people using Solar.

    Perhaps ignoring your tutorials / making it less accessible is a big reason for low adoption; or perhaps it’s some other reason that is within your control. Perhaps being so “similar” to ZF could be a problem. What is your USP?

    A common problem with startup-businesses is creating a solution to a problem that doesn’t exist. They spend time and money creating a functional product and then don’t understand why no one wants to buy it. Perhaps this is something similar.

  15. For those that feel changing frameworks is to large of a task understand that the change from ZF 1.X to 2.X is going to be a major undertaking.

    ZF group has clearly stated that they will not just be moving to php 5.3 with 2.X but that they will be breaking BC along the way. They even stated at ZendCon that the break is going to be wide enough that they are trying to program “helpers scripts” to assist in the migration.

  16. A lot of people think the Zend Framework is really good, but it’s not – things mentioned for 2.0 are things that should have been dealt with prior to even version 1.0, but like yourself, I saw that one coming.

    Zend Framework is bloated, bulked out by a) features most developers don’t even use, nor care for and b) badly designed class structures that not only bend best practice rules, but break them – with a team of developers working on a project, you do need standards and there are none.

    You have one contributor doing it their way, and along comes another contributor who does it his way, and what do you get?

    Exactly. I suggest for 2.0 the team completely strips out the bloat, and forks a “Lite” version, bare bones for those developers who are really only looking for the very basics, such as the Front Controller and the Model, View and Controller and nowt else.

    Doubt they’ll listen as they have failed to listen so far, so let the bloat continue is my impression. There is going to come a time, this framework [Zend Framework] will make a lot of people puke up all over the place.

  17. You should invest some time writing good documentation, articles, etc. about Solar. I think you’ll find it much more successful instead of doing stupid things like this. Maybe people don’t know about and use Solar because the documentation is not informative enough so they don’t know all this stuff exists.

  18. Hi Paul,

    With due respect, the problem with your rant about ZF and your subsequent cheerleading post is that of some more than 1100, 33% claim to be using ZF and nobody (maybe those 15% claiming to use “Other”) seems to be admitedly using Solar:

    This should make you reflect a bit: Either Solar is not that superdupper, it is not properly “marketed” or it’s not that good compared to other frameworks…

    Just for the sake of real modesty… 😉

  19. I thought this was a great post! This didn’t feel like a post about “mine is better than yours”. I don’t think that’s the point. Articles like this are great at showing some of the similarities and differences between good projects and how two high-quality frameworks are (or will be) approaching problems in similar ways. I use Solar daily; I think it’s the cat’s pajamas, but I would never say that the ZF is sub-par because that would be crazy talk. There are too many top-notch developers working on it to be anything less than a top quality framework. Solar doesn’t have a big following or teams of developers and sponsorship, but it is still a great tool. It would be great to see some other people give it a shot. Take a couple of hours to dive in and play around. If you need help, ask! Those who use it would be more than happy to lend a hand. If you can’t get into it, fair enough. But if you do, please tell others and contribute in any way you can.

    The Solar manual and tutorials do need work. Just be patient. With a little more time, these resources will improve immensely.

    Good post, Paul.

  20. “not writing about the framework. You can help with that if you like”

    I probably would contribute, but I can’t justify the time it would take to learn Solar due to its lack of documentation.

    But still, kudos on what appears to be a very mature framework. And on route rewriting making it to the beta release.

  21. I have looked at Solar on and off since its genesis. I started using the Savant template system years ago — I think it was a 1.x release — and have built some major commercial sites using it (and a custom MVSish framework). I finally started a new project earlier this year that allowed me to choose a new framework. I wanted to go with Solar, but b/c breaking changes were still being made and I banged my head against the no documentation situation for longer than my schedule allowed.

    I started using Zend and found it pretty easy to get going. The documentation and community that has been mentioned in these comments provided what I needed at the time. That said, I would definitely consider Solar for a future project, as I don’t need the Lucene, Twitter, etc. support that some use as examples of Zend being more complete. I would actually prefer to scale back to a more lightweight framework at this point.

    What would help me is a migration guide — something that illustrates “in Zend you to , but in Solar you do .” This might sound petty, but I have been doing this long enough that I dread learning yet another way to do essentially the same thing. All my web apps interact with a database, populate template variables, collect form data, parse xml, make http requests, etc.

    Some people relish the idea of learning a new language/framework/paradigm. Maybe I’m getting old, but I just want to get to the finished product these days.

  22. Touche, Mr Paul Jones! Great cheer leading and great work on your framework. Sorry I’m late to the lunch line on this one but glad I read it.

  23. It’s ironic that proponents of this framework would dismiss Zend as being over-engineered when this blogs own caption is “If it’s worth doing, it’s worth over-doing”.

  24. I wanted to say what Padraic did about Doctrine…

    If you AREN’T planning to use Doctrine or similar project, I think you will regret it. Getting the required expertise to do well what Doctrine does is harder probably than building the entire rest of your framework.

  25. […] Después de 5 años de trabajo su principal desarrollador finalmente anunció así el lanzamiento de la versión 1.0 estable del framework para PHP5 Solar. Sus novedades son muy interesantes y las diapositivas de su presentación oficial en la conferecia ConFoo ya están disponibles. Sin embargo, mucho más interesante lo es la actitud de su autor, Paul M. Jones, que literalmente dice en su blog que “el futuro del Zend Framework es Solar”. […]

  26. I’ve been developing with Zend Framework for quite some time now, and must say that that MVC in general is the way forward.
    There are many other PHP MVC frameworks thats been available long before Zend Framework – CakePHP, Code Igniter etc.

    But one thing you must understand is that the Zend Framework has the Zend company as well as IBM behind it, which is a huge advantage in terms of support, future availability, and quality code.

    Magento (one of the leading ecommerce platforms) also uses Zend Framework as part of the stack, Magento’s decision to use ZF as appose to other frameworks was a clear-cut one.

Leave a Reply

Your email address will not be published. Required fields are marked *