On Decoupling and Dependencies: Answering The Critics of Aura's Approach

By | December 20, 2012

“There are no solutions … only trade-offs.” — Thomas Sowell

tl;dr: “As a library author it’s tempting to bring in dependencies for various reasons, but as a library user it’s frequently convenient to not have cascading dependency sets. … If a user already has something they like, make it as easy as possible for them to keep using it without making them install things they don’t actually need. That is the kind of duplication we really want to avoid. This applies not only to HTTP response delivery, but to caching, logging, translation, templating, and a host of other functionality.”

Recent articles from me and others regarding the Aura project for PHP 5.4+, dependencies, and decoupling have generated a lot of commentary, some of it negative, and some of it misdirected. For reference, the posts are:

In this post, I’ll respond to some of that commentary. I will sum up similar comments and address those summaries.

Regarding “Dependencies Are Bad”

Bernhard “Webmozart” Schussek writes an otherwise good post that, unfortunately, begins by misconstruing my statements:

Aura is creating some buzz that components of PHP frameworks should not have any dependencies.

The general attitude of people arguing against dependencies is that dependencies are a bad thing.

Matt Robinson makes a related comment:

You’ve made a judgement call that dependencies should be avoided at all costs – I think that’s going a bit too far.

I can understand how some readers might infer the “dependencies are bad” sentiment from the interviews, especially if they did not read with thoughtful consideration. Their assessment is incorrect.

For the record: dependencies are not a bad thing in and of themselves, nor are they a good thing in and of themselves. Choosing to have one or more dependencies is a trade-off in software development, where the gains and losses from having the dependency must be judged according to the context of the development goals.

If dependencies are neither good nor bad in themselves, why does Aura avoid them so assiduously?

To learn the answer, please recall the origin of the Aura project (which is essentially the second major version of the Solar 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.

As you can see, it is expressly our goal to serve a particular set of users as our primary focus: those who want independent libraries without added dependencies.

As a library author it’s tempting to bring in dependencies for various reasons, but as a library user it’s frequently convenient to not have cascading dependency sets. Call it a case of taking our audience seriously, and going as far as we can with it.

Regarding “Duplication”

Matt Robinson asks:

[W]hat’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. :)

They are remarkably similar, since they serve a similar purpose; that is, to describe an HTTP response. I think “big chunk” is an inaccurate characterization, though; it’s 2 classes out of 56 between both packages.

As Matt allows, he is in fact wrong. ;-) The duplication is not for the sake of avoiding one line in a Composer file. It is to make sure that people who want to use Aura.Web package are not required to additionally install the entire Aura.Http package to get access to a single class.

Many library users out there already have HTTP delivery mechanisms of their own choosing, and have neither the desire nor the inclination to drag another one into their codebase. All these users need is a way to describe an HTTP response. It’s easy to do that in a single file.

Because of this single class of duplication that exists in Aura.Web, library users can build a relatively small amount of glue code to send the AuraWebResponse using their existing installation of Guzzle, Buzz, the HTTP extension, plain old PHP, or even the Aura.Http package. This is the tradeoff: a single duplicated file, versus many dozens of files of duplicated, unused, and unneeded functionality.

That is the central point for the Aura project: if a user already has something they like, make it as easy as possible for them to keep using it without making them install things they don’t actually need. That is the kind of duplication we really want to avoid. This applies not only to HTTP response delivery, but to caching, logging, translation, templating, and a host of other functionality.

Stan, who admittedly is part of the Aura target audience, already knows this:

[T]here are some of us out there that have a hybrid of components tooled together. The more dependencies that are forced on us (guilty by assoc) the harder that is to do. So maybe my app that’s routed by Aura, templated by Twig, works with the DB using Doctrine ODM, utilizes Symfony for the Finder and Yaml components and Zend for the console could find itself in a pickle when more baggage is added to the mix through dependencies that might not be necessary.

Amy Stephen also figured out the point pretty quickly …

Disagree with Paul’s assertion in the comments that such a strategy does not lead to some duplication of code or function or that the methodology means some functionality be sacrificed. Of course, it does. That’s the ying and the yang of it – get one thing clean and another dirty – the cost, time, quality triangle – It’s math. It’s always a balancing act building software.

