Live data from Hacker News

Overview of JavaScript ES6 features

adrianmejia.com

91–100 of 250 posts

Re: Overview of JavaScript ES6 features

#91

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…

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

Re: Overview of JavaScript ES6 features

#92

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…

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.

Re: Overview of JavaScript ES6 features

#93

Ugh. All this "make Javascript like Java" stuff needs to stop. Cool stuff: Tail call elimination. Arrow functions. Assignment spread for multiple return values and "rest" / default parameters. Proxying (combined with computed get/set on properties) for easy decoration. Classes and let: meh.

Let is a game changer imo. In the world of tens of dependencies, knowing that your variables are scope restricted reduces your cognitive load. It's one less thing that can go wrong.

I agree with you on classes, but that's probably more because I've never been a big fan of OO in practice. It doesn't really seem to have seen much use in the greater js ecosystem though, unlike let/const.

Re: Overview of JavaScript ES6 features

#94
post #71

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…

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;

Re: Overview of JavaScript ES6 features

#95
post #22

Earlier quoted context omitted.

Also - for anyone writing code where performance matters, the question isn't when browsers support the syntax, it's when each JS engine's optimizations support it. E.g.: until some months ago just putting "let foo" into a function would cause V8 to bailout (meaning the whole function gets executed slowly, even if the actual let statement gets removed as dead code). Unfortunately I've never found any good references o…

This is an important distinction, and as far as I know, none of the new features are very optimized. If you really want to write performant JS without a build step, you basically have to write it ES3-5 style, use for loops over maps and foreaches, etc

> none of the new features are very optimized

I think for-of is getting pretty good. It's a bit of a pain to optimize because the iteration protocol in ES6 is designed in such a way that you have to do heroics (scalar replacement) to have any hope of optimizing it well. But engines are getting there.

Re: Overview of JavaScript ES6 features

#96

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…

> Is it just me, or is Javascript (and more generally, all front end technology) more susceptible to these trivial holy wars?

What constitutes holy wars are often the most accessible[1]

[1] https://en.wikipedia.org/wiki/Law_of_triviality

Re: Overview of JavaScript ES6 features

#97

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.

> const vs let is an "immutable by default" vs "mutable by default" type of difference

Sorta. I mean you're right but at the same time if you're using const for an object or array then it doesn't really matter without `object.freeze()` because it's not immutable only the reference is and I don't think most JavaScript developers understand that (at least not most of the ones I've run into).

Re: Overview of JavaScript ES6 features

#98
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!'

This is the same as a const ptr in C: the pointer can't change but the value it points to can. While it may seem broken it has its uses. Doing deep watches to disallow object mutation would be impossibly expensive (I think?).

Not sure if this is valid C syntax, but in C++ you can do something like:

  type const * const
Which is a const pointer to a const type, making both the pointer and the data immutable.

Re: Overview of JavaScript ES6 features

#99
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!'

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.

Re: Overview of JavaScript ES6 features

#100

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…

> 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, but it's in ES2017 drafts and is implemented in Chrome and Firefox but so far not elsewhere. The need to do Object.entries instead of obj.entries() is annoying, but needed in case your literal has a property named "entries"... There's also Object.keys() and Object.values(), of course.
Post reply on HN