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

61–70 of 250 posts

Re: Overview of JavaScript ES6 features

#61

Post by mort96 »

WorldMaker wrote: post #47
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…

It also doesn't help that let is 3 letters versus const is 5; programmers if anything will default to the faster to type option.

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.

Re: Overview of JavaScript ES6 features

#62

Post by pauljaworski »

JoeAltmaier wrote: post #49
pmoleri wrote: post #45

Earlier quoted context omitted.

I resisted const for like 10 minutes. You get used to it really quickly and then when you see a 'let' in your code you just know something is happening with that variable afterwards. When I have to go back to programming in a language without const declarations it feels bad.

I know I should use const. I lazily leave it until the end then try to shoe-horn it in. Then it ripples through the code until I give up. Then I hate myself.

This is what makes Eslint so great. If you extend Airbnb's (or write your own very strict) config, it will really enforce best practices for things like this.

I think running eslint --fix will even change your "let"s to "const"s where appropriate, but don't quote me on that.

Re: Overview of JavaScript ES6 features

#63

Post by fryan »

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

buble is a good alternative - small and fast. Doesn't support all of ES2015, but it does support the examples in the article.

https://buble.surge.sh/guide/

Re: Overview of JavaScript ES6 features

#64

Post by fenomas »

acdha wrote: post #30
fenomas wrote: 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 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.

Re: Overview of JavaScript ES6 features

#65

Post by fryan »

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.

I agree that object destructuring makes the code far less readable. Array destructuring however is easy for anyone to grok.

Re: Overview of JavaScript ES6 features

#66

Post by tuxracer »

z3t4 wrote: post #19

var's function scope is a feature! You don't have to place variable declarations in the header! (they are hoisted) Placing the var declarations where they are used makes the code easier to understand. The point of constructor functions is not having to write new . So classes does nothing besides syntactic sugars over the prototype system, witch actually makes it more complicated and the code harder to maintain. Async…

Promises definitely do not just "wrap around" callbacks https://blog.domenic.me/youre-missing-the-point-of-promises/

Re: Overview of JavaScript ES6 features

#68

Post by epmatsw »

depr wrote: post #48
epmatsw wrote: post #35

Earlier quoted context omitted.

Promises and callbacks have fundamentally different behavior. Promises are much more reliable (only executed a single time, always executed asynchronously vs possibly synchronously, etc.) and also have slightly different execution behavior in the event loop. People emphasize the syntax differences, but that's not the most useful thing about Promises imo. You Don't Know JS's async book has an excellent in-depth writeu…

The function passed to the promise is executed synchronously, the call to `then` is always asynchronous.

True, worded that poorly. The resolutions are always executed asynchronously, versus a callback approach where the code receiving the callback can inappropriately and unexpectedly choose to execute the callback synchronously.

Re: Overview of JavaScript ES6 features

#70

Post by fenomas »

treehau5 wrote: post #46
chrisseaton wrote: post #43

Earlier quoted context omitted.

I don't think anything in the rest of their comment has anything to do with block scoping vs function scoping. I do understand the technical difference very well - I have a PhD in implementing programming languages with function scoping like JavaScript. If you agree with the person I was replying to maybe could you humour me and explain why you think function-scoping var is a useful feature?

> I do understand the technical difference very well - I have a PhD in implementing programming languages like JavaScript. I am happy for your PhD and that it is for implementing programming languages like JavaScript. My assertion is the advantage of having function scoping is apparent to those who understand function scoping. Block scoping-style programming in JavaScript was always, in my experienced, shoe-horned in…

> My assertion is the advantage of having function scoping is apparent to those who understand function scoping.

I assert that if you can't say what the advantage is then you don't understand it yourself.

"You'd see the advantages if you understood this, and since you don't you must not understand it" is not a reasonable thing to say to people.

Post reply on HN