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

131–140 of 250 posts

Re: Overview of JavaScript ES6 features

#131

Post by Normal_gaussian »

AgentME wrote: post #94
riquito wrote: post #71

Earlier quoted context omitted.

It doesn't help that many variables are objects, and const means that you cannot reassign the variable, not that you cannot modify it. e.g. const x = {}; x.foo = 'it works!'

`const` means that the variable binding itself is immutable. It only affects the variable binding, not the value it points to. If it affected the value it pointed to, what would happen in this type of situation? let x = {}; const y = x; x.a = 5;

This is trivially testable in most browsers inspection tools.

The answer is it works fine. x.a === y.a === 5

This is because you are simply declaring the binding of y to the object bound to x constant. This does not impact your ability to rebind x or to alter the contents of the object, it simply prevents you from rebinding y.

    let x = {a:5}
    x = {}
    console.log(x.a) // undefined
---

    const y = {a:5}
    y = {} // Uncaught TypeError: Assignment to a constant variable.
---

    let x = {a:2}
    const y = x
    x.b = 12    
    x = {}
    x.b = 13
    console.log(y) // {a: 2, b:12}
    console.log(x) // {b: 13}

Re: Overview of JavaScript ES6 features

#132

Post by dsp1234 »

BinaryIdiot wrote: post #99
ggregoire wrote: post #74

Earlier quoted context omitted.

Maybe in ES9 we will have immut x = {}; x.foo = 'it doesn't work! :)' At the moment, we can use these libs to achieve it - https://github.com/rtfeldman/seamless-immutable - https://github.com/facebook/immutable-js

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.

  const x = Object.freeze({
    y: {
      foo: 'bar'
    }
  });
  x.y.foo = 'baz'
  console.log(x.y.foo) //baz
immutablejs might be overkill, but not having, and using, a recursive freeze is going to bite a lot of people if the advice is just 'const + Object.freeze'.

Re: Overview of JavaScript ES6 features

#133

Post by i__believe »

zelias wrote: post #55

While I'm a big believer in most of the ES6 changes (arrow functions! let/const! classes! generators!), I am not a big fan of many of the new destructuring features. They can actually make your code less approachable if you don't already know what's going on.

Exactly, and this is a big problem where I work. I believe code should be readable, even by those with only cursory knowledge of the language. Object shortcuts is also a problem I think. For example, I had a method like this:

const getObj = (id, store) => { return { id: id name: store.something.name }; };

The linter gave an error on it because I used {id: id}. It was like the linter was trying to make my code harder to read.

I think es6 in the wrong hands quickly falls prey to the problems of ruby/scala where it can become incredibly terse and hard to parse unless you are used to the author's particular style.

Re: Overview of JavaScript ES6 features

#134

Post by [deleted] »

betenoire wrote: post #92
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…

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.

[deleted]

Re: Overview of JavaScript ES6 features

#135

Post by bzbarsky »

pitaj wrote: post #125
bzbarsky wrote: post #100

Earlier quoted context omitted.

> arr.map(...).filter(...).forEach(...) which allows me to iterate over the filtered result? Just like that. It would be pretty nice to have generic filter/map that can work on arbitrary iterables, but we don't have that right now. :( > Also, I never saw any mention of for...of working for object literals (à la `for (let [key, value] of obj`) for (let [key, value] of Object.entries(obj)) { } it's not in "ES6"/ES2015,…

Generics on iterables are super easy: function* map(iterator, mapper) { for (const elem of iterator) { yield mapper(elem); } } function* filter(iterator, filterer) { for (const elem of iterator) { if (filterer(elem)) { yield elem; } } } function forEach(iterator, eacher) { for (const elem of iterator) { eacher(iterator); } } function reduce(iterator, reducer, initial) { let current = initial; for (const elem of itera…

Yes, but you have to have that boilerplate every time you want them instead of them just being around. It's not fatal, but is annoying.

Re: Overview of JavaScript ES6 features

#136

Post by sfink »

fenomas wrote: post #64
acdha wrote: post #30

Earlier quoted context omitted.

This is a real concern, but it definitely carries the usual caveats about premature optimization and needing to measure regularly to confirm that it is a real concern and that the performance landscape hasn't shifted since the last time you measured it. The best suite I've seen is https://kpdecker.github.io/six-speed/ which measures node and the various modern browsers which Sauce Labs supports and appears to be run…

That is a great reference, but in general I don't find myself caring much about the raw performance of individual statements that way. My concern is that this or that new syntax will prevent a function from getting inlined, or prevent the engine from guessing type information it otherwise would have guessed, or whatever - just because those bits of the optimizing compiler are newer and less robust.

I agree that this is a valid concern. And I do not trust the six-speed test to do the right thing here. See for example https://github.com/kpdecker/six-speed/pull/42 where the test claims to be measuring the speed of destructuring, but in Firefox the result is entirely due to the effects of destructuring on the engine's ability to eliminate dead code. While that is relevant to performance, all it means in the end is that if you destructure something and then pointlessly throw away the result, that it will run much slower than using an ES5 assignment to pull out the field and then pointlessly throw it away. It says nothing about actual code that destructures and then uses the result vs ES5 code that pulls out the field and then uses the result. And that PR was closed because it's showing up an optimization gap, and kpdecker wants to force vendors to implement optimizations -- which is fine, except this is an optimization for something that is irrelevant to production code.

This might just be an isolated incident, but it shakes my confidence in the utility of the six-speed suite. I actually do want to know whether there's a speed difference between const { a } = obj vs const a = obj.a, and the suite does not test that. (Worse, it kind of claims that it does, but reports something else instead.)

If 'let' prevented inlining, I would want to know, but I'd have to look very closely at the six-speed benchmarks to figure out whether it's detecting that. And the range of subtle reasons for deoptimization is vast, so despite working on a JS engine myself, I doubt I'd be able to tell whether a given microbenchmark is meaningful or not.

(Note that the Firefox devtools does have a "Show JIT Optimizations" that can tell you why things aren't getting optimized, but it's incredibly cryptic, undocumented, and scaremongering.)

Re: Overview of JavaScript ES6 features

#137

Post by [deleted] »

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…

[deleted]

Re: Overview of JavaScript ES6 features

#138

Post by SHOwnsYou »

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…

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 to understand in this example, but what if let x = 'outer'; is defined at the top of a 5000 line script and this function appears near the bottom?

Edit: Turns out I don't know how to format code. This is in the first example of section 3.1 Block Scope Variables.

Re: Overview of JavaScript ES6 features

#139

Post by z3t4 »

betenoire wrote: post #92
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…

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 probably only meant for constants like the name suggests.

I think something like this is pretty safe from reassigning:

  {
    let foo = 1
    ...
  }
  ...
If you want more control over your properties, you can use the ES5 feature "defineproperty" where you can set writeable: false

Re: Overview of JavaScript ES6 features

#140

Post by BinaryIdiot »

dsp1234 wrote: post #132
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.

const x = Object.freeze({ y: { foo: 'bar' } }); x.y.foo = 'baz' console.log(x.y.foo) //baz immutablejs might be overkill, but not having, and using, a recursive freeze is going to bite a lot of people if the advice is just 'const + Object.freeze'.

> immutablejs might be overkill, but not having, and using, a recursive freeze is going to bite a lot of people if the advice is just 'const + Object.freeze'.

No one should be trying to use a recursive freeze (if they are I would argue their data structure is poorly suited to be immutable).

I'm not saying `const` + `Object.freeze()` gets you Immutablejs I'm saying it gets you, likely, what you want / need.

Post reply on HN