If its a pissing match, its a friendly pissing match as far as I'm concerned- my Ire isn't particularily up.

Quite so.

Frankly, though, I won't be trading in my JDK anytime soon ;-)

Well no. To say that the DOM environment is supplanting Java applets is to describe a gradual process that will take many more years. More importantly, Java's alive and well on the server and in embedded apps like cellphones and specialized scientific applications and... Has any computer language ever died? They may thaw out legions of Java programmer in the year 2999 to deal with the Y3K Bug...just like the army of reanimated Cobol programmers who saved us from Y2K.

I was thinking of Swing (but couldn't dredge up the name) when I talked about "reasonable" effort. I didn't work on either of the applets in my project, but I worked alongside the programmers who did, so I'm passing on their anecdotes...but I think they told me that one reason they decided to abandon full implementation in Java in 2.0 after considering a Swing UI upgrade, was that over the Net you get a huge increase in traffic as the applet goes back to the server, over-and-over, for...something Swing needs, an adapter or interface package, something like that. Sorry to be hazy. It may be that when they designed Swing, they were thinking of standalone apps and didn't consider the deleterious effects over the Net of whatever runtime binding/loading thingie is the bottleneck.

I am a little concerned that the 'cross platform' performance you attribute to javascript seems to be defined as Firefox and IE.

I have a tendency to collapse individual distinctions like JavaScript and the HTML DOM into a single concept, the browser "platform". It's in that context that I talk about "cross-platform"...and now that you point it out, it really isn't meaningful when what we're really talking about is a single platform defined by a standard and implemented with tiny differences (the "froth" of small errors in spec interpretation and implementation) by multiple vendors. I'd be a lot clearer if I dropped "cross platform" and sang the praises of a "standard platform" instead, wouldn't I? OK, that's what I mean.

There is a pragmatically-valid meaning for "cross-platform" in this area: Simply that with DOM-standard-browser use at around 95% these days, you can count on compatibility across user platforms...OK, maybe I'm reaching a bit...

As far as purity of JavaScript implementations goes, it seems as though they've always been more robust (most compliant with ECMAScript, most complete, least mutating and variant) on the browsers, over the years (and, again, it's always been the DOM implementation that's varied so wildly from browser to browser). I've also used JS on the server side in ASP (and Netscape's servers used JS), and tore my hair out trying to move code that worked on a browser on to the server. Microsoft's server-side JavaScript seems to be a brain-damaged subset of ECMAScript with nasty-gotcha differences. The only reason I had to use JS in ASP was that when I was working in the last client's JavaScript Department and building server-side tools, it would've been "unpatriotic" to not use JS.

The difficulty with recommending JavaScript resources is that they're all mainstream, and reinforce the JavaScript-is-just-interpreted-C or something-like-Java-but-not-as-good way of thinking. It's probably necessary to start there, though, so I'd recommend JavaScript.com and the various books and tutorials by Danny Goodman to get started. The thing about much of what I call "exotic JavaScript" is that it's stuff I've discovered on my own. It's been a matter of getting deeper and deeper until I get under the skin, and start programming to the script interpreter rather than the language. Knowing how fundamental constructs like the Function object are implemented (its object-ness is what allows function pointers to have members) keeps leading me into arcane applications of that knowledge. Some of it's inspired by little snippets I encounter while surfing. Reading an article on the phenomenon of "closure" (discussed in negative terms as a source of memory leaks) led me to figure out the function-generator paradigm (with attention to preventing the memory leaks that make closure something to be avoided in most minds).

I think, if we want to talk programming, we should do it on GeekSpeak in the future. Moderator Bob probably doesn't appreciate us drifting this far off-topic, but he may feel (incorrectly) that I'm allowed to break the rules. I just have a tendency to get into this stuff and forget where I am; it's not deliberate.