PHP Frameworks

Mon, Apr 25, 2011 10:00 AM
Last week I spoke at and attended the first ever PHP Community Conference. It was very good. It was also very different from my normal conference. I usually go for very technical stuff. I don't often stop and smell the roses of the community or history of my chosen (by me or it I am not sure sometimes) profession. There was a lot of community at this one.

One thing that seemed to be a hot topic at the conference was frameworks. CakeDC, the money behind CakePHP was the platinum sponsor. I chatted with Larry Masters the owner of CakeDC for a bit while walking one night. Great guy. Joël Perras gave a tutorial about Lithum. I attended most of this one. He did very well. Joël was frank and honest about the benefits and problems with using frameworks, including having to deal with more than one at a time. There was also a tutorial about Zend Framework patterns by Matthew Weier O'Phinney. I missed this one. On the second day, things were different. Rasmus Lerdorf warned about the bloat in most of the PHP frameworks and expressed hope that they would do better in the newer versions. I received several questions about frameworks in my session. I also spoke out about them a bit. Terry Chay wrapped up the day with his closing keynote and touched on them again. More on that later. I want to kind of summarize what I said (or meant to say).

PHP is a framework

In my session, I talked about the history of Phorum. One of the things I covered was the early days of PHP. Back in the 90s, before PHP, most dynamic web work was done in C or Perl. At that time, in those worlds, you had to do all the HTTP work yourself. If you wanted a content type of text/html, you had to set it, in code, on every single response. Errors in CGI scripts would often result in Apache internal error pages and made debugging very hard. All HTML work had to be done by writing to output. There was no embedding code with HTML even as a templating language. PHP changed all that. You had a default content type of text/html. You had automatic handling of request variables. Cookies were easily ingested and output. You could template your HTML with script instead of having to write everything out via print or stdout. It was amazing. Who could ask for more?

Frameworks as a tool

Well, apparently a world that I honestly don't work in could ask for more. There are three major segments of web developers these days. There are developers that work for a company that has a web site, but its business is not the web site. Maybe it is a network hardware company or some other industry where their business merits having a staff to run their site, but it is not their core business. Then there are developers like myself that work for a company where the web site is the business. Everything about the business goes through the web. We have the public web site and the internal web site our team uses. It is everything. The last type are those developers that are constantly building new sites or updating existing sites for clients. I will be honest, this is not a segment I have considered much in the past when writing code or blog posts. But, I met more of those people at this conference than any of the other two types. They seem to be the ones that are motivated and interested. Or at least, because PHP and the web are their business, they sent their people to the conference.

You see, I have spoken out about frameworks. Not very publicly, but those that know me have heard me comment about them. I have never really seen the point. Why start with something generic that will most likely not fit your ultimate need when you need to scale or expand beyond its abilities? Well, for thousands of web sites, that are likely being built by agencies, that time never occurs. Most likely, before that happens, the site will be redesigned and completely replaced. So, if you spend every day building a new site, why do all that groundwork every time?

In addition, why have to deal with every different client's needs? I often say that Apache is my controller. I don't like to use PHP as my controller. But, if I was deploying a site every week to a different stack, I can't rely on Apache with mod_rewrite or whatever things I rely on in my job today. So, you need to have full control in the application. What database will the client this week use? I don't care, the framework abstracts that for me. These are all very good reasons to use a framework.

Framework Trade-Off

There are some trade-offs though. The biggest one I see is the myriad of choices. Several of the pro-framework people even mentioned that there are a lot out there. And it seems that someone is making a new one everyday. With all these choices, it is likely that some of the benefit you get from a framework could be lost. If a client already has a site based on CakePHP and your agency uses Lithium what do you do? Say no to the work or have to deal with the differences? Some of them are big enough to be a real issue. Some are so small, you may not notice them until it's too late. That is a tough place to be.

The other issue is performance. Frameworks are notoriously inefficient. It has just been their nature. The more you abstract away from the core, the less efficient you are. This is even true with PHP. Terry Chay pointed out that PHP is less efficient than Java or C in his keynote. But, you gain power with PHP in way of quicker development cycles. Frameworks have that same benefit. But, have not solved this issue any better than PHP has over C. They abstract away the low level (for PHP at least) stuff that is going on. And that means loss of efficiency. This can be solved or at least worked on, however, and I hope it is.

Frameworks as a Commodity

