Michaël Gallego

This is my blog. What can you expect here? Well... Zend Framework 2, Amazon AWS...






Status of Zend Framework 3

It has been several months I didn’t blog. Actually, I have been pretty busy with work, and I’m in the process of trying to reduce my addiction to computer and coding. But no matter how hard I try, I always go back to what I’m enjoying the most: writing beautiful and efficient code. And here I am, to speak of the long-awaited Zend Framework 3.

First, I’d like to say that this article IS NOT related to Zend nor the other contributors. However, I know a lot of people are interested about this project, and the lack of news from the Zend team, coupled with the low activity of Zend Framework 2, is very frustrating. Even more for some other contributors and myself.

Current state of Zend Framework 2

Even though I’m a Zend Framework 2 contributor and a ZF2 education board member, I’m pretty new to PHP. I actually started learning PHP seriously when the Zend Framework 2 was in development. I was a pure newbie, and I saw this as a perfect occasion to learn with other talented developers. This was a tremendous experience, and I can’t thank enough all the guys (Marco Pivetta, Matthew Weier O’Phinney, Ben Scholzen…) that did extensive reviews of my code, gave me advices… Contributing is definitely the best way to learn.

Today, Zend Framework 2 is a big part of my life. I make a living of Zend Framework 2, and a big part of my free time is working on high quality modules for Zend Framework 2.

ZF2 has a special place in the PHP eco-system: it is, by far, the most verbose, the most configurable and the hardest framework to learn. It is not RAD, requires much more config than Ruby On Rails or Laravel. I will always remember the faces of my trainings’ students when I show them how much array config you need to write.

The consequence is obvious: while I can’t say it for sure (I don’t have access to such figures), the user base have never been as high as everyone would have expected. Symfony 2 has a phenomenal marketing team that make this framework highly successful, while frameworks like Laravel attracted a lot of beginners thanks to its RAD and Railish philosophy.

But I think that frameworks like ZF2 still have their place in our eco-system. I like the explicitness it provides, and because of its elitist and low user base, the modules quality is very high (really, have a look at ZfcRbac, SlmQueue, SlmMail!).

In the last few months, the Zend team worked on a very exciting project: Apigility. Apigility is, as you may know, a whole ecosystem of modules to easily write APIs. Actually, it shows how flexible ZF2 is, and that’s very good.

But Apigility came with a big drawback: ZF2 was, during a few months, a near-dead framework. The PR list went growing and there was very few activity on the repository. And, more importantly, the initially release planning was not really respected. This was very frustrating for me to see the lack of activity and communication from the official team and, often, I was often discouraged by it.

More importantly, there was another exciting project that, if we have followed the initial planning when ZF2 was released, should already been released: Zend Framework 3.

Why Zend Framework 3?

After saying all of this, you may wonder: why do we need Zend Framework 3, as I said it was very flexible? Indeed. And, to be honest, this was a major discussion even among major contributors. Some want to continue working on ZF2 only, while some others (like me), would like to work on the next version.

I have to admit this is a purely selfish behavior from myself: I don’t work for big companies, and I don’t have the constraints that big companies have when it comes to upgrading big piece of software. That’s why I can understand people that do not want ZF3 now. But what I don’t like is the lack of communication.

Regarding Zend Framework 3, the reasons are various:

  • There are several design mistakes that we made in ZF2, and the only solution to fix them is by releasing a major, new version.
  • While ZF2 is fast enough, there are LOT of improvements to be done in ZF3 (my early prototypes of some major refactored components show a 5-10 times improvements!).
  • ZF2 components have complex dependency graph, and it is hard to use a single component without fetching nearly all the framework.
  • Some components have, in my opinion, accumulated a lot of crap (forms, input filters…) because we wanted to merge features for everyone’s use cases. This was bad, and we should be stricter in how we merge new features.
  • Because it’s fun to write.

