Request/Response or Bust

  • Posted by Mike Naberezny in PHP

    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.

    As technologies very close to HTTP like REST become more prominent, abstract components like those in .NET and Java become less relevant. At least, these kinds of components become much less convenient than their initial promise. AJAX on the component model is a double-edged sword. While event-driven architectures are ideally suited for processing asynchronous requests, it takes a lot of sophistication for component frameworks to automatically emit good Javascript for client side. So far, it hasn’t really happened.

    Microsoft’s solution to these challenges is to continue even higher up the ladder of abstraction, while Ruby-on-Rails’ much simpler notions of “components” and Javascript generation is much the opposite. Rails provides a bit more convenience but still stays close enough to the familiar paradigms of HTML generation and HTTP request/response to give good control.

    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.

5 comments

  • pingback by Knut Urdalen’s Blog » Why PRADO? 26 Apr 06

    [...] whole application in the end. Update: Mike Naberezny have some thoughts on this topic in his post.
    Entry Filed under: PHP

    Leave a Comment

    Nam [...]

  • comment by Cal Evans 26 Apr 06

    You are right, PHP page-based model dominant because PHP developers work close to the metal. Most PHP developers are multi-discipline developers who do graphics, HTML, scripting and more. Because they spread their skills out they do not generally have the depth that traditional developers do. Therefore they gravitate towards models that are easy to understand. The majority of code (other people’s code) I work on these days uses PHP to create ‘dynamic’ web pages. (dynamic in the 1999 definition of the word, maybe data-driven is a better description.) In most of these situations, the level of sophistication is very low as is the level of understanding by the developer and won’t support more intense concepts like MVC or even abstractions to a great extent. I believe that this is why .NET is struggling in the web space. The concepts are too abstract to be groked quickly.

    As we see PHP mature with 5 (and I anxiously await 6) and we see web based applications as a whole move out of the 1999 model and into true applications, I believe we will see a movement towards frameworks like PRADO, .NET., and what JavaBeans was supposed to be. The developer base is already maturing, the evidence is the proliferation of frameworks. I believe (as you seem to indicate you do) that the model of the future will be Rails, not .NET. While AJAX on the component model is difficult because of the amount of Javascript that has to be generated, libraries like prototype and YUI are easing that pain. AJAX is important for the UI components of any good framework.

    I think as the dust settles in the framework space, we will see a rise in the component libraries like ez components and their ilk. I hope that their developers will learn from the mistakes of Java Beans and come together to form a concrete spec, an RFP that is adheard to by all for how components talk to each other, the underlying framework and even to the IDE.

    IMHO, etc…

    =C=

  • comment by Mike Naberezny 26 Apr 06

    “and we see web based applications as a whole move out of the 1999 model and into true applications, I believe we will see a movement towards frameworks like PRADO, .NET., and what JavaBeans was supposed to be.”

    The term “true application” is far too nebulous.

    “I believe (as you seem to indicate you do) that the model of the future will be Rails, not .NET.”

    The Ruby-on-Rails project, as I understand it, is about extending the Ruby language into a Domain Specific Language (DSL) for writing database-backed web applications using agile methods. At its core, it’s not about building frameworks or components, it’s about extending Ruby to service the needs of agile web developers. While there’s certainly overlap, the future of PHP applications can’t be the Rails language by the definition of their project. PHP is its own language.

    PHP itself is DSL for developing web applications but is much more generalized than Ruby-on-Rails and not tied to a development methodology. I believe that for this reason, not just its age, that PHP has a larger potential audience. I think that a lot of Rails’ ideas apply to the problems that I’ve had developing apps. However, PHP is too generalized and its users have such varying needs that it’s hard to speculate whether these ideas suit the majority of PHP developers. I think there’s a lot of overlap, but PHP and Rails definitely have a different focus and potential audience.

    What I said in the original post is that Ruby-on-Rails is much closer to the familiar paradigms than .NET and friends. It is not total abstraction, rather it molds applications into a more manageable MVC structure while not getting too far away from the fundamentals. I think their ideas are more applicable to the PHP space as a whole than those of .NET.

    “I believe (as you seem to indicate you do) that the model of the future will be Rails, not .NET.”

    Mixed messages here. You say that you expect a movement towards component frameworks like .NET or PRADO. Ruby-on-Rails embodies everything that is the opposite of Java or .NET component frameworks and its developers could not be more outspoken against these. They openly oppose any attempts to make a component framework on top of their system.

    “While AJAX on the component model is difficult because of the amount of Javascript that has to be generated, libraries like prototype and YUI are easing that pain.”

    Prototype is a lightweight layer on top of Javascript that facilitates writing Javascript in a class-based style with mechanisms for observers, iterators, and other conveniences for writing your own Javascript.

    This is entirely different from something like the .NET environment, where you drop a DataGrid onto a form and it emits some Javascript automatically. I agree, extensions to Javascript like Prototype will become more prevalent amongst PHP developers. I think it’s a natural evolution as developers’ needs for Javascript increases. I don’t feel the models of .NET or JavaBeans are a natural evolution for PHP. If you want these, use .NET. It’s more mature, has a large enterprise backing, and very sophisticated tooling (now free!).

    “I think as the dust settles in the framework space, we will see a rise in the component libraries like ez components and their ilk.”

    Projects like ezComponents or Solar are not components at all in the .NET or JavaBeans sense. They are class libraries where the classes descend from a common superclass and follow similar conventions. The scope is much more limited, the classes are much lighter weight, and the classes may encourage but don’t force an application model. I agree that projects like these will continue to proliferate in the PHP space. As I said in the original post, I don’t see the natural evolution of these as moving to something completely away from the existing PHP and HTTP request/response paradigms.

    Thanks for your comments.

  • comment by Steph 17 May 06

    - so Rasmus was right and JSON support should’ve been in 5.1.0.

    It’s coming, no worries.

  • pingback by RJHarrison.org » Blog Archive » ZF + DOJO = Bleugh 21 May 08

    [...] Mixing the server-side and client-side is a bad idea in my opinion and it moves down the “let’s abstract HTTP” path. Mike Naberezny (and Paul Jones) published some thoughts about this a couple of years back (http://mikenaberezny.com/2006/04/26/request-response-or-bust/). [...]

Post a comment


Thanks for commenting. Please remember to be nice to others and keep your comment relevant to the discussion. I reserve the right to remove comments that don't meet these simple guidelines.