☝️ Note that you can use (most of) these features today already, as browsers start rolling them out (unflagged) when they hit Stage-3. So no, you don’t have to wait until mid-2021 to start using them.
An ECMAScript Language Feature that I’m looking forward to is Declarations in Conditionals. It adds the capability to declare variables inside conditional statements. Let’s take a look …
~
Setting the Scene
Say you want to iterate over an array which might be tucked away inside an object. To do so, you’d most likely first check for that variable’s existence using a simple if
if (user.meta.interests) {
for (let interest of user.meta.interests) {
// …
}
}
As we’re now typing user.meta.interests twice in our code you might declare an intermediary variable, and use that further down in your code:
let interests = user.meta.interests;
if (interests) {
for (let interest of interests) {
// …
}
}
But now you have a nasty side-effect: you’re loitering the scope with this extra interests variable. This is quite useless, as you’re only using it inside the if statement.
💁♂️ To make it totally failsafe, you might also want to add some Optional Chaining in there and check if interests is iterable, but that’s beyond the scope of this post.
~
Hello “Declarations in Conditionals”
With the “Declarations in Conditionals” proposal we can keep this extra interests variable, yet without loitering the outer scope. We do this by declaring the variable directly inside the conditional (e.g. if statement), like so:
if (let interests = user.meta.interests) {
for (let interest of interests) {
// …
}
}
⚠️ Note that this is an assignment right there, not an equality check!
With that one line the interests variable:
will be declared
will have a value assigned to it
will be checked for being falsy or not
Scope-wise the interests variable will have its scope limited local to the conditional (e.g. only visible inside the if).
The proposal limits declarations to use either const or let; declarations in conditionals with var are currently not allowed.
💡 You might not 100% realize it, but you’re already doing this kind of thing when using a for loop. Inside its initialization part (e.g. its first part) you are also declaring variables.
for (let i = 0; i < 5; i++) {
console.log(i);
}
☝️ Did you know that you can declare more than one variable there, separated by a comma? In the example below I declare an extra variable len right after declaring i:
const cars = ['Ford', 'Mercedes', 'BMW'];
for (let i = 0, len = cars.length; i < len; i++) {
console.log(cars[i]);
}
🤔 What about the scope of len you might ask? Variables declared using let are scoped to the statement (e.g. local to the loop). Variables declared using var get hoisted. And oh, it’s not allowed to declare variables using const here.
~
So, when can we use this?
The proposal is currently Stage-1, so it still has a long way to go before it can become an official part of the standard — if it ever will be.
Stage-1 is the Proposal stage. It signals that the committee is showing interest in the proposal and that it is seeking further investigation on how to tackle it. At this stage the proposal is subject to heavy changes. It is only when a proposal reaches Stage 4 that it is ready to become part of the ECMAScript Specification.
As it’s still Stage-1, it can change quite a lot before it to be finished. And I’m quite sure it will change, as right now:
It only allows declaring one variable.
It only checks for values being falsy or not.
These two feature are currently listed under “Future Work” of the proposal, and it looks like this:
if (let x = 1, y = 2; x || y) {
// …
}
Must say I’m pretty curious how this one will evolve, as I’m already quite excited about it: it’s one of those small additions that will have a pretty big impact on how I write my code.
Happening right now is ESNEXT Conf a fully remote conference exploring the future of JavaScript and the web. When I saw the CFP float by, it sounded like a perfect match for my talk “ESNext: Proposals to look forward to”. Thankfully the organisers – Fred and Drew from Pika – also felt that ways and the put me in the line-up.
With the yearly ECMAScript releases (ES2015..ES2020) of a lot of things have changed in JavaScript-land, and there’s even more to come. This talk takes a look at a few of the newest (ES2020) and some of the upcoming ECMAScript features, which (hopefully) will become part of the ECMAScript Language Specification in the near future.
ESNext Proposal: Cancellation API (+ Mention of AbortController)
ESNext Proposal: Declarations In Conditionals
ES2019 Feature: Object.fromEntries()
ESNext Proposal: Slice Notation
ESNext Proposal: Pattern Matching
Fin.
~
Talk Video
Once the video has been released, I’ll update this post to include it. Here it is:
~
Thanks to the organisers for having me, and thanks to the attendees for coming to see me. I hope you all had fun attending this talk. I know I had making it (and whilst bringing it forward). A shame we couldn’t meet in person though, perhaps at a next edition 😉
The past few days I’ve been attending some virtual conferences. At JS VidCon and JavaScript Remote Conf I also joined as a speaker, to bring forward my ever-evolving talk “ESNext: Proposals to look forward to”
With the yearly ECMAScript releases (ES2015..ES2020) of a lot of things have changed in JavaScript-land, and there’s even more to come. This talk takes a look at a few of the newest (ES2020) and some of the upcoming ECMAScript features, which (hopefully) will become part of the ECMAScript Language Specification in the near future.
ESNext Proposal: Cancellation API (+ Mention of AbortController)
ESNext Proposal: Declarations In Conditionals
ESNext Proposal: Slice Notation
ES2019 Feature: Object.fromEntries()
ESNext Proposal: Pattern Matching
Fin.
Thanks to the organisers for having me, and thanks to the attendees for coming to see me. I hope you all had fun attending this talk. I know I had making it (and whilst bringing it forward). A shame we couldn’t meet in person though, perhaps at a next edition 😉
// "Or Or Equals" (or, the Mallet operator)
a ||= b;
// "And And Equals"
a &&= b;
// "QQ Equals"
a ??= b;
Basically these operators translate to these actions being performed:
||= will only assign the value of b into a if a is falsy (false, 0, null, etc.).
&&= will only assign the value of b into a if a is truthy (true, 1, {}, etc.).
??= will only assign the value of b into a if a is null or undefined.
🤔 Not familiar with that ?? you see there? It’s the Nullish Coalescing Operator which is part of ES2020 and it’s awesome!
~
These operators will change the way you code, see this before/after example:
// Without Logical Assignment
name = name ?? 'stranger';
// With Logical Assignment
name ??= 'stranger'
Using Logical Assignment Operators will save you to writing an if statement. Additionally it can save a setter execution.
let name = 'bramus';
// Without Logical Assignment: the value of name will *always* be set to (here: to its own value), even though name is not nullish
name = name ?? 'stranger';
// With Logical Assignment: name won't be reassigned as name is not nullish
name ??= 'stranger'
~
The Logical Assignment Operators proposal is currently Stage-3.
Stage-3 is the Candidate Stage where the feature is considered complete and only critical changes will happen based on implementation experience. If all goes well the proposal will advance to Stage 4 without any changes, after which it will to become part of the ECMAScript Specification.
Since it’s Stage-3, we can expect things to look good implementation-wise, which it totally is:
Babel: The “Mallet Operator Transformer” got added a long time ago(back when it was still called “6to5”). Nowadays you should use the @babel/plugin-proposal-logical-assignment-operators plugin.
Chrome/V8: The feature got added two days ago and will get shipped with V8 v8.4 behind the flag --harmony-logical-assignment
Firefox/SpiderMonkey: Version 77 should support it, but I couldn’t get it to work in Firefox Developer Edition (77.0b2). Firefox Nightly (78.0a1) works fine.
I don’t expect this proposal to change at all anymore and can see it advancing to Stage-4 at the one of the next TC39 meetings. That way this proposal will most likely become part of ES2021.
~
Did this help you out? Like what you see? Thank me with a coffee.
I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!
“Worth It: Modern JS edition” is a small tool to analyze how much less JavaScript is downloaded in modern browsers as a result of it using the module/nomodule pattern.
💡 The module/nomodule pattern is a technique to ship ES2015 modules to browsers that support, whilst also keeping older browsers (that don’t support it) happy. It was covered here on bram.us back in July 2017
An ECMAScript Internationalization API Feature that currently is in Stage-3 and that has already landed in V8 version 8.1 is Intl.DisplayNames. It’s a way to get localized display names for languages, scripts, regions and others.
🤔 Note that this proposal is part of ECMA-402 (the ECMAScript Internationalization API Specification) and not ECMA-262 (The ECMAScript Language Specification). Therefore this proposal will not be part of the yearly "ES20XX”, as that term only applies to ECMA-262.
To advance proposals in ECMA-402, TC39 uses the same 5-stage-process as they use in ECMA-262.
Stage-3 is the Candidate Stage where the feature is considered complete and only critical changes will happen based on implementation experience. If all goes well the proposal will advance to Stage 4 without any changes, after which it will to become part of the ECMAScript Specification.
The idea is that you as a developer should not build your own list of localized strings for languages, regions, etc. but that the JavaScript runtime should provide if for you:
Translation of languages, regions or script display names requires large amount of data to transmit on the network, which is already available in most browsers. The Intl.DisplayNames API will allow web developers to shrink the size of their HTML and/or ECMA script code without the need to include the human readable form of display names and therefore reduce the download size to decrease latency.
// Get display names of region in English
const regionNames = new Intl.DisplayNames(['en'], {type: 'region'});
console.log(regionNames.of('419')); // "Latin America"
console.log(regionNames.of('BZ')); // "Belize"
console.log(regionNames.of('US')); // "United States"
console.log(regionNames.of('BA')); // "Bosnia & Herzegovina"
console.log(regionNames.of('MM')); // "Myanmar (Burma)"
// Get display names of language in Traditional Chinese
const languageNames = new Intl.DisplayNames(['zh-Hant'], {type: 'language'});
console.log(languageNames.of('fr')); // "法文"
console.log(languageNames.of('zh')); // "中文"
console.log(languageNames.of('de')); // "德文"
// Get display names of script in Traditional Chinese
const scriptNames = new Intl.DisplayNames(['zh-Hant'], {type: 'script'});
console.log(scriptNames.of('Latn')); // "拉丁文"
console.log(scriptNames.of('Arab')); // "阿拉伯文"
console.log(scriptNames.of('Kana')); // "片假名"
// Get display names of currency code in English
const currencyNames = new Intl.DisplayNames(['en'], {type: 'currency'});
console.log(currencyNames.of('USD')); // "US Dollar"
console.log(currencyNames.of('EUR')); // "Euro"
console.log(currencyNames.of('TWD')); // "New Taiwan Dollar"
console.log(currencyNames.of('CNY')); // "Chinese Yuan"
~
Syntax
The constructor takes two arguments: locales and options. Both are optional:
new Intl.DisplayNames([locales[, options]]);
Once you have a Intl.DisplayNames instance, you use its .of method to request a localised string
Intl.DisplayNames.prototype.of(code);
~
Constructor Arguments
locales
The locales argument is a BCP 47 language tag which identifies the locale to use. The main parts, amongst others, of a BCP 47 language tag are language, script, and region
The language part is a 2/3 character long ISO 639-1 code
The (optional) script part is a 4 character long ISO 15924 code
The (optional) region part is a 2 alpha or 3 digit long ISO 3166-1 code
When more than one part is present, they are separated by a dash (-)
Examples:
"nl": Dutch (language).
"nl-BE": Dutch as used in Belgium (language + region).
"zh-Hans-CN": Chinese written in simplified characters as used in China (language + script + region).
When locales is omitted, it will default to the language-setting of the browser/system.
options
The options object allows you to tweak how Intl.DisplayNames behaves. It has the following properties:
localeMatcher
The locale matching algorithm to use. Possible values are "lookup" and "best fit"(default)
style
The length of the output message, e.g. "English (United States)" vs. "English (US)". Possible values are "long"(default) and "short", or “narrow” (which mostly yields the same result as "short", depending on the language)
type
What you want to display. Possible values are "region", "script", "language", or "currency".
~
Intl.DisplayNames.prototype.of Arguments
code
Depending on the type you passed into the constructor, you pass in a different value for code:
Intl.DisplayNames already shipped in V8 v8.1(included in the upcoming Chrome 81) and will be available in Node 14. Other JS runtimes / browsers don’t support it at the time of writing.
~
The future: More types to come!
When looking at the open issues listed on the proposal’s repository you can see that there’s more to come in a future version of Intl.DisplayNames: support for units, timezones, emoji names, date parts (such as months, weekdays, etc).
For this first release the scope was limited to supporting the types "region", "script", "language", and "currency".
~
Did this help you out? Like what you see? Thank me with a coffee.
I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!
Matthew Gerstman explaining a lot of terms that evolve around JavaScript: ECMA, TC39, Babel, Polyfills, …
So you Google how to make your app work in IE 10, or 11, or whatever. You’re quickly flooded with acronyms and terms you’ve never heard before ES5, ES6, ESNext, ES2020, TC39, ECMA. What’s a transpiler? People are debating about polyfills and ponyfills; is there a difference?
If you’re overwhelmed, that’s okay, it’s a lot. This article will attempt to cover the entire ecosystem around shipping new-ish JavaScript to older browsers and how the community decides what features get added to JavaScript in the first place; let’s dive in.
UPDATE June 2020: This feature has advanced to Stage-4 and will be part of the ES2021 Specification! 🎉
An ECMAScript Language feature that’s currently in Stage-3 is String.prototype.replaceAll, a handy way to replace all instances of a piece of text in a string.
Stage-3 is the Candidate Stage where the feature is considered complete and only critical changes will happen based on implementation experience. If all goes well the proposal will advance to Stage 4 without any changes, after which it will to become part of the ECMAScript Specification.
~
The Problem
If you ever needed to replace a piece of text in a string you most likely will have used String.prototype.replace:
'the quick brown fox jumps over the lazy dog'.replace('a', '_')
// ~> "the quick brown fox jumps over the l_zy dog"
There’s one somewhat counterintuitive issue with it though: it only replaces the first match it finds:
'the quick brown fox jumps over the lazy dog'.replace('o', '_')
// ~> "the quick br_wn fox jumps over the lazy dog"
One of the workarounds we can use today is to use a global regular expression (e.g. a RegEx with the g flag):
'the quick brown fox jumps over the lazy dog'.replace(/o/g, '_')
// ~> "the quick br_wn f_x jumps _ver the lazy d_g"
~
The Solution
The String.prototype.replaceAll proposal offers us a non-hacky solution, right in the JavaScript language:
'the quick brown fox jumps over the lazy dog'.replaceAll('o', '_')
// ~> "the quick br_wn f_x jumps _ver the lazy d_g"
Its method signature is exactly the same as String.prototype.replace‘s:
Implementation-wise it differs in only two ways from String.prototype.replace:
When given a string as its searchValue: replaceAll will replace all occurrences, whereas replace will only replace the first — hence why it is being proposed in the first place.
When given a non-global regular expression (e.g. a RegEx without the g flag) as its searchValue: replaceAll will throw an exception as the word replaceAll implies to “replace all” but the lack of the g flag implies exactly the opposite — Computer says no.
~
Browser Support
Although the feature is Stage-3 already, it’s not enabled in browsers yet. To test this feature:
In Chrome: Enable #enable-javascript-harmony in chrome://flags/
In Firefox: N/A
In Safari: Enabled in Safari Technology Preview Release 97
~
Did this help you out? Like what you see? Thank me with a coffee.
I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!
A proposal to the ECMAScript Internationalization API Specification (ECMA-402) that just moved to Stage-4, is Intl.RelativeTimeFormat. It’s a way to format time in a relative manner – e.g. “10 minutes ago” or “in 3 quarters” – while also taking a language into account.
🤔 Note that this proposal is part of ECMA-402 (the ECMAScript Internationalization API Specification) and not ECMA-262 (The ECMAScript Language Specification). Therefore this proposal will not be part of the yearly "ES20XX”, as that term only applies to ECMA-262.
To advance proposals in ECMA-402, TC39 uses the same 5-stage-process as they use in ECMA-262.
Stage-4 is the Finished Stage and indicates that the proposal is ready to become part of the ECMAScript Specification.
const rtf_en = new Intl.RelativeTimeFormat('en');
console.log(rtf_en.format(-1, 'day')); // ~> 1 day ago
console.log(rtf_en.format(30, 'seconds')); // ~> in 30 seconds
const rtf_nl = new Intl.RelativeTimeFormat('nl-BE', {
localeMatcher: 'best fit', // other values: 'lookup'
numeric: 'auto', // other values: 'always'
style: 'short', // other values: 'long' or 'narrow'
});
console.log(rtf_nl.format(-1, 'day')); // ~> gisteren
console.log(rtf_nl.format(30, 'seconds')); // ~> over 30 sec.
~
Syntax
The constructor takes two arguments: locales and options. Both are optional:
new Intl.RelativeTimeFormat([locales[, options]]);
Possible units to use while formatting are "year", "quarter", "month", "week", "day", "hour", "minute", and "second".
~
Constructor Arguments
locales
The locales argument is a BCP 47 language tag which identifies the locale to use. The main parts, amongst others, of a BCP 47 language tag are language, script, and region
The language part is a 2/3 character long ISO 639-1 code
The (optional) script part is a 4 character long ISO 15924 code
The (optional) region part is a 2 alpha or 3 digit long ISO 3166-1 code
When more than one part is present, they are separated by a dash (-)
Examples:
"nl": Dutch (language).
"nl-BE": Dutch as used in Belgium (language + region).
"zh-Hans-CN": Chinese written in simplified characters as used in China (language + script + region).
When locale is omitted, it will default to the language-setting of the browser/system.
options
The options object allows you to tweak how Intl.RelativeTimeFormat behaves. It has the following properties:
localeMatcher
The locale matching algorithm to use. Possible values are "lookup" and "best fit"(default)
numeric
The format of output message. Possible values are "always"(always include a number in the output, default) or "auto"(which allows output such as “in 1 day” to be rewritten in the more natural "tomorrow")
style
The length of the output message, e.g. "in 1 month" vs. "in 1 mo.". Possible values are "long"(default), "short", or “narrow” (which mostly yields the same result as "short", depending on the language)
~
Extracting all parts with formatToParts
If you don’t want a string to be returned, you can use formatToParts() to get an object describing all parts:
const rtf = new Intl.RelativeTimeFormat("en", { numeric: "auto" });
// Format relative time using the day unit.
rtf.formatToParts(-1, "day");
// > [{ type: "literal", value: "yesterday"}]
rtf.formatToParts(100, "day");
// > [{ type: "literal", value: "in " }, { type: "integer", value: "100", unit: "day" }, { type: "literal", value: " days" }]
~
JS/Browser Support
Intl.RelativeTimeFormat shipped in V8 v7.1.179 (included Chrome 71) and Firefox 65.