So, this gets me back to something Terry Chay said. He talked about the motivation of companies to open source their technology. He used Facebook's Open Compute Project as an example. He pointed out that a major reason Facebook would open up this information would be in hopes that others would do the same in their data centers. If that happened, it would be easier for Facebook to move to a new data center because it was already mostly setup the way they like it.

Transitioning this same thought frameworks, the commoditization here, that I see, is in the interest of developers. If the framework you support becomes the de facto standard, then all those developers working in agencies using it are now ready to come to work for you. Plus, if you are the company behind it, there are opportunities for books, conferences, training, support, and all the other peripherals that come from the commercial/open source interaction. Need proof of that? Look no further than the "PHP Company", Zend. They could have committed developers to PEAR, but instead created Zend Framework. I see job listings very often for Zend Framework experience. Originally Zend tried to monetize the server with their optimizers and Zend Server. They had moderate success. The community came up with APC and XCache that sort of stole their thunder. I feel they have had much better success with Zend Framework in terms of market penetration. The money is with the people that write the code, not run the servers.

Frameworks are EVERYWHERE

I will close with something else that Terry Chay said. This was kind of an aha! moment for me. Terry pointed out that frameworks are everywhere. Wordpress, Drupal and even my project, Phorum, are frameworks. You can build a successful site using just those applications. It is not just the new breed code libraries that can be viewed as frameworks. In fact, Phorum's very own Maurice Makaay is building his new web site using only Phorum 5.3 (current development branch). Phorum offers easier database interaction, output handling, templating, a pluggable module system and even authentication and group based permissions. Wow, I have always kind of shunned this idea. In fact, when Maurice first showed me his site, I kind of grimaced. Why would you want to do that? You know why? Because the main thing that drives his site is Phorum. His users come to the site for Phorum. So, why would he want to install Phorum, invest in making it all it can be and then have to start from scratch for all the other parts of the site that are not part of the message board. Duh, I kind of feel stupid for never looking at things from this perspective before. Feeling dumb is ok. I get smarter when I feel dumb. New ideas make me a better developer. And I hope that is what comes out of this experience for me. You never know, I may throw my name in this hat and see how Phorum's groundwork could be useful outside of the application itself.
20 comments
Gravatar for Lukas

Lukas Says:

I think even if you are working at a company where you will stick with your product for a long time it makes sense to use a framework. Or lets say when you start off you should use an established framework that fits what you need for the most part. So if you need full stack, get a full stack framework. If you need something highly specialized, then maybe a microframework. If you need a forum, use an existing forum, if you need a CMS use an existing CMS.

Why?

1) free documentation, tests, security audits
2) ability to higher much easier as your team grows
3) hack it to bits if 1) and 2) start to matter less and success/failure dictates you turn in another direction

I always like to use Twitter as an example here. Would Twitter exist if they would have had to do everything from scratch? The company actually was working on another product and scrambled to reinvent itself when their investors started loosing faith in their original idea.

Time to market counted big for them and it counts for most projects.
If you would have done everything on their own they might have exploded because of security issues etc.

Now obviously their framework of choice didn't keep up with them when they needed to scale. But isn't that a great problem to have? You need to scale when you are successful and using a framework to get started got them there.

Now lets imagine they would have build everything from scratch. Would they have build something that scales sufficiently? Probably not. It might have scaled better because they would have less features from the get go. Then again as they were scrambling to implement features they might have had even less time to bother with caching which to some extend they got out of the box with the framework of their choice.

Anyways, super scaling light speed performance is rarely required form a team at day one. And any team that is required to do this has done something slightly smaller before and can take that code (aka framework) for this project with some additional tweaks.

Now obviously you can choose the wrong framework as the basis and likely for a few awesome ideas there isnt even a good framework to base your work on. But this is the exception to the norm and when you are doing something like this, I hope you are experienced to not require my or your advice. :)

Gravatar for Brian Moon

Brian Moon Says:

Good points Lukas. My only issue is with people throwing out the Twitter or Facebook arguments. Where you cite Twitter, I can cite Facebook. They did not use a framework. (well, they used PHP, the best framework I know of ;) They just wrote the code. And they made it just fine.

My point is, you can't use the two biggest lottery winners of the modern web as examples of how to run your company.

If I was starting from scratch again how would I do it? That is a damn good question. Maybe I need to get dealnews to let me open source our "framework" so I won't have to worry about that if the time comes. =)

Gravatar for Lukas

Lukas Says:

We all know that Mark stole everything from somewhere :)
Anyway, imho writing a secure and scalable architecture is not something most web developers are capable of. For these developers the cost of generic code is much cheaper to pay than them trying to figure out how to do proper caching let alone protected against XSS.

As for those developers that are capable of doing it, you can split that group in those that want to write every bit themselves and those that would be bored out of their mind trying to come up with something that has been done a billion times before. I fall in the later category :)

Gravatar for Justin Rovang

Justin Rovang Says:

I think there's a balance - kind of what Brian indicated the OP. You're limited to what your team mates know - and how comfortable everyone is with key topics.

Here's some more comments/observations from my thoughts:

Using a boxed framework does not give you an "easy A" in security. (Dead horse, I'm sure)

I'm far from one of those people who get hung up on terminology, but something I can't let go of is the concept of a framework vs. library in these types of discussions. Where, in my book a framework tells you how to organize your code, how to code it- along with a packaged library. A library is a mere collection of cookie cutter code, right? IMHO a framework is more restrictive in that regard.

Frameworks appear to be most beneficial to people pumping out high volume, somewhat shallow scoped projects.

As many people say - you can 'hack it'; but nobody has time to 'undo' what the framework does to make it work like they want. (An interesting paradigm, to save time people adopt a framework, only to spend more time hacking it in the future in some scenarios)

Is anyone else naturally put off from having to 'plug into' another system versus 'plugging it into' your own stuff? Experience has proven to many that if you go 'all in' on a particular thing like 'do everything CMS' or a framework; you trade a certain level of creativity, personal experience gains because you're restricted to a particular way of doing everything.

Where I work, we analyzed 'what parts do we -really- like about frameworks?' - most all answers pointed to simple things that could be solved with some additional library functionality (which we wrote ourselves) and continue to snowball the functionality.

Gravatar for Lukas

Lukas Says:

@Justin: Yeah, especially Zend Framework has muddied the term "framework. They are clearly a library.

As for this "plug" vs. "unplug", so far I have mostly seen false pride or just wanting to call every last bit their baby as the driving reason against going from a generic solution to a specialized solution. The end result of starting from scratch has never impressed me. And like Brian points out if he would switch jobs he would likely miss his "specialized" framework because he got to invest so much time into and make it his. We just get used to stuff and more importantly because we know it and what problems it solves it makes us faster. So the question is just finding the right framework and I guess some just believe that only they can develop the right framework from scratch.

Though from scratch likely (hopefully) then at least consists of taking some standard extensions and user land libs to get started.

Gravatar for Gerard

Gerard Says:

Great post, Brian.

IMO, working on a platform or product company gives you depth. Working for clients in an agency or freelancing gives you breadth.

And the grass is always greener. Product-types learn a lot about scalability, caching, multiple databases, etc. The code ends up super-optimized and customized to deal with challenging architectural issues. But at some point they get tired of working on the same codebase and the same product, and want to work with other technologies and other people.

The client-types do a lot of shallower (as someone above put it) projects. Lots of corporate sites, ecommerce sites, crank and churn. They see a lot of brownfield projects and experience a lot of competing technologies. But at some point, they want to go deeper and look at how to build a really high-traffic site.

And then everyone swaps places :)

Gravatar for Jatin

Jatin Says:

Great Article. Thank You for throwing some light on frameworks.

Gravatar for Nate Abele

Nate Abele Says:

Brian, you raise some good points about the trade-offs of performance implications and potential future restrictiveness of a framework on long-lived applications. There are a couple of different ways to look at this.

The first and most obvious benefit is the significantly reduced ramp-up time. Over the lifetime of the application, this means less and less, but the business value of having a working application that much sooner could be significant. Also, I've always been of the opinion that, as long as you have a good architecture, the best way to solve performance problems is just to get the app into production (or QA testing, or whatever) then figure out the pain points. Trying to guess what they'll be just isn't worth it.

Another thing (and this falls somewhat under the development speed category) is that frameworks provide a structure for how to build an application, which gives you much less to think about up front. To answer the question raised by another commenter, this is one of the key differentiating factors between frameworks and libraries.

I think the most important point you raised was about trading off flexibility as your application "outgrows" the framework. For any long-lived application, this is nearly inevitable. With Lithium, we've recognized this and tried to make replacing components, and eventually whole architectures, as easy as possible.

This idea is tied directly into our approach to dealing with performance problems. As your application grows, if and when the generic parts of the framework aren't working out for you, drop in some hand-coded replacements. Just don't treat it as a problem until it's actually a problem. :-)

Gravatar for Gerri

Gerri Says:

Now I feel stipud. That's cleared it up for me

Gravatar for jshrek

jshrek Says:

