51–60 of 144 posts
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, typed arrays, TCO, and so on.
Earlier quoted context omitted.
async/await solves error handling and hanging onto values quite nicely. IMO you should use Babel and take advantage.
link to example please
async function foo() {
try {
const valueOne = await promiseReturningFunction();
const valueTwo = await anotherAsyncFunction(valueOne);
return valueTwo;
} catch (err) {
alert(err);
}
}
foo(); //Returns a Promise.In this example, I've sequenced the resolution of two promises (async functions return Promises when invoked)
If either of these Promises reject or throw an error, or if any of the code within the try {} block throws an error, the error will be caught inline in the catch block (one area only).
You can also see that both Promise's return values are in-scope and continually usable (vs. losing scope with 'then' chains).
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 of people.
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.
JavaScript is object oriented just like any other language. The difference is that it is prototype-based OO instead of class-based OO. I would say that JavaScript's OO is actually more powerful/flexible than other languages but it is less readable and more error prone if you're not careful - For example, the fact that objects can 'borrow' a method from other object an apply it to themselves is a common source of issu…
Rust and Go are so exciting because they've intentionally rejected flexibility without compromising power.
Earlier quoted context omitted.
link to example please
async function foo() { try { const valueOne = await promiseReturningFunction(); const valueTwo = await anotherAsyncFunction(valueOne); return valueTwo; } catch (err) { alert(err); } } foo(); //Returns a Promise. ---- In this example, I've sequenced the resolution of two promises (async functions return Promises when invoked) If either of these Promises reject or throw an error, or if any of the code within the try {}…
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…
'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.
Earlier quoted context omitted.
> .then() does not create a new Promise It returns a promise, right? > var foo = Promise.resolve([1,2,3]).then(function() { return 5 }) > foo
I'd think it would return the original promise, for chaining.
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?
Personally I'm most excited about the module system. It's by far the most confusing thing for our students (and hard to google since you end up going down the rabbit hole of build systems etc.)