Request/Response or Bust
My friend Paul M. Jones recently wrote about a component framework called PRADO. The idea of a component framework for PHP is certainly nothing new, with PRADO having won Zend’s coding contest a full year ago. There’s even phpBeans, and PRADO provides some integration with these. PRADO is getting some new attention because it was completely revamped earlier this month. It’s certainly matured considerably since the contest and is the most well-known component framework for PHP. However, in all that time since PRADO was first introduced, the idea of a component framework hasn’t been adopted by the majority of PHP developers. Why is that?
Although PRADO is a nice piece of software, Paul surmises that a component model as used by Microsoft .NET (Visual Web Developer now free!) and its close cousin PRADO is not the “PHP way” or “PHP spirit”. For the most part, I agree with this. Although, I don’t think it’s necessarily a PHP-specific issue. I think it speaks to a larger architectural decision — how far to abstract out the HTTP request/response paradigm.
For the majority of websites out there, web application architectures can be lumped into three broad categories, ascending up a ladder by the level of HTTP abstraction:
- “Page-based” or “file-based” systems are at the bottom. These comprise the majority of CGI and PHP applications. In this style, the application’s files are stored in directories that map directly to URLs. HTTP requests come in, the URL points directly to the file which handles the request, and the response comes out.
- “Action-based” – While not necessarily part of the MVC pattern itself, this is the style used by the majority of MVC architectures. Ruby-on-Rails, Apache Struts, and Paul’s Solar framework are examples of this type of design. Typically, URLs are initially mapped to controllers and actions within those controllers. These will then chain together into a workflow for processing requests and rendering responses. While at a higher level than page-based systems, the majority of these implementations are still request/response driven, and thus aren’t so much farther away from HTTP.
- “Component-based”, such as Microsoft .NET and PRADO are the furthest abstraction from HTTP. In these architectures, the request/response paradigm of HTTP is completely abstracted out into an event-driven architecture. Components are objects that simply respond to events, and the interaction between components and mapping to HTTP are all handled by the infrastructure of the framework.
What’s interesting is that in PHP, page-based is still dominant for most of the web while the action-based (really, MVC) systems for PHP are gaining the most mindshare. These are becoming increasingly prevalent as application complexity continues to increase. The majority of PHP developers seem uninterested in component-based architectures.
Perhaps it’s because PHP has always been about “getting it done”. Perhaps it is also because the best PHP developers are also used to working close to the metal, always striving for that perfect CSS or fastest page load. As the level of abstraction increases, the ability to tweak and control the application and its rendering tends to proportionally decrease.
Good old HTTP seems more PHP-like to me than the Microsoft or Java models. What do you think is the next step for PHP?
Update: Python blogger Ian Bicking has some great thoughts in his post, HTTP(ish) all the way down.