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

ES6: The features I'm most excited about

justicen.com

Post reply on HN
Print view View original

101–110 of 144 posts

Re: ES6: The features I'm most excited about

#101

Post by AshleysBrain »

koolba wrote: post #99

What's the point of promises being part of ES6? I understand them and use them quite a bit. I just don't understand why they're in the language spec. They don't add anything new to the language ( vs say generators or symbols ). Is it purely for performance?

It allows web APIs built-in to the browser to return a promise, e.g. audioContext.decodeAudioData(data).then(...). If you just used a library, the browser wouldn't know how to wrap the returned value in a promise. It also guarantees interoperability between all APIs using promises, avoiding any incompatibility between different libraries.

Re: ES6: The features I'm most excited about

#102

Post by spion »

hokkos wrote: post #95
spion wrote: post #76

I don't understand why everyone considers classes controversial. If you look at code in the wild, it already does what classes desugar to: everyone already writes constructor function and attaches properties to their prototypes. At least now with classes, users coming from other languages wont be as tempted to make their own completely incompatible object systems.

It is more the "extends" than "class" that is controversial because it eschews other pattern like mixins.

I think extends mixin(SomeClass, AnotherClass) will work.

Re: ES6: The features I'm most excited about

#103

Post by grandalf »

15155 wrote: post #62
grandalf wrote: post #55

Earlier quoted context omitted.

I see. Not sure what the best practice is for the losing scope in then chains issue with promises. I ended up creating something along the lines of a message object designed for each chain, which felt like a smell.

Feels like an un-compiler-assisted State monad. IMO threading an object through is probably the best method, unfortunately. You could use an Immutable Record or something to help keep it under control. I would personally just use async/await to more explicitly handle the sequencing/binding.

Agreed. I think I'll refactor... thanks for the example.

Re: ES6: The features I'm most excited about

#104

Post by woah »

alkonaut wrote: post #89
charriu wrote: post #86

I'm a bit worried about ES6 making the language harder to understand. For example, scoping: For backwards compatibility reasons, var has to stay function scoped. But now we also have let, which has different scoping rules. Also, Symbols: [Symbol.iterator]() - what? Why?! On the other hand, stuff like arrow functions, template strings, modules and tail optimization are awesome.

Can someone explain the reasoning behind having any kind of backwards compatibility? Who would pick a worse-but-compatible ES6 over a better incompatible version? For example, the scoping rules: why have two separate scoping rules for let and var? To put it another way, would ES6 have let and var with differing scoping rules if it was designed today? If not, then it's a flaw (any difference from what a clean redesign…

Python 3

Re: ES6: The features I'm most excited about

#105

Post by Touche »

alkonaut wrote: post #89
charriu wrote: post #86

I'm a bit worried about ES6 making the language harder to understand. For example, scoping: For backwards compatibility reasons, var has to stay function scoped. But now we also have let, which has different scoping rules. Also, Symbols: [Symbol.iterator]() - what? Why?! On the other hand, stuff like arrow functions, template strings, modules and tail optimization are awesome.

Can someone explain the reasoning behind having any kind of backwards compatibility? Who would pick a worse-but-compatible ES6 over a better incompatible version? For example, the scoping rules: why have two separate scoping rules for let and var? To put it another way, would ES6 have let and var with differing scoping rules if it was designed today? If not, then it's a flaw (any difference from what a clean redesign…

> Can someone explain the reasoning behind having any kind of backwards compatibility?

Not breaking millions of websites.

Re: ES6: The features I'm most excited about

#107

Post by robinson7d »

Kiro wrote: post #84
nodesocket wrote: post #9

I was just talking to my friend who works at NetFlix on the frontend team about ES6, he is most excited about destructuring `let { name, age, gender } = user;`. I however advocate that the new class syntax is the best part of ES6. Take the following trivial OOP example, which I think reads so much easier a lot like PHP. "use strict"; class Vehicle { constructor(name) { this.kind = 'Vehicle'; this.name = name; } print…

> he is most excited about destructuring `let { name, age, gender } = user;`. Why is this a big deal? Seems pretty trivial.

One of the reasons that it's a big deal is because of what it means for functions. It helps make named-parameters more attractive, which can help a lot with code maintainability.

Example code: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Additionally, it's nice sugar for module loading, for modules that export multiple values.

Re: ES6: The features I'm most excited about

#108

Post by pluma »

koolba wrote: post #99

What's the point of promises being part of ES6? I understand them and use them quite a bit. I just don't understand why they're in the language spec. They don't add anything new to the language ( vs say generators or symbols ). Is it purely for performance?

Paving the cowpaths. Promises were already standardized before ES2015 arrived, but now you can just write libraries using promises without having to rely on the developer providing their promise implementation of choice. This also prevents scenarios where you might end up with N different promise implementations because you're using N libraries, each depending on a different promise module (e.g. bluebird, Q, jQuery.Deferred, AngularJS $q, etc) all of which are slightly different.

This also means more feature-rich implementations can just extend the native promises instead of implementing everything from scratch, though for me this pretty much spells the end of third-party promise implementations.

In other words, they've been added for the same reason as the various new helper methods: not because they add new functionality, but because they provide a reliable well-defined and consistent solution to a very common problem.

Re: ES6: The features I'm most excited about

#109

Post by pluma »

Touche wrote: post #105
alkonaut wrote: post #89

Earlier quoted context omitted.

Can someone explain the reasoning behind having any kind of backwards compatibility? Who would pick a worse-but-compatible ES6 over a better incompatible version? For example, the scoping rules: why have two separate scoping rules for let and var? To put it another way, would ES6 have let and var with differing scoping rules if it was designed today? If not, then it's a flaw (any difference from what a clean redesign…

> Can someone explain the reasoning behind having any kind of backwards compatibility? Not breaking millions of websites.

*billions.

Maybe even orders of magnitude more than that.

Re: ES6: The features I'm most excited about

#110

Post by tel »

tragic wrote: post #74
smt88 wrote: post #54

Earlier quoted context omitted.

It's possible to get power without flexibility. Flexibility is bad -- it creates code that is idiomatic to the person who wrote it. Rust and Go are so exciting because they've intentionally rejected flexibility without compromising power.

Flexibility is not 'bad' - it's a tradeoff. More flexible languages are better for writing DSLs, etc; but using them means a lot of self discipline regarding code style. One thing I wish JS had is a PEP8-style canonical style document. I would find that more useful than classes. On classes, I am among the less excited about them; however, we are in a ridiculous situation where there are about 500 different library im…

> More flexible languages are better for writing DSLs, etc;

Citation needed, or, I'm not quite sure I agree with you there. In fact, I think I believe the exact opposite (to a degree).

Post reply on HN