Live data from Hacker News

ES6 Cheatsheet

github.com

31–40 of 89 posts

Re: ES6 Cheatsheet

#31

The only thing from this list of new ES6 idioms that doesn't sit comfortably with me is the short-hand for creating classes. I remember being kind of blown away way back in the day with the prototypical/functional nature of Javascript and how you could wrangle something into being that behaved in an object-oriented manner just like other languages that had explicit class declaration and object instantiation. Part of…

I think it's un-Javascript-y as well, and I consider that a good thing. I don't think javascript is a particularly well designed language. (I mean, it's great considering its origins, but still)

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.

Re: ES6 Cheatsheet

#32
post #22

Wow, 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!

Re: ES6 Cheatsheet

#33
post #22

Wow, 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…

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

Re: ES6 Cheatsheet

#34
post #20
post #18

Earlier quoted context omitted.

Having used ES7 async/await through Babel extensively for some highly asynchronous code, I can say that it feels much better than using Promises alone, even better than using ES6 generators + a runner (especially since async/await meshes so well with ES6 classes).

The only fear I have is that the spec might still change, which is not the case for ES6 features. Do you think my fears are unfounded? Because I'd love to use ES7 for my back-end projects where all database interaction, and by extension a large part of my codebase, relies on promises...

[deleted]

Re: ES6 Cheatsheet

#35
post #22

Wow, 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…

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

Re: ES6 Cheatsheet

#36
post #5
post #2

[deleted]

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.

Re: ES6 Cheatsheet

#37

Earlier 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…

Agreed. I think JS is quite a broken language that should probably be replaced. It won't be, but it probably should. I know Google thinks Dart could be that language but they're not even trying to put the VM into Chrome, so it's just another replacement that needs to be compiled.

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.

Re: ES6 Cheatsheet

#39
Great reference and overview of ES6.

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.

Post reply on HN