Didn't realize arrow functions preserver this! Now using arrow functions.
ES6 Cheatsheet
71–80 of 89 posts
Re: ES6 Cheatsheet
#72Earlier quoted context omitted.
TypeScript is very nice. The one main problem it has is lack of type definitions for third-party modules, some developers find having to "waste time" writing those defs themselves to be quite bothersome.
Typescript gives you an "out" to type checking using the any type. Additionally, most libraries really worth using have .d.ts files floating around the internet somewhere, in DefinitelyTyped or otherwise.
That's all true. It's a chicken-and-egg problem there, though. I've seen several arguments that the language is not worth looking into until more typings become available, and of course those naysayers are not going to write the missing typings.
Re: ES6 Cheatsheet
#73Wow, var was so broken. Anyway, we use as much ES6 as Node 4 allows at work. Transpiling on the server never made much sense to me. I also used to sprinkle the fat-arrow syntax everywhere just because it looked nicer than anonymous functions, until I realized it prevented V8 from doing optimization, so I went back to function until that's sorted out (I don't like writing code that refers to `this` and never require b…
Transpiling on the fly on the server is even more painless than for the frontend: - Require babel-core/register (as of Babel 6) - Require your server entry point ES6 file. - Done. Everything just seems to work, no need for sourcemaps or anything; line numbers, error reporting, non-ES6 modules, everything Just Works. Haven't had a single issue since starting to do this 4 months ago (knock on wood). Highly recommended!
Additionally, if you're using tape[1] for testing, I implemented a useful feature not too long ago to allow the preloading of modules[2] so you can run something like babel-register before your tests are run, effectively plugging in JIT-like support for your tests. (End shameless plug.)
Re: ES6 Cheatsheet
#74Earlier quoted context omitted.
Transpiling on the fly on the server is even more painless than for the frontend: - Require babel-core/register (as of Babel 6) - Require your server entry point ES6 file. - Done. Everything just seems to work, no need for sourcemaps or anything; line numbers, error reporting, non-ES6 modules, everything Just Works. Haven't had a single issue since starting to do this 4 months ago (knock on wood). Highly recommended!
The babel documentation says it's a bad idea to do this in production, so I'm thinking of using webpack to transpile then entire back-end to one ES5 file. Do you know enough about this situation to tell me if this is a bad idea or not? Because obviously your approach would be 'simpler'. Edit: An additional reason to transpile to ES5 is that on the whole much of the ES6 support is not very performant yet. While this m…
There's no difference in compiling to ES5 versus hooking into the module loading mechanism to compile on the fly, in terms of the end-result. The only practical difference is that precompiling means your modules will load faster the first time, but there will be no difference for subsequent loads since modules are cached. I'm guessing the caveat for running something like babel-register in production is the first-load performance penalty, as well as having less control over the compilation process. However, if you are ok with configuring babel through .babelrc files alone, and you're ok with the first-load performance penalty, I don't see what it'd be any worse than precompiling to ES5. (There may be subtle differences in debugging due to the lack of source maps, but I don't know enough to comment on that with any degree of certainty.)
Re: ES6 Cheatsheet
#75Earlier quoted context omitted.
> I'm not a fan of the class keyword either, but to each their own. I think it obscures understanding of modules and prototypes just so that ex-Class-based OOP programmers can feel comfortable in JS I couldn't agree more. Classes were implemented so that JS haters could write syntax they wanted to and not to improve the language per say. Seems like JS is entering an age of cruft.
While I am also not a fan of the class keyword, I'd argue that we already had that age of cruft. For quite a few years (past decade?) practically every book on JS would start with the author building their own version of inheritance, and then relying on it throughout the rest of the book. It's only in the last few years that the majority have stopped trying to recreate Java in JS. (I don't think the majority of PRACT…
> While I am also not a fan of the class keyword, I'd argue that we already had that age of cruft. For quite a few years (past decade?) practically every book on JS would start with the author building their own version of inheritance, and then relying on it throughout the rest of the book.
This, right here. The class keyword is unfortunate, but at least it ends the useless meta discussion of "how to implement classes" by simply providing some sugar over the RightWayToDoIt(tm). (According to those in the know – whatever, I don't care for classes.)
Re: ES6 Cheatsheet
#76Is "WeakMap" really the suggested way to implement private class properties? Using "this" as a key into a Map of private variables looks bizarre. I would rather keep my code concise than create a layer of obfuscation.
It was really hard to make truly private properties that couldn't be leaked in some way without WeakMap. If you don't need foolproof leakage, Symbols are a more convenient way to get most of the benefits of private properties. This is intentional: as I recall, the committee realized that WeakMap wasn't the most ergonomic solution and created Symbols as a more convenient, though less ironclad, alternative.
Additionally, symbols would have provided a neat way to implement private (and privately shared) properties, if they hadn't decided on adding the `getOwnPropertySymbols` function[1]. Bummer.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: ES6 Cheatsheet
#77Earlier quoted context omitted.
It was really hard to make truly private properties that couldn't be leaked in some way without WeakMap. If you don't need foolproof leakage, Symbols are a more convenient way to get most of the benefits of private properties. This is intentional: as I recall, the committee realized that WeakMap wasn't the most ergonomic solution and created Symbols as a more convenient, though less ironclad, alternative.
Additionally, symbols would have provided a neat way to implement private (and privately shared) properties, if they hadn't decided on adding the `getOwnPropertySymbols` function[1]. Bummer. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
There were other ways to leak symbols before that method was added. They were never foolproof.
Re: ES6 Cheatsheet
#78> Unlike var, let and const statements are not hoisted to the top of their enclosing scope. No, let is hoisted to the top of the enclosing scope [1] ("temporal dead zone" notwithstanding). let, however, is not hoisted to the top of the enclosing function . [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I'd say that makes you technically correct, but practically speaking, if using let before it's declared (assigned?), this temporal dead zone, results in an error, it's pretty much not hoisted in the way that most of us think of it. Or is there a use case that I'm not aware of where the hoisting is beneficial despite the temporal dead zone?
let f = function() { ... g(); ... }
let g = function() { ... f(); ... }
f();
Re: ES6 Cheatsheet
#79"Require" is the reason why we now have a module for just about anything in Node.JS. I even think Kevin Dangoor or whoever invented it should get the Nobel prize. But then the ES committee choose to use paradigms from year 1970. I cry every time someone use import instead of require in JS because they miss out why globals are bad, modularity is good, and the JS API philosophy (super simple objects with (prototype) me…
I'm not sure I understand. ES6 modules are basically equivalent to "require". `import foo from "foo";` is the same as `var foo = require("foo");` Yes, it was Kevin Dangoor who started the CommonJS (originally "ServerJS") project and led many of the discussions. Kris Kowal and many others were instrumental as well. This is probably the pivotal mailing list thread for what became CommonJS modules: https://groups.google…
The main technical difference is that you can not have scoped imports.
The main impact though, is that many will use a hammer on screws, meaning; people used to "other tools", can now do so (ES6: import, class, etc). While require teaches you to use the electrical screwdriver.
Re: ES6 Cheatsheet
#80Wow, var was so broken. Anyway, we use as much ES6 as Node 4 allows at work. Transpiling on the server never made much sense to me. I also used to sprinkle the fat-arrow syntax everywhere just because it looked nicer than anonymous functions, until I realized it prevented V8 from doing optimization, so I went back to function until that's sorted out (I don't like writing code that refers to `this` and never require b…
Transpiling on the fly on the server is even more painless than for the frontend: - Require babel-core/register (as of Babel 6) - Require your server entry point ES6 file. - Done. Everything just seems to work, no need for sourcemaps or anything; line numbers, error reporting, non-ES6 modules, everything Just Works. Haven't had a single issue since starting to do this 4 months ago (knock on wood). Highly recommended!
babel-register is not recommended for production use.
https://phabricator.babeljs.io/T6940
That being said I've used in production for quite a while, but the memory foot print is a lot higher. I'd recommend compiling to a separate file for production.
I recently put in the pull request to suggest not using register in production just as babel-node is not recommended.