Juriy Zaytsev (kangax)

> "[]+[]" 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…

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-vs-function-expressions/

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-242134

[3] https://github.com/jashkenas/coffee-script/wiki/FAQ - "Q: Is there any way to name functions, for reflection and recursion?"

edit: formatting

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.

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

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.