Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ES6 Cheatsheet

github.com

Post reply on HN
Print view View original

81–89 of 89 posts

Re: ES6 Cheatsheet

#81

Post by tlrobinson »

z3t4 wrote: post #79
tlrobinson wrote: post #47

Earlier quoted context omitted.

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.

Are you saying you can't do function-scoped imports ("require" inside a function)? I rarely see that used and it's not available in any other language I can think of.

Re: ES6 Cheatsheet

#82

Post by z3t4 »

tlrobinson wrote: post #81
z3t4 wrote: post #79

Earlier quoted context omitted.

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.

Are you saying you can't do function-scoped imports ("require" inside a function)? I rarely see that used and it's not available in any other language I can think of.

Yes. It makes things so much simpler. Your program do not have to be complex! It can exist entirely of functions that do not depend on their outer scope. You can basically change everything around them and the function will still work the same. And you do not have to look outside the function to understand what it does. You only have to know about the standard objects witch in JavaScript (ES5) is Math, Date, JSON and Error. Everything else is "required" when needed.

Re: ES6 Cheatsheet

#83

Post by tlrobinson »

z3t4 wrote: post #82
tlrobinson wrote: post #81

Earlier quoted context omitted.

Are you saying you can't do function-scoped imports ("require" inside a function)? I rarely see that used and it's not available in any other language I can think of.

Yes. It makes things so much simpler. Your program do not have to be complex! It can exist entirely of functions that do not depend on their outer scope. You can basically change everything around them and the function will still work the same. And you do not have to look outside the function to understand what it does. You only have to know about the standard objects witch in JavaScript (ES5) is Math, Date, JSON and…

That's still true but on the module level. If your module is so large that it's hard to keep track of the imports/requires then you should probably split the module up.

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?

Re: ES6 Cheatsheet

#84

Post by mercer »

mstade wrote: post #74
mercer wrote: post #66

Earlier quoted context omitted.

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

That's informative, thanks. At least I have something to look into, and a quick search indicates that source maps are not even necessary in this approach!

Re: ES6 Cheatsheet

#85

Post by mercer »

pcwalton wrote: post #78
mercer wrote: post #65

Earlier quoted context omitted.

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(); Works despite the temporal dead zone and depends on hoisting. This exact example is why hoisting was kept for let.

Interesting. This kind of stuff makes me want to dive into the details of these kinds of choices, as I regularly wonder why languages designed are a certain way.

Re: ES6 Cheatsheet

#86

Post by mstade »

pcwalton wrote: post #77
mstade wrote: post #76

Earlier quoted context omitted.

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.

Oh? Would love to be enlightened!

Re: ES6 Cheatsheet

#87

Post by z3t4 »

tlrobinson wrote: post #83
z3t4 wrote: post #82

Earlier quoted context omitted.

Yes. It makes things so much simpler. Your program do not have to be complex! It can exist entirely of functions that do not depend on their outer scope. You can basically change everything around them and the function will still work the same. And you do not have to look outside the function to understand what it does. You only have to know about the standard objects witch in JavaScript (ES5) is Math, Date, JSON and…

That's still true but on the module level. If your module is so large that it's hard to keep track of the imports/requires then you should probably split the module up. 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?

A module is already scoped in node.js. It would be nice to have scoped require in the browser too, instead of just global import.

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.

Re: ES6 Cheatsheet

#88

Post by tlrobinson »

z3t4 wrote: post #87
tlrobinson wrote: post #83

Earlier quoted context omitted.

That's still true but on the module level. If your module is so large that it's hard to keep track of the imports/requires then you should probably split the module up. 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?

A module is already scoped in node.js. It would be nice to have scoped require in the browser too, instead of just global import. 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-mai…

ES6 modules do get their own scope in the browser. That's kind of the point of them.

Re: ES6 Cheatsheet

#89

Post by johnny22 »

alexkavon wrote: post #37
ergothus wrote: post #35

Earlier 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 what is for? it does "use strict" automatically
Post reply on HN