Are you sure this isn't a language pissing contest? Cause I already said I don't do that, OK?

Now then...OK, sounds like we were in different segments on what you were getting at about cross-platform deployment. I've seen it work well with Java on the server side, as long as IT pays attention to the basics like installing the correct JRE.

Cross-platform on the client side also depends on some stipulations. Whenever I talk about stuff like this I'm thinking of the modern DOM-compliant browsers like Mozilla et al and IE; I try to forget those older browsers ever existed. Both are in the ballpark, and after some struggle Mozilla's edged ahead recently. I now design to FireFox and adjust for IE later. And there are some minor differences, you're right, but in the DOM implementations rather than JS implementations. Both JavaScripts are highly compliant with the ECMAScript spec. It's how the browsers implement the HTML DOM that requires adjustments between the platforms. Quantitatively, I'd say about one line of JS in 300 (in a large code base) is devoted to platform-variant code.

As far as JS/DOM interfaces supplanting Java, I'll stick to that. It's funny how you hit the nose on the head when mentioned that you had troubles at 1.4.2 to 1.5--that's what killed me, too. And it wasn't because we didn't follow Sun guidelines, it's because Sun for some damn reason decided to change a string return (across the interface from JS) from a primitive string to a String object (or maybe it was the other way around). Go figure.

So if the platform's going to mutate on you one way or another, I'd rather depend on a platform defined by an international standards body than by Sun. For all the hype about Java's standardization and openness, in reality Sun's control is so absolute that Java is essentially proprietary.

Once past the cross-platform speedbumps, the real question is capability and suitably of Java versus JS in applications you'd typically see on the Web. I assert that there are very few things that Java can do that I can't do with JavaScript controlling the DOM.

The advantage of JS/DOM is particularly vivid in the UI. The HTML platform is visually rich, easily laid out, and in all ways aesthetically superior to what you can reasonably do in Java. By "reasonably", I mean with the controls and components available to mere mortals; Java applications look like computer applications. You could devote a few manyears to creating a fancy Java display engine rivaling the HTML rendering engine...or you could use the HTML engine you get for free in the browser.

Note that I'm not saying that it's JavaScript alone that gives the platform so much power. It's the combination of JS + the standard DOM that kicks ass.

The browser platform begins to hit the wall when you attempt high-quality/high-speed graphics and animations. There's a limit to complexity of objects and motions you can manage, and performance issues when you try to do too much. You might do that stuff better in a Java applet...or, at exactly that level, you might turn to Flash. I might say that Flash is JavaScript, but ActionScript is actually JS 2.0, which has never made it into the browsers. Flash is mostly Flash.

My opinion that Java applets are on their way out is based on the notion that it's being boxed-in at the low-to-mid-range by JavaScript/DOM for a wide range of common tasks, and at the high-end by Flash, which is optimized for graphics-heavy complex apps. Where is there a niche on the Web client side that only Java can fill?

To be fair I can think of a few niche examples. There are a lot of cool scientific visualization applets that probably are better done in Java. Encryption is also better done in Java, in part because of the nice crypto libraries (I could use on-page strong encryption to set up a secure BBS or chat system, for example). Speaking of chat, Java has more discretion to open ports and make connections than does JS. There are some domain and host security restrictions on that HTTPRequest component I mentioned earlier, so if I wanted a page to talk to a foreign server I'd have to turn to Java.

Mainstream, though, Java applets are fading away. Sorry.

In what may be the coup de grace, I should tell you that what I did at eBay was LiveAuctions 2.0. Version 1.0 was a full-page Java applet, and everybody in the world hated it. Users thought it was ugly as sin and awkward to use; management and the engineers couldn't stomach another round of development to add the large new feature set. The applet made sense a few years ago for broad cross-browser useability in a field of crappy browsers (it ran in Nagivator 4.7...ewwww!); but by the time we started 2.0 we could design for DOM-standard browsers. JS/DOM replaced Java applet and did a much better job. That's the longterm evolutionary trend in the real world. I was there.

And that was just Java versus JavaScript. Geez, now there's .Net. I hope it's obvious I have very little energy in defending or promoting .Net. I'll be wrong soon anyway, as soon as the wheel turns.

Probably the one thing that best illustrates what I think is innovative about .Net is the cross-language application of the CLR. VMs aren't a novelty by any means (BTW, didn't Forth come before SmallTalk? If so, I win the Most Grizzled Programmer Award). It's just that where, to Sun, the VM was a feature of Java, to Microsoft the languages became features (or instances?) of the VM. I talked about being able to see the "language of computers" underlying each "dialect"; the CLR resonates with me because it makes the underlying layer even more concrete. And ironically, given Microsoft's reputation as the mean monopolistic bully, the CLR design allows third parties to develop languages that run atop it. Would Sun ever, ever, ever permit Java to be polluted that way? Microsoft open, Sun proprietary...sweet.

And wow, that's about all the energy I have for .Net.

XML, beautiful XML...I agree completely, it's manna from heaven. It means different things to different people. To me it means finally being able to store data in its natural form, following the hierachical structure of most real-world data. No more linking together vast numbers of tables to basically simulate hiearchies of data. And interoperabilty. And SOAP (did I mention that HabitableZone 4.0 will be a WebService?). And XSL rendering (Zone 4.0's user interface will use HTTPRequest to make a SOAP call to the server, and will render the returned XML directly into the page using a stored XSL stylesheet.) Sweeeeeet!

It's late, I gotta gooooo....