How Is Aura Better Than (er, Different From ;-) Than Symfony and Zend?

By | December 6, 2012

I did an email interview with the folks at PHP Magazin; their German version is here. What follows is our original email exchange in English.

First of all, congratulations for releasing Aura 1.0!

Thanks! Most of the packages are at 1.0, but there are still three that are in beta; I expect them to go “stable” soon as well.

Why did you do it?

Aura is essentially a second major version of the Solar Framework. (Solar was the first E_STRICT framework for PHP 5; its development pre-dates that of the Zend Framework.) One of the repeated questions we got regarding Solar went like this: “I want to use just one part of Solar; can I do that without having to download and configure the whole framework?” Of course the answer to that was “not really.” It was a monolithic framework, where all the pieces were designed to work with each other in a relatively dependent fashion.

So with Aura, we started out from the other direction. We wanted the pieces to be usable on their own, without any other dependencies. Only after that would we build a framework out of the pieces. We called this our “libraries first, framework second” principle. This means you can use just one Aura package if you want, and you won’t get a lot of of other packages as dependencies; each one is completely self contained, including its tests. Each one uses separated interfaces and data transfer objects as necessary to move information across package boundaries.

In addition to that, we wanted to take all the lessons we learned from Solar and break backwards compatibility to start over again. The single biggest BC break has been moving away from a Service Locator implementation and the universal constructor, toward a more formal Dependency Injection oriented system. That one change has made for gigantic improvements in decoupling, testability, and package independence. (I have to thank Jeff Moore here for being patient with me and slowly getting me on the dependency injection track.) We don’t even use superglobals within the packages; everything from the environment has to be copied into the objects, which makes things really easy to test.

Why did you decide it has to be PHP 5.4? What’s the advantage?

When we started the Aura project in 2010, we targeted PHP 5.3, since it was the most recent PHP version at the time. Closures and traits especially have a lot of powerful uses if you approach them wisely. Then PHP 5.4 came out in January 2012. Almost all of the Aura packages were still in development at the time, so we figured we might as well target PHP 5.4, with its short-array [] syntax and “callable” type hint. Those things seem small, but once you start using them, they are *so* convenient (and frankly they make the code look prettier :-).

You seem to love small packages. What do you think of the microframework approach Ed Finkler published in the beginning of the year?

I think Ed has a strong point, although to be clear I don’t think he’s so much about “microframework” as he is about “micro-PHP” in general.

It used to be, back in the PHP 3, 4, and early 5.x days, that the word “framework” was a dirty word in PHP land. (The word “CMS” was OK though.) Then, right after Ruby on Rails came out, suddenly a “framework” was a good thing. Lots of developers got on board with that, and we did the same with Solar.

So in a way, I think moving back to a library-oriented approach is a natural tendency for the PHP world. Frameworks still have value, especially for early-to-mid-career developers, or for teams where you need a standardized development process but don’t have a strong senior-level architect on staff. But a lot of senior developers want to be able to pick and choose between libraries, and they want to be sure they understand what the library is doing (and why, and how). And they want to be able to replace the pieces they end up not liking. That’s a lot easier when you have independent libraries than when you have a monolithic framework.

What can one do better with Aura than they can with Zend or Symfony?

A lot of PHP developers are stuck with codebases they didn’t build themselves, or that they need to improve carefully over a long period of time because the business is dependent on it for revenue. For those PHP developers, switching the project to a framework isn’t an option. The Aura project, being composed of independent packages, lets these developers use just the individual independent parts they need for their existing projects, and slowly improve the quality of their codebase. It’s easier to refactor your project one part at a time using Aura than it is to start all over again with a monolithic framework.

If you’re lucky enough to be able to start a brand-new project, Aura also provides a framework system that glues all the other packages into a cohesive whole. If you’re the kind of developer who wants to use a full-stack framework, but you also want to be able to pull out parts of the framework and replace them with your own implementations, Aura (because it was built with a “libraries first” approach) makes that a lot easier for you than Zend or Symfony does. There are no cross-package dependencies like there are with Zend and Symfony, and we use separated interfaces for things that should have replaceable implementations. (The framework package is still beta, but it appears to be working just fine.)

Thank you very much and keep up the good work!

Thank you for your interest and attention!

