Eric complained about implementation-specific language features in JavaScript -- things that only run on some, but not all of: SpiderMonkey, V8, JScript, and Nitro. To quote:

    Instead of coding in one language, we're actually coding 
    in two. One is the subset JavaScript that can be run in 
    all browsers, and another is the set of JavaScript that 
    can be run by Node.

He's not talking about features specific to the Node API, but to features present in V8 that are lacking in older versions of JScript, effectively. A lot of Node libraries use features like Array#forEach, Object.create, Array#indexOf, Function#bind, making libraries unusable in the browser, even when they should be able to run perfectly well there.

CoffeeScript doesn't prevent you from using implementation-specific features if you want to, but provides in-language alternatives to all of the things listed above, in a cross-browser fashion.

Objective-J works in the same way, doesn't it? It's possible to write Objective-J code that is tied to a particular runtime, but if you write in the regular style, you won't have any cross-browser trouble.

When he said "language" I guess I automatically translated that to "APIs" since that's usually what people mean when they complain about incompatibility in JavaScript environments.

Differences in the JavaScript language in engines are fairly minimal these days (BTW all the features you mentioned can be added to legacy engines, see http://github.com/280north/narwhal/blob/master/engines/defau...) I think the bigger problem with sharing code between client and server is the libraries that unnecessarily tie themselves to APIs specific to each environment (i.e. the DOM and other browser APIs, and Node.js or other server-side APIs)

First -- your global-es5.js module is awesome. I frequently point folks to it for a way to bring old browsers up to speed. But at the same time, if you don't include a library like it, you have to admit that there are 30 core functions in there that it's easy to depend on, and that the global-es5 implementation isn't perfectly compatible with real browser implementations, it's just very close (Object.getPrototypeOf being a good example of something you can't fix).

The other approach, and the one that Eric is lamenting, is writing lowest-common-denominator JavaScript. The problem he calls out in Node isn't that it's not possible to write cross-implementation libraries -- but that people aren't doing it. There are tons of Node libraries which could very easily run in the browser, but don't. Just browsing through NPM, here are three random ones:

http://github.com/visionmedia/lingo/

http://github.com/Marak/Faker.js/

http://github.com/past/speller/

All of those do nothing Node-specific, but use JavaScript features that aren't present in IE6, 7, and 8.