Filina Consulting

Frameworks for everyone

January 8th, 2014

I recently read an article about the ecosystem of PHP frameworks.

First, I don't understand why the author puts Aura and Symfony in different categories. Symfony can be used standalone components or as a full-stack framework. Additional components are very easy to install through Composer. The way to describe the frameworks in that article is inaccurate, which makes me wonder whether the author actually tried any of them.

Second, I don't like the suggestion that all frameworks are essentially the same. I have built mission-critical projects on top of a great many frameworks.  They are not the same. Otherwise, Aura would not have been relevant, given the other frameworks that are already out. Each framework, no matter how decoupled, has its own philosophy that may or may not work for you. Not to mention that each framework has a separate developer community, and its own set of bugs and limitations. You still need to shop around, read reviews, ask for opinions, etc.

Third, frameworks should not be viewed as some big scary monster, only reserved for those who have 15+ years of experience. I have coached many beginner developers on various frameworks with great success. A new framework is possibly the best learning experience for a developer.

By all means, go ahead and try a new framework.


Stephen R January 8th, 2014 I just read the article you reference, and your last point specifically sums it up for me.

I'm not suggesting that every developer out there should abandon existing frameworks/libraries and write their own, but I also think its inappropriate to suggest that no one should ever write their own re-usable code.

My other pet peeve in the linked article is the way PHP-FIG is deified and the PSR's treated like some kind of holy bible for writing PHP. The PHP-FIG was never about the "best way" to do something - it was simply what's most common between the member frameworks. This is less explicitly stated now, but still mentioned in Q2 on
Bertrand Mansion January 8th, 2014 In my opinion, PHP would be better with less frameworks and more useful and well crafted compact and portable libraries. Frameworks like Symfony tend to multiply the number of useless files and classes, making maintenance more complex and degrading performance. It is no surprise Symfony 2 performs so bad in benchmarks...

These days, too many developers write "components" for their framework of choice instead of writing a portable version for PHP, without dependencies. So you end up having to install all the crap that comes with the framework "core" just to use the "component". This seriously sucks.

I think the need for frameworks is less and less relevant today. I build web applications that rely on small http requests with ajax and javascript, to take user's actions into consideration. So the faster the request, the better it feels. For that, I am using a lot of Nginx+Lua (openresty) now and it's great. I use PHP to display web pages, but most of the work is done with Javascript on the client and Lua on the server.

I have seen people using a PHP framework and not even knowing what PHP was or what they were doing (for example, they were directly calling method offsetSet() everywhere on an object with ArrayAccess interface). The weird thing is that people with a framework experience seem to get employed with higher salaries than people with only PHP knowledge (at least in France). Personally, I prefer to employ someone with a good PHP understanding and knowledge than someone with only a Symfony/ZF background.

There are so many cool things you can do quickly with PHP when you know it well, that are just hidden from you or bloated when you use a framework.
Anna January 9th, 2014 Frameworks have their place in the ecosystem. They are not mere libraries tied together. They provide a guideline for building applications.

This has important advantages. First, beginners can learn a lot faster. Second, companies can more easily replace developers. Otherwise, each time someone leaves the company, the project will slow down as the new dev figures out the approach used. This is why companies will pay more: because that developer becomes productive faster. Would you not pay for the convenience of replacing a car's part instantly off the shelf instead of waiting months for a factory to make one?

The fact that some people don't know PHP basics or do click-programming in Drupal is a whole different topic. Companies should know better than to hire devs with skills in a framework, but not the underlying language.
Bertrand Mansion January 9th, 2014 @Anna
I understand your point with "developer becomes productive faster" but I don't agree. I have seen application code written on top of Zend Framework that was so ugly that even with the underlying framework trying to frame things, it was just too messy to maintain. The team of developers didn't understand what the framework was supposed to bring to them in term of structure and API... In Drupal, I have seen people writing PHP code directly in the template, as if it was a module, and invading the global scope without care (which is easy because Drupal has no encapsulation).

Some managers wrongly think that because they choose a well-known framework, they are safer. That's not enough and that's also a good way to get stuck with a "not maintained anymore" framework version for ever, like Symfony1

I just wish more people would learn PHP than use a framework API.
PEJ January 9th, 2014 Nice article.

IMO Frameworks are great and satisfy a lot of use cases and of course they are no silver bullet. You can still write bad code using a framework. Nothing stops one from running a sql query in your view.

I have long held the view "frameworks are slow/bad/..." but the truth was I just wanted to use and write my own code. This is a flawed and lazy philosophy to live by. You are doing a disservice to yourself and you employer/employees if you hold this view.

Most php frameworks apply a component based development pattern resulting in highly decoupled well tested and documented libraries leaving you with the freedom to use bits of a framework and with even greater ease if you use composer.

