Is there a resource that tells me which of these features are available in the latest stable Node version?
ES6 Cheatsheet
61–70 of 89 posts
Re: ES6 Cheatsheet
#62Earlier quoted context omitted.
Not at work, but I use either ES6 or Typescript personally. "All of the syntactic sugar stuff changes the look and feel of the language too much for my tastes." I think it brings it into line with how the language is being used in production these days. Modules, generators etc make the language more beautiful, powerful and easier to maintain.
>>> Not at work, but I use either ES6 or Typescript personally. Not a JS developer, but most of my friends who are have been transitioning to Typescript. The road is bumpy, but they say once you get some syntax stuff down, you're good.
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.
Re: ES6 Cheatsheet
#63I love how concise this is an handles a lot of "Gotchas" when working with ES6, but can we call a spade a spade and NOT call this a "cheatsheet?"
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.
Re: ES6 Cheatsheet
#64Earlier quoted context omitted.
I'm all in on ES6 when it's practical or allowed. Arrow functions are wonderful, I love destructuring assignment, const and let, and considering that some projects I work on involve a lot of async stuff, I'm close to just giving in and using ES7's async/await functionality. But most of the time this is in the context of Node.js development, and in every case I use Babel.js to turn the end result into ES5 code. I'm pe…
> But most of the time this is in the context of Node.js development, and in every case I use Babel.js to turn the end result into ES5 code. If it's helpful: the current stable node (4.x) already supports ES6 out of the box.
I'm currently doing that for a project, but I'm about to change things up and use Babel anyways, for the following reasons:
- my project contains jsx files, which currently are compiled into .js files which feels a bit messy.
- I'm seriously considering using ES7's async/await functionality, which is not supported by node yet.
- and most importantly: node's ES6 support is incomplete. In particular, I miss default function parameters and destructuring assigment.
Using Babel would solve all these issues, and I could simply remove Babel once support is sufficient.
Re: ES6 Cheatsheet
#65> 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?
Re: ES6 Cheatsheet
#66Wow, 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!
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 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?
Re: ES6 Cheatsheet
#67Two questions: what happens if you use ES6 standards in a browser that does not support it? And would it be wise to hold off adopting until all browsers support it?
You'll get an errror :) (probably a syntax error) 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. [1] https://babeljs.io/
Shouldn't ES5 be god enough at this point (honest question)?
Re: ES6 Cheatsheet
#68Earlier quoted context omitted.
You'll get an errror :) (probably a syntax error) 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. [1] https://babeljs.io/
Shouldn't ES5 be god enough at this point (honest question)?
Yes, in most cases. As always, the pro way to do it is to examine the browser statistics for your target market, decide which browsers you will/won't support, and build and test for those browsers. If you don't want to go to all that effort for your smaller project, the bottom line is that most developers today end up targeting ES5.
Re: ES6 Cheatsheet
#69Earlier quoted context omitted.
>>> Not at work, but I use either ES6 or Typescript personally. Not a JS developer, but most of my friends who are have been transitioning to Typescript. The road is bumpy, but they say once you get some syntax stuff down, you're good.
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.
Re: ES6 Cheatsheet
#70[This](https://ponyfoo.com/articles/es6) is also a very informative guide of ES6. I highly recommend perusing it.