Home >
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 you need 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?
Tag Cloud
Podcasts & Screencasts
@InsideRIA on Twitter
Follow InsideRIA on Twitter
Facebook Application Development
Have you seen the memory usage of Benz Web Site
Rails creator never said Java is legacy and twitter problem is not Rails, is database trasactions propagation.
I think page based websites will also have a place and will not go a way any time soon. However there are cases where you want a more interactive experience. Also visual data has a way of communicating that textual information just doesn't convey. The field of data visualization is predicated on that. AJAX is just not a solution.
To your point Daniel, I think most nontechies are not worried about memory consumption/CPU usage when they are at a website.
@Parkash - Memory use on the client's machine is not a killer, but there is some memory leak in Flex modules that eventually will be ironed out. CPU utilization is more important. BTW, when you configure your car on that site, rule engine runes on your PC (not on the server) to validate your choices.
@daniel Listen to DHH talk on legacy software from RailsEurope conf. If you don;t have time for all, get it at IT Conversations and FF first 6 minutes.
He said there that Java is legacy.
The main point of legacy software of DHH presentation is point no only Java or PHP will be legacy but Rails to ( because many Rails developer thinking PHP and Java are legacy and Rails never be, the idea of DHH is oposite and any Rails app will be legacy only depends of time ).
@Parkash, users will be really ungry when their browser break because memory issues (it's happen a lot in flash world website if you don't worry about remove listeners specially enter-frame) and happen a lot in Js world, so if you can process a lot of data on client and still have a good performance is great.
In my point of view the future are plugins (like Flashplayer and Silverlight) but also a more robust HTML and CSS (safari already suport html5 and css3 ,mozilla will soon). For me page like webapps or sites will be there for a long long time.
Way too technical for me but one thing i agree with, I can't live with the "back" button. By Hotel Prague.
"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"
Right, but you still have to implement server-side validation and make sure all data on the client and server-side is in sync. This is dangerous for the data. The other issue I see here is that parts of the logic is on the client and part on the server. Been there, do not want to go back there. You don't need 5000 records on the client.
I've seen an AJAX application that was working with J2EE on the server. They've implemented Blaze rules engine on the server. The application didn't perform well for other reasons, but they decided to make the users happy and duplicated the rules in JavaScript on the client.
By the time I was given it for an architecture and code review, the HTML/JavaScript portion was 4MB...and the application was even slower because it took a while just to bring this code to the client.
Why would you want to implement the same rules both on the server and the client?
Experience matters.
@Parksah,
If I am finding a cool experience, I am not care about the memory usage. for example, I love world of warcraft, I don care about how many memory it uses, 2GB not enough? Just add 2GB, I care about my experience from consumer perspective. Controling and managing the memory, CPU or other hardware resources usage are business of tech team. Consumers ONLY take care of EXPERIENCE. If I can buy a Benz with that cool experience way, do you think I still have time to open the system monitor to see the memory usage?
So, please see the web future from a consumer perspective, thanks.
"you can and should treat the client's CPU as a first class citizen."
totally agree.
especially when creating apps/ games for children and students.
Often this kind of content will be consumed on 'public space' computers such as in libraries and schools or hand-me-down computers in the home. None of which are likely to have especially muscular CPU
Your RIA should not be about the client cpu it runs on. I always point people at this 37signals post because it's so true http://is.gd/aHW6
Too often devs build RIA to run on the high-end machine they build on rather than the one the audience has.
The back button and other habits such as using tab to skip from one field to another are user habits that you can build on but don't necessarily need to take into account. But you'd better have a good reason for it. Ideally your user doesn't have to worry about whether or not its Flash or whatever, and the best way to accomplish this is to respect codes such as the back button. I've posted on the subject before:
http://arielsommeria.com/blog/2008/10/04/using-flash-without-it-getting-in-the-users-way/
Ariel
@Simon
You're right about the need to test the software on crappy machines. What's even more important is to test it on a slow connection. Today, you need to spend some time making sure that your RIA loads at a decent time on a machine with DSL connections - 512Kbps (one minute is OK for such slow connections).
"Why would you want to implement the same rules both on the server and the client?"
I wrote a bespoke javascript validation routine some years ago for a 'classic' ASP data capture application. Using runat="server", I could run exactly the same validation on both the client and server, creating a single point of maintenance and reducing unnecessary round trips.
The approach may not work so well on much larger applications or rules engines but the .js download was trivial. These days even more so given a javascript compressor like YUI.
"I don’t think so. To support server-side push you need 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."
Not every ria belongs to a firm with even what most of us may consider a minimum level of resources. I know it sounds trivial to a worldwide firm, but a fresh startup or home grown web resource has even less bandwidth than 65000 persistent connections require. Without "a round of funding" :), some have to make due with a single proliant running on their personal dsl, if not less.
I think that has something to do with Bray's idea of "scaling".