But the server side is dead. OK, that's a ridiculously massive exaggeration - being sensible, clients are getting thicker and consequently servers are getting thinner. And clients are getting thicker because of the increasing power of browsers and the understanding that it's a lot simpler to handle client state in the client than to manage it by passing it back and forth to the server in multiple requests. Ajax, Web 2.0, Web Sockets, HTML5 - increasingly the web is about delivering a thick client to the browser that then only does server-side communication when it actually needs to get data or persist data in a form that is non-local.
However, the joy of languages that run outside the browser is that if you disagree with the way a language does things you can use a different one you prefer. You don't need to have religious wars about it, there doesn't need to be a One True Language To Rule Them All - you want to hack in Delphi, off you go and hack in Delphi. That was why Apple's decision to limit the languages in which you can develop for the iPhone was so wrong. (You want to be employed by someone else to write their code for them and you'll have to do it their way, but that's life as an employee.)
What I would like is if browsers could interpret JVM bytecode, not in an obscure Japanese framework that seems to have died, but natively in the browser with the browser having the common runtime classes so they don't have to be provided in every case. Then we could at least use Java, Groovy, Scala, Jython, JRugby, Clojure and others to write our client side code. Of course that's still a very JVM centric view of the world; I'm not really sure how you could do this with languages like C and C++ that compile directly to machine code and expect to manage memory themselves, but you could certainly imagine doing it for the CLR byte code and so make all .net languages available (IE probably does this, for all I know).
(Am I revealing my lack of knowledge of Applets here? I think of them as virtually stand-alone applications, rather than natively working with the browser events, XMLHttpResponses and the structure of the DOM, but I've never really used them in anger - I sort of assume that since GWT isn't applet based they don't give you what I'm talking about, but I guess it's possible that Google decided to go the GWT path to avoid needing the Java plugin on the browser...)