… although to be fair, I didn’t say “does not lead to some duplication”; I said duplicated code was “almost nonexistent.” ;-) Perhaps that too was a mischaracterization: a few classes here and there, among hundreds of classes and a dozen packages, seems rather small to me. Others may disagree.

Regarding “Not Invented Here”

Some commenters claim that this approach promotes “NIH” syndrome. Drak said:

Seems to me like you are promoting NIH. The very concept that a decoupled component cant have dependencies means you have to invent everything yourself.

Webmozart similarly opined:

I think this needs some urgent clarification before this way of thinking becomes mainstream and PHP creeps back into its NIH-hole.

I would argue that the offering decoupled packages in the way the Aura does leads away from not-invented-here syndrome, not toward it.

Recall that one of the driving motivations behind Aura was to extract the parts of Solar that users wanted as separate packages. Those users wanted very badly not to engage in NIH by using Solar, but could not, because it was delivered as a monolithic whole. Those users can now download independent, decoupled Aura packages and avoid rewriting the functionality contained therein.

Bertrand lobbed a shot over the net at, I guess, the Symfony crowd, when he said:

Ha, ha, who’s got the NIH syndrom ?

Event_Dispatcher, written in 2005, 3 years before the one in your example…


This is a comment I sympathize with. It seems to me that many accusations of NIH-ism are more complaints and frustrations that the accused is not using the libraries and packages the accuser prefers.

Regarding “Tests As A Way Of Discovering Dependencies”

Some commenters were dissatsifed with my use of unit testing requirements to discover what a package really depends on, as opposed to what its composer.json file states. Webmozart said:

There’s a distinction between required dependencies and optional, supported libraries. For example, the Symfony2 Validator optionally supports annotations, in which case you need DoctrineCommon (why should it reinvent annotation parsing?). You can use the Validator without any of these supported libraries.

Obviously, the support for these libraries is tested, so for running the tests you also need the supported libraries (doh). I fail to see how this is bad.

Lukas covered this as well:

[T]he issue is that the way [Paul] was comparing. Paul was making a very incorrect conclusion that anything that is needed to run the tests illustrates “cross-package dependencies”. Yet if you look at the composer.json (which I would have expected Paul to be familiar with) then you would notice that infact the Validator component has ZERO dependencies beyond PHP itself:


This was a topic I had hoped I would not have to address. All my other statements regarding dependencies have been as clinical as I could make them, without reference to words like “good” or “bad” in describing the various practices. For this topic, though, I must make some statements that others will find negative or perjorative. Because of that, I am going to do it in an entirely separate post, so as not to pollute this commentary thread too harshly. Look for it in a few days.


Thanks to everyone for their comments and critique, and please be sure to check out the Aura project!

