Tim Bray, a Distinguished Engineer and Director of Web Technologies at Sun Microsystems has been interviewed by InfoQ about the future of the Web. With all my respect to Sun’s engineers, I have to disagree with some of the statements Mr. Bray made.

He said, "Anything that discards the Back button is a step backward".

I strongly disagree that people who are used to the page-based Web apps can’t/won't learn how to live without it. But even if it is the case, you can create RIA that support Back button - just decide what application view (no page) to show when the user hits the Back button.

Here’s one more of Mr. Bray’s statements, "The whole universe runs on polling and it scales beautifully".

I don’t think so. To support server-side push an application has to keep an open socket connection that doesn’t take almost any resources most of the time. For a server, it's easier to keep open 65000 connections on the server, than repeatedly responding to multiple requests from 65000 clients when most of them return "Sorry, I don't have any new data for you".
I agree that opening a socket present issues for Web applications running behind firewalls, but still the whole polling universe doesn’t scale beautifully.

Mr. Bray continues, "Web applications are not computational intensive".

Of course, if you are using page-based applications that just show the data, there's nothing to do on the client other than, well, showing the data. But in the world of RIA, we should get into a different state of mind - you can and should treat the client's CPU as a first class citizen.

For example, our company helped Mercedes Benz in design and development of their Flex-based RIA: www.mbusa.com

. There's a bunch of interdependent rules for each car model that should enable/disable UI controls depending on the user's selection. For example, if you ordered white leather interior, you can't have yellow exterior.  We've implemented the entire rule engine on the client, which makes the entire system a lot more responsive.

During one of my recent presentations, I said that if you build Flex/Java RIA utilizing fast AMF or RTMP protocols, you can bring 5000 records and keep them on the client in a split of a second.

A person from the audience asked,
"Why would I even need to keep 5000 records on the client?"
"Because you can! Of course, something like this sounds wrong for AJAX applications, but it's normal to bring 5000+ records of reference data to the client and keep them in the client’s VM so the user's application wouldn't need to do a round trip to the server to validate user's input".

If you offload the processing to the clients, you don't need to horizontally scale the servers.  With RIA, you can afford to have Client/Server mentality again.

Mr. Bray believes that the direction of Web applications is moving form J2EE to PHP and Rails. He didn't make it clear for what kind of applications though. Is he talking about applications like Twitter that can go down several times a day and people will keep using it because they don't have any better choice? I've heard creator of Rails calling Java legacy, and I understand the populist nature of such a statement, but it's strange to hear this from one of Sun's higher ups.



In this case Tim Bray is right. But if you take any application that handles your money (Banking, eCommerce, auctions) I'd rather stick to tried and true J2EE on the server and the RIA client  software (Flash Player, Silverlight, JavaFX) that runs inside a predictable Virtual Machine.

I believe that Web moves to a VM-based stateful clients with fast communication lines between the client and the server moving tons of strongly-typed data back and forth. This was a mouthful sentence, wasn’t it?

This article has been originally published on the Yakov Fain's blog and is printed with author's permission.

• Getting from PowerBuilder to the Web (Revisited)
• Getting from PowerBuilder to the Web (Revisited)
• Delegates at Second Annual World Congress on The Future of Work to Hear from Philadelphia's CIO about Wireless Philadelphia Initiative