HTML 5 and client - server apps

Was listening to this: http://www.infoq.com/interviews/HTML-5-Ric-Smith interesting stuff as always, thanks InfoQ, I really needed to hear what's the fuss about HTML5. I say it's Pandora's box. Meet me at a beer and I'll explain cause it's going to take all night :-D

However there is this question asked by the interview-er which I just couldn't stand responding :-)

One of the trends that I have seen that seemed to have occurred several times: when you start of you have the main server, you have the dumb terminal and logics gets pushed down to the clients, and then the same thing happens with personal computers, pushing desktop applications down to the clients, not being run on the server anymore. Those started to shift back and then you have web applications which are hosted on the web and instead of Flash plug-ins. Now it seems there is a shift back down, to adding more intelligence to the client, and doing more work on the client. While at the same time there is a push to move stuff from the client to the server. Is this a pattern that you see is happening as well and what do you think it's going to happen in the future? Will we continue to do this back and forth or not?

I think, at least in the Java community, all evil started with Struts. Yes. Most server side frameworks used this paradigm of receiving a request, rendering a HTML page and send it back in response. And yes, there may have been some valid reasons to do that, but not all. And it wasn't the only alternative. AJAX is with us since many many years but it got lots of publicity and traction with the clients like GMail appearing. As a long time GWT runner now (and not only GWT but I'll stick to that mainly) I can see, hands on now, how the HTML rendering on the server side was a huge mistake.

So let me put it this way:
Spending CPU cycles on the server side for rendering HTML is simply wrong. All the flow and UI rendering and event interception SHOULD happen in the browser. You go back to the server if you want to access persistent data or want to coordinate with other thin clients (simplest example is a chat app) and send or receive data from them but that's it. UI rendering and application flow in most of the cases belongs to the client. There are few cases where you need to go back to the server for application flow but that proportion is minimal.

And as I also said here: http://lightweightyes.blogspot.com/2009/04/is-browser-new-virtual-machine.html UI rendering and application flow in the browser allows for a whole new level of scalability (rendering HTML on the server side was eating a humongous percent like 50 - 80% of the total application CPU cycles in some apps that I saw and even developed, fingers crossed !). Also in the above mentioned post I was envisioning running a Terracota setup in the browser (maybe too much beer at that time). Of course that with the current state of HTML it's not possible. But there is this thing called Web Sockets which comes in the HTML5 and this would really enable that scenario and many more. Don't ask me how practical is that, but I am sure there are Usecases where that would be appropriate, we just need a smart guy to point them out :-)

As I said: Pandora's box :-D