Is there a similar thing for coffescript?
ES6 Cheatsheet
41–50 of 89 posts
Re: ES6 Cheatsheet
#42Wow, 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!
It's not that I don't know how to set it up or use it, I just trust a future V8 implementation enough to wait for it over using a shim. I've also become a bit allergic to dependencies :P.
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.
Re: ES6 Cheatsheet
#43Great 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 pedant…
> By sticking to this paradigm, we make our code easily readable and allow ourselves to interpolate between CommonJS and ES6 modules.
This sentence should probably say "interoperate"
Re: ES6 Cheatsheet
#44Earlier quoted context omitted.
Template strings, arrow functions and object shorthand ({ foo: foo } === { foo }) are very nice.
To be clear, that statement doesn't actually evaluate to true, but those two object literals are equivalent (not referentially equal)
Why did someone downvote this? It's correct: https://babeljs.io/repl/#?experimental=true&evaluate=true&lo...
Re: ES6 Cheatsheet
#45Earlier quoted context omitted.
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 an…
Down-voters should be required to respond if they're going to down-vote. Too often is conversation halted by negative people on HN.
Re: ES6 Cheatsheet
#46"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) methods).
Re: ES6 Cheatsheet
#47"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.com/forum/#!topic/commonjs/Gr72Bc8Twzc
I may have written the first implementation... https://github.com/tlrobinson/narwhal/commit/f960f7902fb9099... (RIP Narwhal!)
Re: ES6 Cheatsheet
#48This will likely get downvoted - but I have just realized how much I was underestimating the privilege of developing apps in Dart instead of JavaScript. Dart had none of the mentioned idiosyncrasies from day one, all the features, and has a lot of other stuff (like async/await, yield, mixins, etc) to offer. Its tooling is very simple and powerful, and the overall experience is really nice - when there is a problem, it's always in the logic of my code, and not things like some weird implicit conversions that are so common in JS land. I almost forgot how terrible JS is...
Re: ES6 Cheatsheet
#49Earlier quoted context omitted.
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 an…
Isn't that basically what we did with doctypes? HTML has a lot of similar issues and it has slowly managed to move forward. The real benefit was not having to mix old and new code and getting rid of all the quirks by requiring you specify that you want them if you want that old doc to work.
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.
Re: ES6 Cheatsheet
#50Earlier quoted context omitted.
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 an…
Isn't that basically what we did with doctypes? HTML has a lot of similar issues and it has slowly managed to move forward. The real benefit was not having to mix old and new code and getting rid of all the quirks by requiring you specify that you want them if you want that old doc to work. JavaScript could get to the same place just be letting you specify a different language in the script tag. The big question is h…
A script type could work too. Either way, there would be some indicator of how the JS VM could parse the code. It's true you could get other languages into HTML this way as well, but the trick is that the browser needs to support the VM, which can be done natively or through a browser plugin/extension. Google tried this for a Dart VM (sidenote: there is no TypeScript VM from Microsoft that I'm aware of) into Chrome but discussions led away from that idea, and now Dart compiles to JS instead. A tag in would eliminate , , etc. Though providing an either/or situation would be optimal too to allow a mixed script types for older libraries.