Javascript vs. PHP: RIA 1.0 and RIA 2.0?

Some thoughts about how to integrate Server Side and Client Side in modern web applications....

On the weekend i attended the #phpunconf in Hamburg. We had a lot of very interesting discussions there with Michael Mayer, Johann-Peter Hartmann and Cornelius Weiss about PHP in the Javascript world. In these discussions we found that there are basically two approaches discussed at the moment:

Server side frameworks integrate JS widgets into their libraries now. They try to generate JS code from templates on the server side to control the user interface. This way, forms can be enritched with some special input fields that can provide nicer user interface (for example date-pickers, grids, tab controls, etc.). The widget structure that JS libraries like dojo or JQuery provide today seem to be targeted on this kind of usage. It appears to be a solution for sites with low user interface requirmements or for a transition period. Would that be RIA 1.0?

However, a lot of applications will need much more. Users demand top-level interactivity also from web applications these days. That introduces a different approach to javascript (RIA 2.0?). The server only sends one page and a bunch of Javascript to the client. From then on, the application flow is controlled by the client (JS) code. The server only supplies data here and there and executes transactions triggered by the JS application. For this kind of application, more code structuring is needed on JS side. Fortunately, there are already frameworks for this approach. JavascriptMVC is one of them. It contains a special JS-adapted implementation of the MVC pattern and is completely event driven. It even has a template engine implemented in JS in order to separate code from html when the JS app renders data from the server into html fragments to insert in the DOM structure of the page.
With this kind of structure elements, the Javascript code can be structured in a way that even big javascript applications can be built, maintained and automatically tested without losing overview. For the application we are currently building, this appears the only feasible approach.
Especially functional testing with tools like Selenium becomes fundamentally critical when feature rich JS applications are built. There are too many details that can break and each change needs to be tested on different browsers to do it all manually.

Personally, i believe there will be both models in the future. The first approach (JS enritched server controlled applications) will probably stay around for CMS sites with little user interaction.
But the more interesting model for me is the second one. This model opens a whole new world of feature ideas but also technical design and architectural challenges for the next years.

Auf Facebook teilen

« automated build process - Namespaces in PHP 5.3, Webcast »