I think frameworks are great for any language; Java, Ruby, Python, PHP ... One of my favourite sayings now is that "a good programmer is a lazy programmer". Use a framework, use an ORM if it make sense. If it doesn't use components/libraries.
Anna January 9th, 2014 Yes, you can write bad code with a framework too and I have seen some atrocities. I still have nightmares. However, code written from scratch will usually differ much more from one developer to another than code written on top of a framework. It's not a silver bullet, but it helps. It is true that most modern frameworks understood the value of decoupling.

Then of course, the size of your team, their skill and the kind of flexibility you need should not be overlooked. There is no one-size-fits-all solution. I personally prefer using libraries on the frontend due to their lesser weight and greater flexibility. It's typical to choose this path when you have a small "swat" team.
Rasmus Schultz January 9th, 2014 He does state, near the end of his article, "I advise new developers to learn the frameworks that exist, rather than advising them to create their own".

I don't think Brandon is necessarily going to disagree with anything you said, and I don't think most of what he's trying to get across is actually really at odds with anything you said. But some of us have been working with so many frameworks, for so long, that they are all starting to look quite similar.

I personally enjoy the freedom of choice that comes from not simply selecting a full stack framework, but rather hand-picking based on the specific needs of the application I'm building, and I think that's what Brandon is really saying: you don't need to use a full stack, you can easily build your own stack from an increasing wealth of independent, focused, dependency-free components.

In my experience, components that were designed to stand on their own, are generally more decoupled (and easier to replace, individually) and generally of higher quality than components that were tailored to work together as part of a stack.

Each to his own, of course - but I think, even for (ambitious) beginners, the experience of building their own stack out of individual components, will help them better understand the interplay between those components; as opposed to starting with a skeleton app for a fully integrated stack and trying to fill in the blanks.
Greg January 11th, 2014 @Bertrand Mansion
I find a number of your assertions to be wrong on the face of them. You seem to equate "framework developers" to people who have just learned a framework and don't have any understanding or appreciation for the language that the framework is built on. This >never< happens if you employ professionals. Surely to goodness the interview process weeds out any back yard hacker who learned Silex on the weekend.

A good modern framework is far from simple to write in. There are a number of pitfalls and problems that any person who does not have a firm grasp of the language and the underlying engineering principles will blindly fall into. This isn't the framework's fault. It isn't the communities fault. It is your fault if you employ such people.

In the hands of a competent developer a full stack framework is a powerful tool. It abstracts away a tonne of boilerplate and allows the developer to be more productive. This is an incontrovertible fact. The duty of any developer (be they self employed or working for someone else) is to get PRODUCT out the door and earning money/ROI as soon as possible. It makes poor business sense to reinvent the wheel all the time.

You can quote contrived performance benchmarks which suggest frameworks are slower - and yes, in an artificial benchmark they are. But the cost of hardware is chump change in the cost of developing and maintaining a product.

Yes it is true that it is frustrating that some developers write code that is not entirely portable between frameworks. But again, if YOUR employees are doing this, then it is YOUR responsibility to a) review their code, b) reject their changes, c) coach them in better ways of doing things d) fire them if they don't change their ways. Not a fault of frameworks. Similarly you have all the choice in the world to select only components which are neatly decoupled.

I also disagree entirely with the assertion that you might be left with a "no longer maintained framework". For this to happen you really have to be neglecting your own code for a long time. Progressive upgrading and maintenance of 3rd party packages should be common practice for you and your team. If you are not doing this then you are at fault. You should also be insulating yourself from 3rd party packages with your own interfaces where practical so when it comes time to change packages doing so is trivially easy.

The TL;DR is essentially you don't *need* a framework. But except in a few edge cases and contrived scenarios if you are not using one you are negligent and possibly incompetent.. All of the evils of frameworks which are trotted out by detractors can easily be placed at the foot of the people implementing the solution built on the framework. Employ professionals, agree to standards, have some QA and don't screw it up.
Anna January 16th, 2014 @Greg You summed up my thoughts on the matter. Developers should ship the product to start monetizing the investment as soon as possible. Every argument that starts with "yes, but" means that the developer did not understand the purpose of writing business software.
Adil October 21st, 2014 @Anna, In your post you mentioned...
"Second, I don’t like the suggestion that all frameworks are essentially the same. I have built mission-critical projects on top of a great many frameworks. They are not the same."

Can you please mention them? My next question, PHP is good to work on mission critical projects? Thank you.
Anna October 22nd, 2014 My favorite so far has been Symfony 2. I tried many others before making my current choice. The frameworks all had a different structure and philosophy to them. Communities also play an important role. A framework without a community can be dangerous when working on mission-critical projects, because it's really hard to get an answer to your question otherwise.

Yes, PHP is very good to work on mission-critical projects. I think pretty much any modern language (or an old one that was kept up to date) is good as long as the developers know it well.

This page is protected by reCAPTCHA and the Google
Privacy Policy and Terms of Service apply.

Twitter: @afilina | E-mail: