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!