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

Overview of JavaScript ES6 features

adrianmejia.com

Post reply on HN
Print view View original

141–150 of 250 posts

Re: Overview of JavaScript ES6 features

#141

Post by z3t4 »

oldmanjay wrote: post #105
mort96 wrote: post #61

Earlier quoted context omitted.

This. I personally agree with everyone saying const > let, but I just don't find myself caring enough about it to add the inconvenience of typing 5 characters instead of 3 every time I need to create a variable.

You'd think after all these decades I'd no longer be surprised that programmers try so hard to minimize their typing, since it has no demonstrable positive impact on code quality. I guess premature optimization is in the blood of some people.

The right path have to add more value then the path of least residence.

Re: Overview of JavaScript ES6 features

#142

Post by nothrabannosir »

abritinthebay wrote: post #91
cloakandswagger wrote: post #86

Earlier quoted context omitted.

Is it just me, or is Javascript (and more generally, all front end technology) more susceptible to these trivial holy wars? While I agree that const/let is a useful convention for communicating mutability, it isn't nearly a big enough deal to warrant the attention it receives from the community. It's not just const/let; I rarely make a front end PR that isn't bike-shedded to death over subjective styling choices, sin…

> Is it just me, or is Javascript (and more generally, all front end technology) more susceptible to these trivial holy wars? - Tabs vs spaces. - Vi vs Emacs - Weak vs strong typing - where to place {} in block statements - where to put commas No, programming in general is susceptible to these trivial holy wars.

Weak vs strong typing is hardly "trivial"... it's the very foundation of a language.

Not trying to derail the convo or take sides, but one of these is not like the others ;)

Re: Overview of JavaScript ES6 features

#143

Post by z3t4 »

Meegul wrote: post #130
SHOwnsYou wrote: post #120

Earlier quoted context omitted.

Honest question here --- What is the difference between let and global variables? There are hundreds of articles written about the doom associated with PHP globals, but let appears to be universally lauded. I must be missing something, but I can't tell where.

It's spelled out pretty well in the article. But if you want another example, consider these two code blocks: var foo; var bar; { let foo = "hello"; var bar = "world"; } console.log(foo); console.log(bar); This produces: undefined world The reason being that the `let` statement restricted that variable to the block it was in (defined by the { and }). `var` declares the variable globally, allowing it to be accessed ou…

> With the asynchronous nature of Javascript, it's theoretically possible for you to declare a variable with `var`, assign it a value, then immediately use that value and find that it's different than what you expected

Can you give an example ? My understanding is that the closure freeze the variable in the time the function was called. It can happen if you do not use a closure (function) though.

Re: Overview of JavaScript ES6 features

#144

Post by Meegul »

SHOwnsYou wrote: post #138
Meegul wrote: post #130

Earlier quoted context omitted.

It's spelled out pretty well in the article. But if you want another example, consider these two code blocks: var foo; var bar; { let foo = "hello"; var bar = "world"; } console.log(foo); console.log(bar); This produces: undefined world The reason being that the `let` statement restricted that variable to the block it was in (defined by the { and }). `var` declares the variable globally, allowing it to be accessed ou…

From the article-- let x = 'outer'; function test(inner) { if (inner) { let x = 'inner'; return x; } return x; // gets result from line 1 as expected } test(false); // outer test(true); // inner This makes it seem like let creates global variables. Why would you want to return a variable from outside the function? Doesn't that create massive overhead in terms of keeping track where variables are initially set? Easy t…

If you were to then reference 'x' from another block of code, say in another element in the case of web development, 'x' would not be a defined variable, whereas with 'var', it would be.

This is mostly just a case of 'let' restricting a variable to the block it is in, and the child blocks. In your example, `let x = 'outer';` is sort of acting like a global variable, but the importance is that if another script were to be running, it could not access that instance of 'x'.

Re: Overview of JavaScript ES6 features

#145

Post by fryan »

z3t4 wrote: post #139
betenoire wrote: post #92

Earlier quoted context omitted.

const vs let is an "immutable by default" vs "mutable by default" type of difference. it's not just a style difference, it can help you write stateless code if you assume immutability. but yeah.

Native objects in JavaScript are already immutable as in you can not change them, only create new objects. Const will not make your object immutable! Try this: const foo = {bar: 1} foo.bar = 2; It will only avoid having the pointer re-pointed to another object. It's better to just try avoiding global variables, and use a naming convention like uppercase and/or underscore for constants and global variables. Const is p…

    const foo = {bar: 1}
The only thing const about it is the reference `foo` cannot be reassigned:

    foo = something_else; // error
Unlike `const` in C++, `const` in javascript in not very useful in my opinion. `let` is shorter and more readable.

Re: Overview of JavaScript ES6 features

#146

Post by mnarayan01 »

cloakandswagger wrote: post #86
ggregoire wrote: post #39

I'm surprised by the state of const/let nowadays. The well-known good practice: use const by default; use let when it's needed. At the release of ES6, it was the way to go. But everyday I notice libraries—and some really famous— that use let everywhere in their docs, or some really influent developers from Google or Facebook who share samples of code on Twitter using let when it's not needed [1]. I don't know why. Se…

Is it just me, or is Javascript (and more generally, all front end technology) more susceptible to these trivial holy wars? While I agree that const/let is a useful convention for communicating mutability, it isn't nearly a big enough deal to warrant the attention it receives from the community. It's not just const/let; I rarely make a front end PR that isn't bike-shedded to death over subjective styling choices, sin…

Presumably each project/organization/etc. has its own style guidelines (or at least unwritten conventions). If you're not following them, then it's not a surprise people are calling you on it. If, on the other hand, they don't exist then it would be weirder.

Re: Overview of JavaScript ES6 features

#147

Post by BinaryIdiot »

RussianCow wrote: post #122
BinaryIdiot wrote: post #99

Earlier quoted context omitted.

We don't need any libraries to solve this issue (please don't bring in libraries to do weird stuff like this; that's a dependency that you'll be stuck with forever over your entire codebase for essentially zero reason IMO). Just use `const` + `Object.freeze()`; it'll get you 99.9995% of exactly what you want.