There is one thing I often hear about this project: « how much different ZF3 will be compared to ZF2 ». The answer is easy: not much. ZF2 had the right abstractions, the goal of ZF3 is just to make them even better and more efficient. While there will be a lot of breaking changes, the architecture of ZF3 will be pretty close to ZF2. It definitely won’t be like ZF1 to ZF2.

Where is Zend Framework 3?

And here we come to the main problem: if you go through the mailing list, you will be able to find a lot of threads. I also personally tried to bring this problem up a lot of time on IRC. But this project is still at point zero. That’s also why I decided to write this blog post!

Actually, I’ve already invested a lot of time, and I already refactored some components. As I said before, I was able to make them like 5 to 10 times faster. For heavy components like event manager, service manager or input filters. But as I have never been able to merge those components, very few people hear about it. Some people like Ben Scholzen (DASPRiD) have also worked on refactored components like the router, with impressive performance improvements and much much simpler configuration. In overall, here are a list of some components that are actually NEARLY finished:

  • Event Manager
  • Service Manager
  • Route
  • Input Filter
  • Hydrator
  • Authentication
  • Filter/Validator

Yes, most major components are actually already rewritten (or, to be more precise, rewritten as proof of concept) and even well-tested (for some of them, even with a lot of benchmarks and awesome docs!)!

Therefore, a few months ago, I decided to create a private repository with a few other contributors. The idea was simple: we would be able to start discussing seriously about ZF3, and more importantly, starting to merge components. However, I now realize this was a mistake: private repositories get very little interest, and most importantly, we didn’t have the main Zend team involved in the project, so it was working for nothing.

I therefore thought about it, and decided to come with a few solutions that I’d like to discuss with you (don’t hesitate to leave comments!), and most importantly, I hope getting news from Zend!

Choice n°1: new framework

The first idea is to write a new framework. Yes. However, I’m not sure this is the best solution. Here are a few advantages :

  • We are no longer related to Zend. Because we would have an even lower user base, we are not as restricted as Zend is when it comes to releasing new Zend Framework versions.
  • We could drastically reduce the number of components to rewrite.

Obviously, drawbacks are:

  • We no longer benefit from Zend visibility.
  • Most importantly, upgrading modules will be… awkward. While saying that v1 of a module works with ZF2 and v2 of that module works with ZF3 makes sense, it will be very strange to say « v1 works with ZF2 while v2 works with MyNewFramework v1 ».
  • We will have less highly talented contributors as it will be split among ZF2 and the new framework.

Choice n°2: Zend Framework 3 as a new major version

The other solution is to consider ZF3 as a new major version of ZF2. Some components will be rewritten, some will be removed, but in overall, we will still need to have support for Zend\Db, Zend\Dom, Zend\Code, Zend\XmlRpc, Zend\Navigation…

The advantages are:

  • ZF3 is really a new version of ZF2. Most users that are using ZF2 will be able to use ZF3 by just refactoring some part of their code, but all the components they use will be in ZF3.
  • All modules will be able to be upgraded without adding external dependencies.

However, the drawbacks are:

  • It will require a lot of time.
  • Some components are rarely used, and we will either need to refactor them or keep them as they are today.
  • We will face, in the future, the same problems: because we have so many components to maintain, at some point, the PR list will be crowded.

Choice n°3: Zend Framework 3 as a next-generation, complementary framework

Ultimately, my last idea (and favourite) is to not make Zend Framework 3 the successor of ZF2, but rather a complementary framework. Let me be clearer.

Composer has changed the way we use PHP, and I think keeping so many components is stupid. Did you know that ZfcRbac (I’m one of the main contributor of it) no longer uses Zend\Permissions\Rbac since v2, but rather my own implementation? I’m pretty sure very few people still use the ZF2 implementation of Rbac, but as it is tied to the ZF2 framework, it cannot be removed nor refactored!

