Wouldn’t it be cool to take java’s slogan “write once, run everywhere” and implement it on other things? For example, we can create an Ajax API that decouples the server functionality from its implementation. One would be able to replace the server implementation (lets say from PHP to JAVA) and evaluate performance, stability and scalability variations without changing the web application front-end code itself. Creating such standard API will result in several server-side implementations (hopefully, some of them open source) competing over the web developer community, this competition will mean better products.
We have tested this concept with our latest open source project AJAXDO. Ajaxdo enables runtime loading, saving, deleting, and listing of JavaScript objects stored on a server-side database. Because it has a JavaScript API with multiple server side implementations, using Ajaxdo can reduce server side code and make a Web 2.0 application port easily from one server-side programming language to another. Initially, we’ve implemented the server-side in PHP and have just finished the Java server-side version. It was really nice to see the same front-end application code work with different server side implementation with no code change.
AJAXDO is an example of front-end and server-side decoupling. A full blown standard should include, among other things: security, object passing/storing, some sort of server-side business logic invocation, and even transactions. Now with rise of activity around web 2.0 applications and software-as-a-service concepts it might be a good time to start working on such standards.
What should this front-end and server-side decoupling standard contain?
The standard must contain a mechanism for backward compatibility between layers (front-end and business).
So, instead of writing one version of server side code, you write
(and maintain) 2,3...etc.?
And instead of tight control that comes with the code
deployed on server, you mix both the presentation and business logic
and then let it loose on the client?
Don't forget about browser incompatibilities, security issues etc..
Who needs it
I agree with Tom. Ajax is a powerful tool that when used correctly can greatly enhance the web user's experience. Beware however that Ajax is not a panacea. If we load everything up in our presentation layer we will have all-in-one mammoth jsps that will be a hell of a lot harder to maintain.
In any case if you had to pick one thing that sould stay indipendent and unchanging it should be your business layer. It is much more often the case that we need to decouple the business from the front end and not the opposite. Provide multiple views of the same business.
Don't get me wrong. Ajax is great and is the present and future of client side code but lets not overdo it.