you're several years behind the times Hoppy.
The "everything is a web application" hype is already declining, with ever more people realising that web applications are not the way forward for a "rich user experience".

As a result, we're again in an upswing towards fat clients talking to relatively lean servers, a similar concept to that employed in the client/server architectures of the 1980s and '90s.

It's all cyclical really. From the fat server with thin terminals (mainframe/terminal, webapplication/browser) to client/server (webapp/RIA), to standalone applications (though that's unlikely to be much of a factor in the future).
We've seen it all before, we'll see it all again.
I said the webbrowser as an application hype would not last years ago, and I seem to be proven right.

It's not relevant what the current trend happens to be at any given moment in time. The fact is that what I said about the maintenance, usage control, packaging and distribution costs to companies that produce applications are significantly lower with a server based application than with a fat client apps. That will eventually rule the day.

Hoppy

Server/client doesnt necesserialy mean browser based. I just made a multiplayer strategy game that run most of its processing on the server (i used vb.net and remoting) and had a very small client

You are quite right. But it doesn't matter whether the client is a browser or a thin app that just looks (to the server) like a browser. I still think that, in the future, the fat part of the app is going to reside on the server.

My point was that just as a river does not travel directly to the sea, it meanders turning left, then right, then left again. It's goal is the point of lowest altitude, the sea. So the path of software development will travel. Its ultimate goal will be the point of greatest economic benefit. That of lowest cost.

Which doesn't mean that user interface technology will be unimportant, as was claimed.

And no, there will be a trend to offload server functionality back to the client. Part of that will be "performance" (clients don't want to wait for server roundtrips for everything, they're tired of it already), part security (yes I know, the current "wisdom" is to do nothing on the client but the reasoning will be to have the client do validation and stuff so no corrupt data even reaches the server), part of it reduction in server load (why have the server do all those non-critical tasks, taking up most of its CPU load when server hardware is harder to upgrade than desktop hardware).
There are more reasons, and indeed we've heard them all before (as well as their exact opposites to favour pure server based systems).

It may be counter to your way of thinking, but it will all happen.

I've been myself involved in operations that decentralised mainframe systems to smaller branch servers.
I've also (at roughly the same time) been involved in operations that centralised branch servers to mainframes.
Both type of projects used the same style of reasoning, with exact opposites of the actual arguments, and both were right.

It's the same with server and desktop systems. There's no right or wrong, only shades of grey and personal opinions.

don't worry my friend it will take plenty of time to out-do a technology that is continously evolving since 10 years. no threat as long as compatability, extensibility and productivity are taken care of. And consider the java community, now do u think any technology has that much of scope and time to equal java in terms of serious business.

I think you're wrong on the performance issue. Technologies like ASP.NET that enable sophisticated server based data validation without reloading the entire browser page combined with advances in hardware performance that have sped up both client, server and everything in between (broadband data transmission) continue to improve performance year after year.

I take issue with your statement that that server hardware is harder to upgrade than desktop hardware. I don't have statististics to prove it, but my instinct tells me that the cost to upgrade a server is far less that the cost to upgrade all of the clients it serves.

I will admit that it makes sense to have some basic data validation on the client side, and this is the norm for most internet apps. I also admit that it makes sense to have functionality on the client side. But if the logic to achieve that functionalify (Javascripts and what not) comes from and is maintained on the server, then the provider of the software does not have to have multiple teams of programmers and customer support staff to maintain multiple versions of the product as is the case with shrink-wrapped desktop apps. Furthermore, there is no packaging cost and no distribution cost as there is with desktop apps.

Actually, I think that we agree more than we disagree. From the standpoint of what functionality is best executed on the server and what functionality is best executed on the client side, I don't think that it can be solved with a blanket generalization. I think that it is a judgement that depends on the nature of the particular application.

That having been said, the original issue was, if I can even remember back that far, if Java was going to go away. My answer is no, but I think that it belongs on the server. I think that it is a clean, powerful language the frees the programmer, to a large extent, from the burden of memory management and resource management and after a while (maybe in 10 years time) you will not find a JRE on very many desktop computers.