Furthermore, I’ve seen a very exciting trend in web development: more and more the server part is only used as a lightweight layer to provide the API, while it is consumed by heavy client side applications made with Angular and EmberJS. This had a very important change in how I use ZF2: I no longer use the form component (as this is tackled by the client), I have a very reduced use of View components (as pages are rendered in client side), and so on…

I can’t see this trend to be stopped in the future, and I think we must take this into account. Therefore, my idea is to make ZF3 the « metal framework ». It will no longer be a big framework, but rather only comes with completely rewritten, highly efficient components that are needed for modern applications. Components like Zend\Form, Zend\Navigation or Zend\Permissions will be gone.

Some of those packages will be provided in other official repositories, and could evolve at their own pace. Some of them won’t be rewritten at all. But rather, the idea is to allow you to use ZF3 components along ZF2, maybe with some kind of « bridge » component.

Really, this is important: I think the best way is not to consider ZF2 as a dead framework when ZF3 is released, but rather as « related » frameworks that you could choose depending on your needs. Think about jQuery 1 and jQuery 2: both libraries are maintained and live together. You just decide which one to use based on your use case.

I’ve made a list of some components that could have their place in the main framework:

  • Authentication
  • Crypt
  • Escaper
  • EventManager
  • Filter
  • Http
  • I18n
  • InputFilter
  • Validator
  • Log
  • ModuleManager
  • Router
  • Mvc
  • ServiceManager
  • View
  • Session

Other components may be provided in separate repositories (because they are still important, while not necessarily used in all applications):

  • Feed
  • Form
  • Paginator

All other components will be definitely gone. GONE. Compare this to ZF2 list components, and you can imagine how it will make things easier. ZF3 main repo will be « the bare metal of web development », other official components will be « things that you still need in lot of projects, but not necessarily if you use an API-only server », components that are biggest abstractions like RBAC will live in third-party modules. For anything else, use Composer.

The way I see it, the main goal of those components will be to be:

  • Very extensible and flexible, so we don’t need to merge a lot of PR for every use case. I definitely want to avoid the Zend\Form’s syndrome!
  • VERY fast. We would increase minimum dependency to PHP 5.5 (or even 5.6) to be able to use ::class, generators (yes, we have lot of use cases for it in the context of the framework!).
  • Documentation: ZF2 documentation is bad, and we know it. I think that doc needs to be written AT THE SAME TIME as we write code.
  • Benchmarks: ZF2 does not have any benchmarks. Some components have accumulated a lot of crappy code and, if you compare them for the initial version in ZF2, some components are maybe 2, 3 or 5 times slower than they were initially. By having benchmarks for each components, we will be able to track regression more easily, and having some references for more optimizations.

How would in work in practice?

This is pretty nice in theory, but in practice, it would be much harder to make ZF3 works with ZF2. I think one possible solution would be to take a similar approach that Guzzle took when they release their v4: ZF3 and ZF2 would use different namespaces.

So… now?

Obviously, this is, for now, my own ideas and, once again, they are not related to Zend nor any other contributors. However, I REALLY want the Zend team to realize that contributors are very important to the eco-system. If the major contributors are tired of lack of visibility, they will leave. And I don’t want this.

First, I’d love to have your opinions about those solutions.

Then, I think that Zend team should organize an IRC meeting (like in the old days!) and SERIOUSLY discuss about Zend Framework 3. All contributors and users will definitely understand a « NO », but at least, we won’t live in the dark anymore and will be able to take a decision (like creating a new framework). If they decide to starting work on ZF3, they should trust contributors and give them write access to the ZF3 repository (that actually exists since a long time: https://github.com/zendframework/zf3).

As I said before, we have already a lot of components that we wrote as proof of concept, so all we will need be review, new ideas…

Let me know what you think! Do you want ZF3 or are you satisfied with ZF2? What would you like to have in ZF3? Which one of the previous solution do you prefer?

Once again, I can’t outline it enough: this is not an official proposal for ZF3. Those are just some ideas I have about how ZF3 could come to life, and a slight hope of pushing the development of this version.