20 thoughts on “On Decoupling and Dependencies: Answering The Critics of Aura's Approach

  1. Pingback: On Decoupling and Dependencies: Answering The Critics of Aura’s Approach | codegooroo

  2. Lukas

    Paul: why do you continue to not bother discussing that commentors have been making in regards to hard and optional dependencies? I guess the answer is “This was a topic I had hoped I would not have to address.” To me (contrary what Matthew replied) this post is exactly the same as the previous post and then wraps up with bringing up the main point of criticism as intentionally ignored. Actually in my paragraph I also do not use the words “good” or “bad”, but I do quote you on your claim that Validator has “cross dependencies” and that I think you are glossing over the the distinction between hard and optional dependencies. At any rate, I guess we have both made our points and appearently do not get each other. So it goes.

    1. pmjones Post author

      Hey Lukas — Man, I can only address so much at one time. I read all the posts and comments from everyone, boiled them all down, found what I thought were the major points, and wrote responses to all but one of them. That one remains to be answered is not a case of me “not bothering to discuss” but of me being worn out addressing all the other points. I even say that I intend to address it. Patience, sir, patience.

  3. Matt Robinson

    Haha, okay we disagree on the definition of “big chunk”! :) It’s certainly not a large proportion of the code, and I’m sorry if that’s how it came across. Regardless, your counter-point is well-made, and I agree. There’s definitely a pragmatic balance to be made.

    As I’ve since clarified in the comments to the previous article, I think a lot of us felt sore that you criticised Symfony2 with two false accusations: first, that it was made framework-first and library second; and second, that it’s much more tightly-coupled than Aura. In fact if you ignore the framework component, SF2 has only 2 components that require other components (Form and Security). All the others can be (and are!) dropped into other projects with other components from other libraries just fine.

    Personally I think Aura, SF2 and Zend can play very well together. But reaching for and exaggerating differences is probably the wrong way to go about mutual and useful cooperation.

  4. Drak

    Something that really riles commentators is your continued mushing of issues to make a case to promote the benefits of Aura (based on fallacy). I can only surmise you either don’t get it, or it’s a deliberate publicity stunt. You are pushing points which are patently wrong and casting libelous aspersions. If you’d released Aura without making wildly inaccurate and misleading claims, none of this riot would have erupted.

  5. Roman

    To add to what Drak has wrote, your whole project promotion is based on one single “Hey! We have this one feature better than Symfony2/ZF2! Use our project!” premise.
    Personally I disagree with you and still don’t see any benefits, but that’s not something that would’ve bothered me or stopped me from checking your project out at some point.

    What does annoy me and pushes away is the fact that you don’t let users decide for themselves. You just keep pushing your one big point that is arguable at best, trying to ride on popularity of projects you claim yours is better.

    I really hope you reconsider how you promote.

  6. pmjones Post author

    Hi Matt,

    First off, thank you for your civil and courteous tone. I appreciate it.

    You said: “In fact if you ignore the framework component, SF2 has only 2 components that require other components (Form and Security).”

    I’m doing a review of all the components listed on Symfony’s page here: http://symfony.com/components

    I have only just started, but there is at least one more component that has a hard requirement: BrowserKit requires DomCrawler. In addition, there appear other dependencies on the Process and CssSelector components, which I’m sure the Symfony apologists reading here would call “soft” or “optional” dependencies.

    I expect to work through all of the components to see what their actual dependencies are; I’ll include my findings in a followup post.

    Again, my thanks for your attentive and considerate discourse.

  7. Lukas

    “Symfony apologists” .. we are not apologizing, we are annoyed by your continued willingness to spread misinformation about Symfony. its a pity that you use your position within the community in this way.

    but i guess its all on the eye of the beholder. i know that lots of people got mad at me for comments i made about ZF2, which i considered factual. i guess you believe the same about your comments.

    1. pmjones Post author

      (Lukas: As an aside, an “apologist” is “one who speaks or writes in defense of someone or something”. I’m not saying you guys are apologizing for anything. :-)

  8. Matt Robinson

    @pmjones oops yup, browserkit needs dom-crawler and suggests Process, while dom-crawler suggests css-selector. Suggestions are at an even further remove from optional dependencies though.

    Browser-kit strikes me as something designed for functional tests – I’ve never considered it for use within a project itself. That might be my own shortsightedness though. I can see how it’d be useful coupled with GuzzlePHP or Buzz to approximate something like Python’s (frankly superlative) BeautifulSoup.

  9. Pingback: Symfony Components: Sometimes Decoupled, Sometimes Not | Paul M. Jones

  10. Lukas

    @Paul: not sure if you quoted wikipedia, but it lists 2 definitions .. the one you quoted and as the first option “One who makes an apology.” .. also it might be a language barrier thing, but to me the word “apologist” has a negative connotation.

    1. pmjones Post author

      I generally use it in the sense I quoted (it was a dictionary definition, not a Wikipedia one) and that sense is neither positive nor negative, merely descriptive.

  11. Lukas

    Paul: I looked up a few sources and both the “apologizing” aspect and the negative connotation seem to be consistently mentioned in definitions I found. I acknowledge that you did not mean it that way, but just be aware that if you use this word that you may have to explain your definition or risk upsetting people unintentionally.


Leave a Reply

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