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 :-)
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