Yes, that is a thing, although many didn't know it because most of ES2015 code - let alone ES2015 - gets transpiled.
Honestly I'd have preferred to trigger strict mode as soon as non-simple parameters get parsed.
You want to use default arguments, argument destructuring, spread operators? Fine, but you'll be in strict mode.
But I guess keeping the "use strict" directive mandatory for strict mode make things clearer... But the workaround is messy, sadly.
I actually had plenty of experience with that type of clients, sadly. I've never gone back to IE6 fortunately, but I have with IE7, and that felt terribly outdated right back then.
Oh, sure, Microsoft was still releasing security patches. They could hide behind that. But now it doesn't, and keeping your software outdated, in the bliss of a false sense of security, is plain stupid.
The point is: stop working for them. You already know that you're not going to get anything good from such clients, and you'll find yourself regretting of not having asked for more money.
My point still stands. The problem is with commissioners who don't understand that keeping your software outdated leads only to sub-optimal experience and/or extended development times.
Installing Chrome or Firefox beside IE6 (if they *really* want to use some legacy ActiveX web app) is free, feasible, fast and just a one-time investment for the administrators.
This is why we, as developers, should try to convince them.
"The two latter work with IE6+, which is a big advantage nowadays."
This is why we can't have nice things.
If you're to develop a web application for the modern world, let the users get a browser worth of a web application. Still giving support to IE6 in 2016 is what kept web development back for so long.
Indeed, it's one of the main arguments about the future development of JS promises.
Also, `setTimeout` should be updated to become a promise (alas, won't happen because `setInterval` can't be promisified too).
Would be nice to have a `wake` function that cancels the timeout, rejecting the promise. Something like Angular's $timeout.
But I guess you need at least a bunch of lines for that.
Actually the object spread operator is part of ESNext, so no need to bring JSX up. And it's *so* much better than Object.assign to create immutable objects.
Basically,
const foo = { ...bar };
is equivalent to
const foo = Object.assign({}, bar);
but the former is more compact and readable than the latter.
If you mean that a language is a tool to program a computer so we're safe from using machine code directly, you may be right. But it's not what's commonly intended as a "development tool".
In the case of JavaScript, moreover, the language actually represents our final product, as the code is interpreted and compiled by the client on run-time.
Actually the object spread operator is part of ESNext, so no need to bring JSX up. And it's *so* much better than Object.assign to create immutable objects. Basically, const foo = { ...bar }; is equivalent to const foo = Object.assign({}, bar); but the former is more compact and readable than the latter.