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

101–110 of 250 posts

Re: Overview of JavaScript ES6 features

#101

Post by gorhill »

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…

Must be careful with the results on that page. It shows map-string as being slower for ES6 (using `new Map()`) compared to ES5 (using `{}`), and yet I found the opposite, that ES6's Map() is faster in my benchmark[1].

[1] https://gorhill.github.io/obj-vs-set-vs-map/

Re: Overview of JavaScript ES6 features

#102

Post by acdha »

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'd assume the author would be receptive to pull requests for things like the `let` deoptimization.

Re: Overview of JavaScript ES6 features

#103

Post by AgentME »

The most interesting part about template strings was skipped over: tagged template literals. You can prefix a template string with a function which will get called with the list of string parts and the values passed in ${...} parts, and then it's up to the function to choose how to join the values up into the resulting string (or hell, you could make it return something besides a string if you want). The function can even access the raw version of the string containing any backslash escapes in it as-is. The default `String.raw` function is handy if you're writing something like an SQL query with a few \ characters that need to be in the final query. Both of these strings are the same here:

    const a = "SELECT id FROM foo WHERE name CONTAINS r'\\n'";
    const b = String.raw `SELECT id FROM foo WHERE name CONTAINS r'\n'`;
You could even assign `String.raw` to a variable first, and then make strings look like raw string literals of other languages:

    const r = String.raw;
    const s = r`SELECT id FROM foo WHERE name CONTAINS r'\n'`;
Another good use of template strings is automatic HTML encoding (with a small module of mine on npm): https://www.npmjs.com/package/auto-html

Re: Overview of JavaScript ES6 features

#104

Post by BinaryIdiot »

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 completely agree and it's nice to see someone else with the same thoughts because I've found a ton of opposition regarding this. I hate the destructuring syntax. While I understand how it works now I felt like it took me too long and feels very non-obvious so I try to avoid it in my code unless absolutely impossible to avoid. I don't find it intuitive especially for newer developers.

Re: Overview of JavaScript ES6 features

#105

Post by oldmanjay »

mort96 wrote: post #61
WorldMaker wrote: post #47

Earlier quoted context omitted.

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.

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.

Re: Overview of JavaScript ES6 features

#106

Post by bzbarsky »

addisonj wrote: post #59
VeejayRampay wrote: post #53

I have a question: What does `for element of arr` buy me over `arr.forEach(element => ...)` I don't find the for...of syntax particularly appealing or useful, but I might be missing something. Is it a matter of preference?

for...of isn't only for arrays. Anything that implements the Symbol.iterator functionality can use for..of, which is pretty nifty for some custom classes and also includes things like the new Map and Set collections, see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... However, even in just arrays there is arguably a benefit. Namely, an extra function being created and invoked with forEach. While in a…

If you're not in a JIT, for-of performance is going to be terrible too. Instead of creating a single function (which may not happen _anyway_ in the non-jit case, depending on how it's implemented) you now have to create an iterator result object for every single thing you get out of the iterator.

In a JIT, forEach is actually _easier_ to optimize well (just need to inline the callback function, though of course that can fail for various reasons) than for-of (need to inline the calls to next() on the iterator, need to do escape analysis on the return value of next(), need to do scalar replacement on the return value of next; note that this is a strict superset of the work needed to optimize forEach).

for-of can be nicer to read, and can work on arbitrary iterables. Those are its key strengths. Performance just isn't, unfortunately.

Re: Overview of JavaScript ES6 features

#107

Post by kin »

Appreciate the article, but this is relatively dated information. While I can see that many enjoyed the article, many have also been working in ES6 for over a year now. If you're ready to join, I highly suggest everyone make their way to https://babeljs.io/ and everything it has to offer resource-wise or tooling-wise.

Re: Overview of JavaScript ES6 features

#108

Post by btdiehr »

pauljaworski wrote: post #62
JoeAltmaier wrote: post #49

Earlier quoted context omitted.

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.

--fix is a godsend.

Re: Overview of JavaScript ES6 features

#109

Post by pitaj »

ng12 wrote: post #85
djur wrote: post #41

Earlier quoted context omitted.

It should have been "let"/"let mut", not "const"/"let" (or some other scheme that makes immutable bindings terser). I recall people warning of this outcome at the time of standardization.

I don't think it's a terminology problem. In fact, "let" and "const" are probably the right terms. Both are descriptive and exist in other programming languages.

`final` is a better term for real constants

Re: Overview of JavaScript ES6 features

#110

Post by fryan »

ggregoire wrote: post #72
fryan wrote: post #65

Earlier quoted context omitted.

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

It depends I think. For example, in my opinion const Header = ({ children, iconName, iconSize, title }) => { ... }; is more readable than const Header = (props) => { ... };

    const Header = ({ children, iconName, iconSize, title }) => { ... };
Once you get used to the destructuring parameter idiom, sure. It also conveys more information.

But that statement is overloaded in that it makes use of implicit object shortcuts which has a bit of a learning curve for longtime ES5 users.

    const Header = ({
        children: children, 
        iconName: iconName, 
        iconSize: iconSize, 
        title: title }) => { ... };
When object destructuring is nested it can be confusing and more verbose.
Post reply on HN