My prefered framework is PHP DevShell
http://www.phpdevshell.org/

Gravatar for IcemanX

IcemanX Says:

Try crVCL http://en.cr-solutions.net/p/projects

and you get Rapid Application Development for PHP with full MVC support!

This is the best alternative to Zend Framework for Enterprise Web-Application, because one of the core characteristics is performance and stability.

Gravatar for James Sugrue

James Sugrue Says:

Hi Brian
I'm one of the editors over at DZone, and I think your blog would be a great candidate for our MVB program. You can read more about the progam at dzone.com/aboutmvb. If you're interested, send me an email and we can discuss further.

Thanks!
James

Gravatar for Joe

Joe Says:

That's cool.I am agree,"PHP is a framework".

Gravatar for Joey

Joey Says:

I was recently doing some research on what were some of the best PHP frameworks available and came across Yii. I have some limited experience with another PHP framework called CodeIgniter. I am looking at rewriting a major website that I initially created without a framework back in 2003. Naturally considering how long these websites live, I wanted to get a framework that was robust with a moderate learning curve considering my very limited free time.

My perspective is one of a software developer with a strong PHP and Java background with experience using multiple web UI technologies. I am currently working on creating high traffic, enterprise mobile websites and was looking at Yii for all its features and best of all, for its performance, an area many frameworks don't emphasize. I am also interested in this framework from an architecture point of view as well. I read through this book noting examples of Best Practices from what I consider a top quality framework.

I purchased "Yii 1.1 Application Development Cookbook " by Alexander Makarov from Packt Publishing( http://www.packtpub.com/yii-1-1-using-php-framework-application-development-cookbook/book) and I wanted to give my review of this book.

This book uses its 13 chapters to cover all of the Yii topics that define a good framework such as: Ajax and jQuery, Working with Forms, Testing your Application, Database, Active Record, Error Handling, Security, Performance Tuning, Extending Yii, and using External Code. Each chapter stands on its own because it uses a "yiic" app generator command to create a fresh copy of a Yii application. I love this part of the framework because this app generator creates login page and a basic home page and if you've ever tried to start a new application the login page with one of the most important pieces of an app yet one of the most boring pieces to work on. Thank you Yii for making this part as easy as a 1 line command.

Since this book is a "Cookbook" style approach to using Yii to build wep apps, you'll find each chapter full of examples and each example uses the following sections to round out each example: Getting Ready (example setup), How to do it (main content of the example), How it works (content explanation) , There's more (where to go to learn more) , and See also (reference to related sections).

I was particularly impressed with how well jQuery was integrated in Yii. It was nice to see that a framework was created with client-side coding as a core feature not an after thought. The Ajax and jQuery chapter covers not only using the jQuery core JavaScript library but also how to register any JavaScript library including your own custom libraries. The examples are well designed and thoroughly walk you through how to implement each MVC component, creating the data model, the controller and the view components. Each chapter's examples use this approach and follow up with some helpful reference links for further reading as well as some sub-chapter references that point to related material for the example and are useful to add more clarity. The tasks that the examples are trying to solve are well thought out to cover multiple scenarios in detail. If needed, you'll have another section called "How it works" after each example to fully explain how the logic flow of the example.


Each chapter fully defines the subject matter with useful examples illustrating how Yii uses the "Configuration by Convention" model to build web application components. You won't find re-used examples from the API documentation, but rather real examples that you'll need to not only make top quality applications but also you'll fully understand how Yii works when you consider the reference material provided to augment the examples.

There were some areas that gave me some trouble in reading through this book. It seems this book does assume some level of knowledge of Yii because this book didn't explain Gii on its first mention. This will mean you will have to reference the Yii documentation to fill in any gaps if you are a pure newbie to Yii as I am, but it may be best if you start off with a starter book such as "Agile with Yii 1.1 and PHP5" by Jeffery Winesett to get a good foundation on Yii before learning some of these advanced topics that this cookbook covers.

Overall, I would recommend this book because if the excellent examples in each chapter, the complexity of the tasks that make up the examples and the complete coverage of the topics in all the chapters. I could get by with just this "cookbook" but I'd feel like I am missing something by not starting with a beginners book to learn the full breadth of Yii. In a pinch, this book can get you past your needed tasks.

If you are interested in viewing a sample chapter of this ebook one is available at http://www.packtpub.com/sites/default/files/5481OS-Chapter-8-Extending-Yii.pdf?utm_source=packtpub&utm_medium=free&utm_campaign=pdf
 

Comments are disabled for this post.