11 thoughts on “How Is Aura Better Than (er, Different From ;-) Than Symfony and Zend?

  1. Pingback: How Is Aura Better Than (er, Different From ;-) Than Symfony and Zend? | codegooroo

  2. cordoval

    i will be the first to start the fire besides reading those political blog posts of yours :)

    but first a question:
    ” data transfer objects as necessary to move information across package boundaries.” PLease could you point to an example of this on github of your code?

    second and here comes the war offensive:

    Symfony2 and Zend are not as coupled as you say they are. Are you sure you don’t want to recant? In addition to this you forget the components in both Symfony2 and Zend. So far the only thing i got from your approach is that data transport, so very interested in looking at it. Good job and great that Aura is in, not many brave people fight it with their own framework!

    Reply
    1. pmjones Post author

      Cordoval: Here is a data transfer object:

      https://github.com/auraphp/Aura.Web/blob/develop/src/Aura/Web/Response.php

      When you run an Aura.Web controller using the exec() method, you get back an AuraWebResponse object. It describes an HTTP response, but it is incapable of actually sending that response. It is up to you, as the user of the package, to take that data transfer object and convert it into a real HTTP response; you can do that with plain PHP, or you can use the HTTP library of your choice.

      Reply
  3. Lukas

    @cordoval: Paul is talking about the fact that Aura components have zero dependencies on other components which is not the case with Symfony2 and ZF2.

    Reply
    1. pmjones Post author

      Lukas has it exactly right. I’ve been asked by PHP Magazin to post a followup regarding this; when they publish it, I’ll post it here as well.

      Reply
  4. Feras

    I completely disagree with your points about “What makes it better”. Both Symfony2 and Zend2 are a set of independent packages managable via git or composer. For example I personally use zendx_console_unix_process and i dont need the whole Zend framework. The same way as many open source projects including drupal, phpbb use some of Symfony components such as the Request without the need of the whole framework. Also there are completely different frameworks solely based on reusable packages from Symfony for example Silex, which i find very comfortable for small projects. So I think the whole purpose of separate components, bundles, etc is a bit lagging and shouldnt be used as some kind of benefit over neither Zend or SF.

    Reply
  5. Roman Marintsenko

    can you give a proper example where I could benefit from Aura packages, but not from Symfony2 Components?

    Also that data transfer object looks really similar to Symfony HttpKernel Component Response one..

    Reply
  6. Lukas

    again you guys are missing Paul’s point:
    https://packagist.org/packages/symfony/http-kernel

    As you can see this component depends on two other components. In Aura no component has a dependency on another component. However as data has to travel between components the user then has to convert the data from A to B (and I assume Aura has some helpers for this for its own components and maybe even popular alternatives).

    Less dependencies is generally a good thing. The problem is however this conversion step. Ideally the PHP world would have provided interfaces for some core things so that such conversion would not be necessary when moving data between totally decoupled components.

    Reply
  7. Matt Robinson

    A minor correction before things get out of hand: the Symfony Response object is part of HttpFoundation, not HttpKernel. It has no dependencies.

    You’ve made a judgement call that dependencies should be avoided at all costs – I think that’s going a bit too far. Symfony’s position is more pragmatic: dependencies should be optional wherever possible. It means that only 3 of the 20ish Symfony components have any required dependencies: Form, Security, and the HttpKernel (which is the Framework component). You can use any of the others completely standalone, and some of them are incredibly useful: yaml, finder, http foundation, dependency injection, routing, templating. There may be good reasons for using Aura, but fewer dependencies compared to Symfony isn’t one of them.

    Being stubborn on avoiding dependencies has already slightly tainted Aura: what’s the real difference between AuraHttpMessageResponse and AuraWebResponse? They look remarkably similar and have significant overlap in interface and purpose. I might be wrong, but it looks like you’ve got this big chunk of duplicated effort for the sake of avoiding one line in a composer.json file. :)

    Neither of them are notably different to SymfonyComponentHttpFoundationResponse, except that SF’s can send the response, and uses a common object instead of arrays for storing headers and cookies (to reduce the number of unit tests required). Not better, not worse. I don’t see a compelling reason to use one over the other.

    Reducing dependencies needs to be balanced against a reduction of complexity and a separation of concerns. There’s nothing intrinsically wrong with a small number of hard dependencies as long as they’re easy to manage and provide genuine advantage. I think Composer solves that problem very ably.

    I’m not saying Symfony is the one true way any more than I suspect you’re saying Aura’s the one true way. In fact I’d much rather see PHP developers working together on common interfaces than separately implementing the same thing time and time again. I’m really happy that more and more projects are switching to the Composer autoloader (Symfony included – it’s great to see a framework shrink instead of grow, sometimes!) I’m glad that the AWS SDK switched to using GuzzlePHP instead of maintaining its own cURL wrapper. These are changes that are good for the community as a whole. More interoperability between best-of-breed components managed by larger communities are things that are enabled by dependencies. Coding it all standalone yourself closes the door on the rest of the world and does no one any favours.

    Reply
  8. Pingback: On Decoupling and Dependencies: Answering The Critics of Aura’s Approach | Paul M. Jones

Leave a Reply

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