Juriy Zaytsev (kangax)

Of course it's not the only way, have you seen Google's homepage? Also, JScript is actually surprising good and is nothing like the DOM or CSS, AFAIK the only known bugs are Named Function Expressions being parsed as Function Declarations (http://kangax.github.com/nfe/#jscript-bugs), and a couple RegExp bugs (http://blog.stevenlevithan.com/category/cross-browser). I suppose if you count DOM bugs, like the memory leak, that's a problem. That's where jQuery is amazingly helpful(and presumably other libraries like it). Considering Raphael is as slow as excanvas in IE (but much faster in other browsers), it's probably IE's fault, not excanvases.

> "[]+[]" throws a TypeError Couldn't agree more. But that's the standard. At some point I hoped that the ES5 'use strict' would fix all of this SNAFU, but it didn't. However, not even once I tried to sum [] + [] or {} + {} till that "wat" video. Funny, but unrealistic, therefore: close, but no cigar. One could operate the "World's safest table saw", but the common sense tells us that usually finger vs. saw => saw wins. Safer tools are desirable, but it's up to the craftsman to use them properly. > the lowest common denominator changes to V8 V8 is pretty much on par with its competition with the ES5 adoption, therefore we can hardly talk about a lowest common denominator that's actually low. The only thing that I actually missed in V8 vs. the Mozilla engines is the support for E4X (which most runtimes don't support anyway). http://kangax.github.com/es5-compat-table/ - even if IE6 and IE7 are gone from the traffic stats, IE8 is there to stay with the XP users. Some of us still don't have the possibility to just drop those users as long as the analytic data shows a fair share of legacy users. Ruby isn't part of the "similar syntax" family. The '==' operator isn't recommended in JS (and PHP). In fact, jslint yells at you if you use it. That's why '===' exists. The semi-colon insertion is one of the big failures on the "allowed" part. Wish that never happened. But any developer that doesn't try to adhere to some hipster JavaScript coding style uses the semi-colon at the…

From the discussion in one of the replies: Named function expressions demystified http://kangax.github.com/nfe/

"Run". Yes, just ~600 times slower. At that speed it probably won't be very useful. You have ~50 msec for an operation which is perceived as instantaneous. If it takes 30 seconds (600 times as long), people will not use it. It simply isn't feasible. This stuff is only ES3 compatible because it didn't need anything from ES5. A low-level compiler target doesn't need any of these things: http://kangax.github.com/es5-compat-table/

Those are indeed features that are missing from Firefox, yes. Although several are already there in nightly builds (WebAudio, number range, for example). As I said earlier, it is easy to compile such a list from the other direction, stuff Chrome is missing. A few off the top of my head: * A wide range of ES6 features, see http://kangax.github.com/es5-compat-table/es6/ * Proper fullscreen mode (resized) * OPUS codec * Microdata * Scoped style * asm.js * etc. All those are in Firefox. Again, both Firefox and Chrome are ahead of each other in various ways. Deciding which is "overall" more ahead means which features you care about - do you care more about JS language features or HTML forms? WebAudio or Opus? etc. There is no clear winner.

> ES6 is already here, piece by piece it is being added. It's just like HTML5 - there is no future date when suddenly it will show up. Firefox, Chrome, etc. all have parts right now. Not sure what you mean, here's a compatibility table: http://kangax.github.com/es5-compat-table/es6/ Doesn't seem to be "already here" by any reasonable definition of here. Looks like no one but Mozilla is adding stuff that aggressively. Knowing the companies, I'd say it's very doubtful that Apple or Microsoft implement much until ES6 is finalized.

Same thing here :( The compatibility table is here: http://kangax.github.com/es5-compat-table/es6/ Result: IE10 supports exactly zero of these features. We can start using them (maybe) once IE10 is dead.

That chart is misleading. V8 supports (and has supported it for a long time) the vast majority of ES5. Since version 13 it's supported every ES5 features with the exception of Zero-width chars in identifiers, and I don't know when, but it was implemented somewhere between 16 and 23. http://kangax.github.com/es5-compat-table/

And according to [0], Chrome apparently has some (most?) of these features locked behind a big flag (seems to be "Enable Experimental JavaScript" in about:flags, no idea what's implemented though) edit: http://kangax.github.com/es5-compat-table/es6/ considering the sea of red, it's rather clear that both Firefox and Chrome only implement some ES6 features (note: this crashes Chrome 22 after enabling "experimental javascript", which may explain the big flag, and the latest Firefox 16 improves quite a bit on the listed Firefox 13: adds const, default params, rest params, proxies and all the new Number functions) [0] https://news.ycombinator.com/item?id=4633069

in the html of http://16s.us/sha1_pass/js/ add <!doctype html> to the top. this will prevent "quirks mode" in IE and String.prototype.trim will reappear. if you want to support IE 8 and lower you'll have to add a shim for String.prototype.trim. (see http://kangax.github.com/es5-compat-table/ )

I'm currently using FabricJS (demo page: http://kangax.github.com/fabric.js/kitchensink/), so far, works fine on desktop and iPad, didn't do much testing on android though.

Object.create does not even work in most browsers! So you cannot even use the preferred solution in todays most popular browsers: http://www.w3counter.com/globalstats.php?year=2011&month=12 http://kangax.github.com/es5-compat-table/ and you really dont expect anyone to write clunky property descriptors like this?? https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/O…

Unfortunately it wasn't there from day one. It was only specified a year or two ago (thus IE 8 and Opera 11.50 didn't have it, and apparently Safari 5.1 still doesn't) so you have to be prepared to check for it and roll your own. http://kangax.github.com/es5-compat-table/

Indeed, however you have to be careful about the outer scope that the assignment is happening in (because of IE): http://kangax.github.com/nfe/#jscript-bugs The other option, if you are on Webkit, is to assign something to the `displayName` property of a function or method. This is explained really well here: http://www.alertdebugging.com/2009/04/29/building-a-better-javascript-…

I realized after making this comment that some people, swannodette included, were not aware of ES5, which my pointing to Harmony overlooked. ES5 support is almost there in the latest browsers: http://kangax.github.com/es5-compat-table/ It does not fill some of the big gaps left in JS (no module system, that's coming in Harmony), but it helps and it got the standards committee back together (sans Adobe).

FF3 does not attempt to support the ES5 standard, FF4 does* - maybe you can try that one. * http://kangax.github.com/es5-compat-table/

I don't believe so. It sounds like he prefers using function declations to function expressions. And this is incorrect according to most js gurus. For example: http://javascriptweblog.wordpress.com/2010/07/06/function-declarations… From that link: "b) Function Expressions are more versatile. A Function Declaration can only exist as a “statement” in isolation. All it can do is create an object variable parented by its current scope. In contrast a Function Expression (by definition) is part of a larger construct. If you want to create an anonymous function or assign a function to a prototype or as a property of some other object you need a Function Expression. Whenever you create a new function using a high order application such as curry or compose you are using a Function Expression. Function Expressions and Functional Programming are inseparable." Also this link: http://kangax.github.com/nfe/ brings up these disadvantages to function declarations: * can't conditionally declare functions with consistent results across browsers * function declarations cannot appear in blocks (technically), though many implementations allow this in practice finally, i'd argue that function expressions encourage you to think of functions as the first class objects js intended them to be

Named functions are generally fine to use (they're hoisted, but otherwise behave the same), but named function expressions (where you both give the function name, and use it as an expression) has some nasty memory leak issues on IE [1]. Some people think its better to ditch named functions completely rather than learn exactly when its problematic and when it's not... which I'm not sure I completely agree with, but its probably a good advice to give to a new JavaScript programmer, as it basically behaves the same minus those issues. CoffeeScript ended up removing named functions [2] [3] (with the exception of being used for "class" declarations, where its known they're safe) for that reason. [1] http://kangax.github.com/nfe/#jscript-memory-management [2] https://github.com/jashkenas/coffee-script/issues/366#issuecomment-242… [3] https://github.com/jashkenas/coffee-script/wiki/FAQ - "Q: Is there any way to name functions, for reflection and recursion?" edit: formatting