Live data from Hacker News

ES6: The features I'm most excited about

justicen.com

121–130 of 144 posts

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

#121
post #51

ES6 is a mixed bag for me. I'm against block scope in a way. It's semi-useful, but it's just sugar. So many features of ES6 seem to be designed for people who don't want to bother learning javascript: classes, block scope, arrow syntax, etc. It's just trying to shoehorn javascript into the template every other language follows when javascript is not every other language. That being said, I like iterators, weak maps,…

Fat arrows are increasingly becoming one of my favourite additions.

No more `function() {}.bind(this);` since `() => {};` is equivalent. It makes it clearer for the reader that the code block inherits scope.

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

#122

Earlier quoted context omitted.

I like Jquery's Deferred better then ES6 Promise. Promises lack the `always` callback, they don't have any `progress` events. The spec on mdn[0] doesn't mention asynchronous `then` or `catch` behavior. If the callback in Jquery `Deferred#then` returns a Deferred that deferred will be returned by `then`. // Basic async function, resolves after n milliseconds function wait(n) { var promise = $.Deferred(); setTimeout(pr…

I don't see the problem... function doSomething() { return new Promise((resolve,reject)={ setTimeout(reject,100); }) .catch(() => []) } doSomething().then((arg) => console.log(arg));

The problem may have just been the docs. They say .catch and .then can be composed but I didn't see any mention of the behavior.

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

#123
post #85
post #13

Earlier quoted context omitted.

Hm, at first glance I am as well, especially with tagged template strings. Those look particularly simple but powerful. Generally though, is it reasonable for features such as these to be included at the language level? I primarily use ES5 JavaScript so I'm used to pulling in a decent amount of modules (in this case handlebars, underscore, etc.) for things like templating. But I will be relieved to have a language-st…

I too was reluctant of using many of the new ES6 features, but as I've begun to adapt them I've come to appreciate them a lot! In fact, when using Babel to compile ES2015/2016 you can in many cases rid yourself of things like Underscore/lodash[1], Promise libraries, etc. I've recently started a new project in React/Flux, and I've cut away 3 or 4 dependencies compared to previous projects by fully embracing ES2015/201…

[deleted]

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

#124
post #57

Earlier quoted context omitted.

No, it returns a new Promise that's already been resolved to the value you returned previously.

Not quite :) See my paste above, it returns a new Promise in pending state that will return the value in the new then block ("5" here), possibly immediately. (i.e. pending for one event loop tick, then resolved)

Yes, you're right. My bad.

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

#125

Earlier quoted context omitted.

`class` trades the flexibility of prototypes for the familiarity of other languages. :(

This is just false. `class` is sugar over prototypes. Nothing is lost.

Yes, it is just "sugar", but it cements one way of doing things.

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

#126

Earlier quoted context omitted.

I think it's fair to say that people who want to write object-oriented Javascript are very excited by class. Those of us who have found that the non-OO nature of Javascript is part of what makes it so productive are... much less excited.

yep. personally I've taken a much more functional approach to my javascript development that barely relies on oop.

Yup. The class keyword is a huge step backward, and it was only put it because of a very different world several years ago when all this was put into motion. It is just a wrapper around prototypal inheritance, but hides a lot of the features in favor of making things look like other OOP languages, even though it isn't.

It is also very debatable if classic OOP is even good at all. JS was heading in the right direction, with more functional approaches, factory based object creation, etc... and now it's all back to square one.

Fortunately I work on a product where most devs have functional programming backgrounds, so the argument isn't too hard to make. But I fear for the community in general.

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

#127
post #5

Wow. I can't believe template strings ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... ) aren't in this list. I'm incredibly excited to start having those at my disposal.

is there pythonesque """ """ triple quotes for literal whitespace?

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

#128

Earlier quoted context omitted.

Ideally, if you're writing business logic, you shouldn't be creating promises but consuming/combining/chaining them from libraries.

What would make you say that? Why wouldn't you use promises in your business logic?

Yeah what dcoder said. You only need to create a promise at the source of an async event like IO. Internal logic will be downstream of IO and therefore will be just be sequencing promises generated elsewhere. You do not (and should not) need to create intermediate promises to do that.

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

#129
post #105

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.

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

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

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

Yes, as a matter of style you could just use let everywhere, and know that var is there for legacy compatibility reasons.
Post reply on HN