It’s coming, no worries.

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.

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=

Leave a Comment

Nam [...]