ES6 Cheatsheet(github.com) |
ES6 Cheatsheet(github.com) |
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 binding, so while the syntax of => is concise, it is rarely used as a Function.bind replacement). Pretty much went through the same experience with template strings. Generator functions are great.
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, and I fear the quagmire of excessive inheritance and class extension that will follow with their code.
I've been hoping that this guy's Function.bind optimizations land before 6.0: http://benediktmeurer.de/2015/12/25/a-new-approach-to-functi...
But you prompted me to check on the status of his work, and was happy to find a new post: http://benediktmeurer.de/2016/01/14/optimizing-bound-functio...
It looks like V8 will finally be able to inline bound functions (https://codereview.chromium.org/1581343002)! That's huge!
- 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!
I do trust that it works, and if I were working on a big project that would be hard to refactor for a major language change, or if I were working on the front-end where the available features are up to question based on client, I would definitely use babel. We have a lot of older code like that where I wish we had used babel years back.
In my case our backend is distributed across dozens of small (usually <400 line) packages so if a really nice ES2015 or 2016 feature becomes available the effort to refactor or rewrite will be measured in hours or days, not weeks or months.
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 might not matter for incidental uses of, say, template strings, it might become noticeable for an entire project. Or is that a clear case of premature optimization?
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.
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.
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 PRACTITIONERS were doing this, but the majority of INSTRUCTORS were, causing a lasting problem until enough people willing/able to teach were grown within the community.
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...
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();
I always imagine cheatsheets to be just that; something I can render on one sheet of paper. Printing the entire raw README text would take 4 pages (2 sheets, front and back).
I think it would be better titled, "ES6 best practices" since I think that's a more accurate description of what it is.
One minor quibble. I was bothered by the misuse of the words "lexical" and "interpolate". The lexical value of the keyword "this " is the string "this". Then, you might translate between two technologies such as CommonJS and ES6 but interpolating between them implies filling in missing data by averaging known values. Granted this word is commonly abused. Sorry this is a bit pedantic but these corrections would improve the document, IMO.
This sentence should probably say "interoperate"
Part of me feels that obscuring Javascript's roots in this respect is very un-Javascript-y. What think ye?
Coming from Ruby, loving template literals, feel right at home with them, I wish even C could have them (if that makes any sense!).
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.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
And would it be wise to hold off adopting until all browsers support it?
You don't need to hold off on using it but you should definitely use a compiler like Babel[1] to compile your ES6 code to ES3 for compatibility.
You're probably better off just switching to ES6, but that's just my opinion.
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.com/forum/#!topic/commonjs/Gr72Bc8Twzc
I may have written the first implementation... https://github.com/tlrobinson/narwhal/commit/f960f7902fb9099... (RIP Narwhal!)
>"...the syntax for creating classes in ES6 obscures how implementation and prototypes work under the hood..."
Yes, it's great for if you're uncomfortable with prototypal inheritance and the "javascript way of doing things" (I'll maybe summarize that as composition over inheritance, mixins, knowing how to use call/apply etc.), but at the end of the day I'm worried it might be a crutch. Specifically, it might create the situation where a javascript noob might use es6 classes and never bother to learn how the prototypal chain works or all the myriad options available for mocking classes and OO behavior. That being said, maybe that's a shitty argument. When you have more tools in the toolbox there's always the option for someone picking the wrong tool. Does that mean you take the tool out? Or leave it because it is really useful when you know when to use it correctly. I imagine the latter.
Personally, I love ES6 for fixing many JS pain points (yes, hacky class-like object constructors are among them). If it is against it's history - so be it!
I don't think it's reasonable to eliminate inheritance (it's very useful when it's needed) but restricting it down from what Javascript currently provides natively is a good thing.
If I could avoid writing javascript I would, but unfortunately, you have to write javascript to do anything inside a browser. I can't wait until class {} gets widespread browser support. I know compile-to-javascript languages are a thing, and I use them, but in my experience, you can't get away with not knowing javascript.
I was complaining about some JS stuff (particularly the required writing of "use strict") in the #nodejs freenode irc chat the other day and someone asked me a way to help solve these issues without breaking 50 year old code. Thinking about it, I think a good attempt would be to create an HTML meta tag that would tell the browser to parse all JS in strict mode. Maybe there's something already out there. This is already possible in nodejs, but browser side I think it could be a big help in moving things forward.
JavaScript could get to the same place just be letting you specify a different language in the script tag.
The big question is how we support legacy browsers for a time because many won't support the new keywords.
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.)
I really don't think require-ing within individual functions is a common or good practice. Can you point me to an open source project that does that?
Splitting up a program, or module, into (more) modules does not make it simpler, rather contrary, it makes it more complex! Unless it's a fully decoupled abstraction reusable in other projects.
An example of require-ing within individual functions: A function to send notifications to e-mail or SMS ... It makes more sense to require the SMTP or SMS module in those functions, then somewhere else.