Live data from Hacker News

ES6: The features I'm most excited about

justicen.com

131–140 of 144 posts

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

#131
post #25

Earlier quoted context omitted.

Yup. It's as if coffeescript was created by one person (and a bunch of great PRs!), while ES6 came out of a committee.

That's exactly what I like about ES6 (the fact that it has come out of a committee and is now a standard).

Leaving aside the committee preference, what value do you perceive in the fact that it's a standard? It can't be that browsers support it, because they don't. Sure Mozilla will probably get there within the next several years, and Chrome won't be too far behind, but forget about Safari and IE. So you'll still have to use Babel or something like it. Please note, there's nothing wrong with requiring a tool chain, which we already need anyway for minimization, compression, cdns, etc. But once we realize that, we realize that coffeescript is just the same as ES6 in that respect.

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

#132
post #105

Earlier quoted context omitted.

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

In what way would a cleaner ES6 break websites? Browsers aren't going to stop supporting ES5.

Browsers aren't likely to implement two separate languages either. Furthermore, forcing people to pick between "ES5" and "ES6" if they just want to use a single ES6 feature is pretty bad.

So your fundamental choices are really an ES6 that is backwards-compatible or an ES6 that is not used.

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

#133

Earlier quoted context omitted.

I'm writing code against indexedDB (which doesn't use promises), but I want to expose promises to my callers. So I'm wrapping my indexedDB usage in Promises. Also some of indexedDB doesn't seem like it would fit with promises, since some operations have 3 or more callbacks (onsuccess, onerror, onupgradeneeded).

There are a number of IndexedDb libraries that uses promises. However, there is or was a problem with how IndexedDb is specified to work that is not really compatible with promises. I'm not sure if they have fixed this yet. https://github.com/promises-aplus/promises-spec/issues/45#is...

Interesting info, thanks for the pointer!

I can see the benefits of the indexedDb behavior: an open transaction is an exclusive resource, so leaving one dangling locks out other transactions. The auto-commit behavior means it's a lot harder to accidentally leave a transaction dangling. But it is unfortunate that this makes it not play nicely with promises.

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

#134
post #91

Earlier quoted context omitted.

What about it is not simple and consistent? Two different syntaxes, and two different expectations and rules. Var is function scope, and let is block scope.

I feel like in a new design you would pick one or the other, as a second scoping rule would not carry its own weight in terms of what problems it solves vs the complexity of implementing runtimes or learning the language. In that case I'm almost certain you would go for block only as it is the default in nearly all curly braced languages.

I think they have selected one over the other - let. var exists for compatibility, but there is zero reason to use it in new code.

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

#135
post #53

Although arrow functions are nice, they've been around in the form of lambda expressions in C# and other languages for some time, so the initial reaction was more of a "about time" rather than a "wow!" for me. Same goes for generators/yield keyword. Thanks for pointing out the key difference between arrow functions and inline functions being the context of 'this'. 'this' is going to be a source of confusion for a lot…

Yes, a lot of the new features are very "about time" but that doesn't remove the excitement to now have them as a part of JavaScript. 'this' without arrow functions is currently a huge source of confusion. I feel like the arrow functions will help to alleviate a lot of that confusion.

My biggest excitement is that in the past few years JavaScript is now regarded as a first class language, and we're seeing these new versions i.e ES 5,6,7 in a rapid development cycle. I remember being told in the 2000-2002 era that JS was a kiddle language and it was worthless on a resume.

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

#136
post #102
post #95

Earlier quoted context omitted.

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.

Sorry, forgot to add an example library: https://www.npmjs.com/package/es6-class-mixin

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

#137
post #25

Earlier quoted context omitted.

That's exactly what I like about ES6 (the fact that it has come out of a committee and is now a standard).

Leaving aside the committee preference, what value do you perceive in the fact that it's a standard? It can't be that browsers support it, because they don't. Sure Mozilla will probably get there within the next several years, and Chrome won't be too far behind, but forget about Safari and IE. So you'll still have to use Babel or something like it. Please note, there's nothing wrong with requiring a tool chain , whic…

Well said. Many who rejected coffeescript because it required a tool chain now embrace ES6 which requires a toolchain. People rave about ES6 features like classes, arrow functions, destructuring, variable interpolation - as if they are something new. Maybe the best thing about ES6 is that it helped transpiling to be accepted as a mainstream technique.

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

#140

Earlier quoted context omitted.

In what way would a cleaner ES6 break websites? Browsers aren't going to stop supporting ES5.

Browsers aren't likely to implement two separate languages either. Furthermore, forcing people to pick between "ES5" and "ES6" if they just want to use a single ES6 feature is pretty bad. So your fundamental choices are really an ES6 that is backwards-compatible or an ES6 that is not used.

On the other hand forcing newcomers to learn the warts of ES5 when they could learn what is becoming a reasonably elegant language isn't ideal either. Two scoping rules, for example.

An ES-latest runtime + transpilers would be all that browsers needed.

Post reply on HN