Amazing work!

have you tried the Scratchpad tool in Firefox (Shift-F4)? It's made for editing and executing as much JavaScript as you want.

One bonus is that this is fully-remoted with our debugger protocol. In time, we hope to get the asset inspection parts included in our tool as well.

We'll also be showing Nick Desaulnier's port of the WebGL Inspector for Firefox in our booth at GDC!

Little known feature: There's also a "cookie" command in the GCLI. Shift-F2 to bring up the command line, type "help cookie".

you can still use it on Nightly.

http://nightly.mozilla.org/

ESC key to close that sidebar in the console.

Works - thanks for the tip. A simple [x] icon (perhaps with a "click ESC to close" tooltip) will also be nice, as there's currently no visual indication on how to close it.

see https://news.ycombinator.com/item?id=6671062

I was aware it's pretty modern but honestly didn't think about it much. We use it heavily in Firefox Devtools code and I much prefer its non-hoisting properties over var.

Out of curiosity, what do you mean by non-hoisting properties? According to the MDN docs let variables are hoisted, at least to the enclosing block.

I usually think of "hoisting" as promoting a var outside of its containing scope to within the next block.

e.g.,

function() { var a = 2; // b is visible here if (a == 2) { var b = 3; } }

Hoisting still occurs within a scope such that, for example, a function defined at the end of a block can be called at the top.

right. The point I was trying to illustrate was that the inner variable declared with a "var" keyword was visible outside its containing block. If I'd used "let" there, it would not be.

SyntaxError: syntax error.

you can't use spread arguments without the ().

Not sure I agree with you. After using them for a few months, they feel pretty natural, light-weight and used close to where you define them. There's actually less thinking required when using a fat-arrow function because you don't really have to worry about the scope.

I have to agree.

I code in C#. I often grouse about certain cases where we use characters instead of words - particularly in boolean logic (I find SQL code with AND and OR and NOT far more readable than C-ish characters)... and especially since the => operator is a perversion of comparison... I mean, it feels like a backwards less-than-or-equal.

But after diving headlong into C#'s various lambda and LINQ features, it's become quite natural, at least for cases where you're creating a function in-line as an argument to another call.

If I were coding more Javascript? I'd probably deprecate the function() syntax with its "this" re-binding misfeature altogether.