I'll give you two reasons: performance and ease of use. When you need a copy of a large object with a small change, performing the copy with native JS is going to be slower than doing it with a specialized data structure like a hash mapped trie[0] (which is what Immutable.js uses). Also, if you're trying to keep your data truly immutable, that copy operation is going to be a pain to write with the built-in tools, whe…

> When you need a copy of a large object with a small change, performing the copy with native JS is going to be slower than doing it with a specialized data structure like a hash mapped trie[0] (which is what Immutable.js uses)

Fair enough though I'm not convinced you should be hitting this type of use case in your code (kinda inefficient and sounds awkward to make a small change to a large object and yet need both objects to continue to be in memory, separated). At least not typically / frequently.

> if you're trying to keep your data truly immutable, that copy operation is going to be a pain to write with the built-in tools, whereas it's super easy to return a copy of an object with a change to a single, deeply nested property with Immutable.js.

While it is a little bit of a pain almost every framework and probably half of the libraries in existence on npm have a copy function. I'd like to think it's a rare use case but when it's needed you likely don't have to install a new library to handle a copy operation.

> I agree that it's premature to reach for a library before you need it, but let's not pretend there aren't rather large drawbacks to using Object.freeze and Object.assign.

I'm not sure anyone was pretending anything of the sort here and I don't understand the assumption of such. There are plenty of drawbacks but I'm also not convinced it doesn't fit the 95% use case.

Re: Overview of JavaScript ES6 features

#148

Post by vcarl »

treve wrote: post #33
Tankenstein wrote: post #12

Earlier quoted context omitted.

For anyone who wants to use ES6 in production, https://babeljs.io/ is amazing.

It's both amazing, and 600MB worth of dependencies. We use it for server-side code. It's high quality, and we only have a few issues with it, but I can't wait to be able to ditch is (pretty much when async/await lands in a stable node).

Doing

    du -ch ./babel*
from my `node_modules` directory yields

    3.2M	total
so I'm gonna need a citation on that 600MB claim.

Re: Overview of JavaScript ES6 features

#149

Post by z3t4 »

VeejayRampay wrote: post #77
duckfruit wrote: post #58

Earlier quoted context omitted.

for...of is more flexible. While forEach is a method on Array.prototype, for...of is a consistent syntax that can be used in more places. For instance, iterables: function *myIterable (v) { while(--v) yield v } let launchCountdown = myIterable(60) for (let i of launchCountdown) console.log(`t minus ${i} seconds`) So in effect arrays can be thought of as iterables in ES6. So IMHO it allows for more consistent behavior…

Ah, I see, good point. And how would you handle cases (that I end up using quite often) such as : arr.map(...).filter(...).forEach(...) which allows me to iterate over the filtered result? One would assign the result of filter to a variable and call for...of on that? EDIT: Also, I never saw any mention of for...of working for object literals (à la `for (let [key, value] of obj`), I suppose that's out of scope, correc…

It's also useful if you want to call break or continue.

Re: Overview of JavaScript ES6 features

#150

Post by Hurtak »

ggregoire wrote: post #39

I'm surprised by the state of const/let nowadays. The well-known good practice: use const by default; use let when it's needed. At the release of ES6, it was the way to go. But everyday I notice libraries—and some really famous— that use let everywhere in their docs, or some really influent developers from Google or Facebook who share samples of code on Twitter using let when it's not needed [1]. I don't know why. Se…

I heard interesting argument against const, it went like this:

Const very rarely saves you from bugs and the bugs that saves you from are very easy to find and fix. On the other hand the time wasted by thinking where whether to write const or let and the time wasted by switching consts for lets (and other way around) outweighs the time saved by potentially preventing these easy to find bugs. To sum it up, if consts does not really provide any extra value, why not make your life easier and just use let everywhere.

It was from very senior c++ programmer, so I am not sure how well that translates to JavaScript.

Post reply on HN