Joel Spolsky has a a great new piece about how Microsoft lost the API war (via Tim Bray). You should definitely read this if you're a programmer, especially if you're working with Windows.
Spolsky's basic point is that the strength of the Windows API has always been in its backwards compatability, but that with new-fangled things like .NET and the stuff that will be in Longhorn they've basically thrown the baby out with the bathwater by sacrificing that compatability. Of course programs written with the old Win32 API will continue to work for years to come, but the party line is that you should be using these newer APIs.
It looks like the result is going to be ever more web applications. I'm with Joel on this: it's sad that we're losing the power of desktop applications to provide rich usable interfaces, to the basically inferior browser-based platform. There are some things where it really makes sense to be able to access your application from an internet café, but the cost in usability has to be paid.
I don't think the rich client is dead though. The application I'm working on at the moment has a rich user interface as one of the main requirements. The whole point is to make it faster and easier to use, so we're providing lots of little interface tweaks, like disabling fields that aren't appropriate at a particular point, and making some text boxes auto-complete with appropriate values. A web-based interface just wouldn't be appropriate for our client, however much it would make my life easier.
.NET is not the answer
A few months back I dipped my toe into the .NET world and tried writing some C# (mainly to see what's been happening in the Windows world since I abandoned it for Linux 5 or 6 years ago). The language is quite nice (compared to C and C++ at least) and the API is much more friendly than the Win32 C/Pascal API (or the foul MFC). I'm not going to be using it seriously though. I've got enough problems right now trying to work out how to deploy a complex Perl application on Windows desktops, so I don't want to end up wrestling with the .NET deployment nightmare.