> Trivia: the JavaScript spec people wanted to name it contains, but this was apparently already used by Mootools so they used includes<p>That sounds ... unfortunate, to say the least. Why is the language spec. beholden to one framework written in that language? Doesn't mootools [1] check first for functions it might be overriding?<p>> Emojis and other double-byte chars are represented using multiple bytes of unicode. So padStart and padEnd might not work as expected!<p>It's a shame this isn't followed up on. What's the solution? Only use ASCII? Don't use padStart/padEnd? Does anyone know anything about monospace fonts and any guarantees they make wrt. unicode?<p>[1] <a href="https://mootools.net/core/docs/1.5.2/Types/Array#Array:contains" rel="nofollow">https://mootools.net/core/docs/1.5.2/Types/Array#Array:conta...</a>
Don't get too excited for SharedArrayBuffer. Every major browser disabled it to help mitigate spectre, and there's no current road map for re-enablement.
I'm surprised we don't have the 'safe navigation operator' yet in Javascript.<p>It would be very useful, especially in templating engines, complex VueJS views etc.<p><a href="https://en.wikipedia.org/wiki/Safe_navigation_operator" rel="nofollow">https://en.wikipedia.org/wiki/Safe_navigation_operator</a>
Gigantic sticky header and footer and a huge font size? You can barely fit a single paragraph on the page, this is probably one of the worst website designs that I've ever seen.
> This is because ️ is two bytes long ('\u2764\uFE0F' )!<p>No, that's not bytes. You're counting code points. Because of the way Javascript works, it can't accept code points greater than U+FFFF, so it has to use surrogate pairs.
The ECMAScript spec is weird. One example: in ES5 RegExp.prototype was itself a RegExp, in ES6 it became not a RegExp but just an Object, and in ES7 it stayed an Object but all of the RegExp.prototype methods have to specially check if `this` is RegExp.prototype, thereby pretending to be a RegExp, without actually being one.<p>Why does the spec have this churn?
Can someone please explain why for…of needed to be specialized for its async form?<p>I get why async generators & iterators won't work with plain for…of, but don't get why following is invalid:<p><pre><code> for (const i of [1, 2, 3])
await getThingAtIndex(i);
</code></pre>
The very last example in the article uses similar code, but I feel iterating over array of promises misses the point (as opposed to actually receiving async iterator with `async next () {…}` via `Symbol.iterator`).<p>Or am I missing something here? Thanks.
i personally think javascript ECMAScript committee needs to take a break and chill for a bit. they are changing too fast. it's to the point one forgets if a certain new syntax is available in the whatever version they are and need to check the manual several times. it was fine from es5, 6,7, but if this keeps up at this rate, it's getting too much.
I really don't understand the need for the infix exponentiation operator. Maybe it's because I just don't do calculation heavy JS code but it seems like nothing but a clever little trick you can impress colleagues with. I would hate for JS to evolve towards needing something like <a href="https://www.ozonehouse.com/mark/periodic/" rel="nofollow">https://www.ozonehouse.com/mark/periodic/</a>
> Until now, if we want to share data between the main JS thread and web-workers, we had to copy the data and send it to the other thread using postMessage . Not anymore!<p>This would have been great for a complex Chrome web extension (Gmail "AI" plugin) I developed previously. It relied on quite a significant amount of postMessage'ing back/forth where I had to create a hand-built queue system (on both ends) with redundancy and debugging. And even then I still had a endless series of race conditions and silently failing bugs that were difficult to debug :/
Question from a backend dev who need to do some JavaScript from time to time.<p>What version should I use?
With backend stuff I am usually responsible for installing the versions of the code / language / libraries that I use. With browsers what can I reasonably expect users to have in their browser?
I am pleased to see that features from E continue to be smuggled into ES, like finally-style asynchronous cleanup and template literal enhancements.<p>Edit: Downvotes can't undo our improvements to ES. We will drag JavaScript and its users, kicking and screaming, to a capability-secure future.