/What’s new in JavaScript (Google I/O ’19)

What’s new in JavaScript (Google I/O ’19)

Video: What’s new in JavaScript (Google I/O ’19)

Subtitles

This is Sathya (hey everyone), my name is Mathias and we work on the V8 team at Google. V8 is the JavaScript engine and the WebAssembly engine that’s used in Google Chrome and in other embedders such as Node.js and Electron. Other Chromium-based browsers such as Opera and very soon Microsoft Edge also build on top of V8. JavaScript started out as the scripting language of the web, and to this day it’s still a crucial piece of web technology. But today, JavaScript’s reach extends far beyond just the web to the entire surrounding platform. So if we take a step back from V8 and Chrome we can see that JavaScript allows you to create engaging web apps across a wide variety of browsers. With Node.js, JavaScript can be used to build command-line tools, servers, and other applications.

With Electron, JavaScript and other web technologies can be used to build cross-platform desktop apps. React Native enables building cross-platform mobile apps. JavaScript can even run on low-cost IoT devices nowadays. JavaScript is *everywhere*, so as a developer learning JavaScript or improving your JavaScript skills is an excellent time investment. At Google we want to enable this enormous JavaScript ecosystem. We do so in multiple ways. TC39 is the committee that governs the evolution of ECMAScript, which is the standard behind the JavaScript language. We actively participate in these standardization efforts together with other browser vendors and industry stakeholders, bringing back feedback from us as implementers and from the developer community. On top of our participation in the standards process we constantly improve our own JavaScript engine, V8. We boost its performance, reduce its memory usage, and we implement new language features as they’re being standardized.

Our mission is to lead real-world performance for modern JavaScript and WebAssembly, and to enable developers to build a faster future web. You might notice WebAssembly is also implemented in V8, alongside JavaScript. Our presentation today focuses just on JavaScript features, but there’s a separate WebAssembly presentation at I/O. If you’re interested, check out Deepti and Surma’s “WebAssembly for web developers” talk later today. Now let’s discuss what we mean when we say real-world performance. We’ve stepped away from synthetic benchmarks where someone sits down and writes code specifically for benchmarking purposes. Such code often does not reflect real-world usage and so optimizing for these scenarios as a JavaScript engine has limited impact.

Instead we now focus on optimizing real websites and JavaScript applications. Let’s walk through some example improvements. Since Chrome 61, we’ve doubled our raw JavaScript parsing speed as measured on real-world websites. On top of that we’ve managed to move up to 40% of parsing and compilation work off of the main thread so that it no longer blocks website startup. 40%! And we’re working to increase this percentage even further. Our efforts are not just visible in Chrome but also in Node.js. Overall, promises got up to 11 times faster between Node.js 7 and Node.js 12. Promise.all in particular got up to 13 times faster. To put that in Chrome version numbers, that’s Chrome 55 compared to Chrome 74. But performance is not just about parse speed and runtime performance. Memory consumption also plays a big role. And that’s why between Chrome 70 and Chrome 76, we worked to reduce overall memory consumption by 20% as measured on Android Go devices running real-world web apps. So we’ve improved startup performance by boosting JavaScript parsing speed, we’ve improved runtime performance by optimizing async and promises, and we’ve significantly reduced memory consumption along the way.

And those are just some examples of what we’ve been working on. Wait, is something wrong with our slides? That does look funky… but I think we talked about this last year — in a regular expression, this would be a lookbehind. I see. So I guess it’s time to look… back? Alrighty then! Exactly one year ago, we were right here at Google I/O, telling you about lots of exciting new JavaScript features. And some of those features were pretty cutting-edge, they were still being standardized at the time. And so unfortunately for many features we had to say that they weren’t yet supported in all modern environments. But today, one year later, feature support looks a lot better. In fact all the features you see here are now fully supported across modern browsers and Node.js.

You no longer have to polyfill or transpile these features when targeting modern environments. That means you can ship smaller JavaScript bundles so your apps load faster, and you get those juicy performance improvements as well. On top of that, some of the other features we talked about have received updates since last year. Let’s take a look at what’s changed, starting off with class fields. Here’s a code example that creates an instance of a class named IncreasingCounter. Note that accessing the `value` executes some code. In this case it logs a message before returning the result. Now ask yourself, how would you implement this in JavaScript? So here’s how IncreasingCounter could be implemented using the familiar ES2015 class syntax. The class installs the `value` getter and an `increment` method on the prototype, but more interestingly, the class has a constructor that creates an instance property `_count` and sets its default value to `0`.

We currently use the underscore prefix to denote that `_count` should not be used directly by the consumers of the class, but that’s just a convention — the privacy is not enforced by the language. Anyway, that’s what this class looks like using the old familiar class syntax. The new public class fields syntax allows us to simplify the class definition. The `_count` property is now nicely declared at the top of the class. We no longer need a constructor just to define some fields. Pretty neat! But, the `_count` property is still a public property in this particular example. We want to prevent direct access to that property. And that’s where private fields come in. So the new private fields syntax is similar to public fields, except you mark the fields as being private by using the `#` symbol. You can think of the hash as being as part of the field name.

This is more than just fancy syntax: private fields are actually private! This means they’re not accessible from outside the class body. When you try, you get a SyntaxError. Class field syntax is especially convenient when dealing with subclasses that introduce additional fields. Consider this `Animal` base class for example. To create a `Cat` subclass that introduces an additional instance property, you’d previously have to call `super()` to run the constructor of the `Animal` base class before creating this property. That’s a lot of boilerplate just to indicate that cats don’t like taking baths! Luckily, the class field syntax removes the need for the whole constructor, including the awkward `super` call. All it takes to add the class field is just that one line. Chrome supports both public and private class fields, and so does Node.

js. And more class features are coming soon! We’re working on adding support for private methods and private getters and setters. Another feature we previewed last year is String#matchAll, which is useful when dealing with regular expressions. It’s common to repeatedly apply the same regular expression on a string to get all the matches. And to some extent this is already possible today by using the String#match method. In this example we find all the words that consists of hexadecimal digits only, and then we log each match. However, this only gives you the substrings that match. Usually you don’t just want the substrings, you also want additional information such as the index of each substring or the capturing groups within each match. And it’s already possible to achieve that by writing your own loop and then keeping track of the match objects yourself, but it’s a little annoying and just not very convenient.

READ  Andra - Sudamericana (feat. Pachanga) (Official Video)

The new String#matchAll API makes this easier than ever before. You can now write a very simple `for-of` loop to get all the match objects. String#matchAll is especially useful for regular expressions with capture groups. It gives you the full information for each individual match, including the capturing groups. The general idea is that you just write a simple `for-of` loop, and String#matchAll takes care of everything else for you. String#matchAll is already supported in Chrome, Firefox, and Node.js. For other browsers, a polyfill is available. Last year we also talked about the numeric separators proposal. Here’s a quick recap. Large numeric literals are difficult for the human eye to parse quickly. Especially when there are lots of repeating digits, like in the first example. To improve readability, a new JavaScript feature enables underscores as separators in numeric literals.

So instead of writing these numbers like this, you can now write them like this, grouping the digits per thousand. Now it’s easier to tell that the first number is in fact a trillion and the second number is in the order of a billion. This small feature helps improve readability for all kinds of numeric literals. Last year, this feature wasn’t supported anywhere yet. The details of the proposal were still being worked out. But since then, the open issues have been resolved, and browsers can now start implementing it. Numeric separators are already shipping in Chrome 75, and transpilers like Babel support them too. Speaking of numbers, we have some news about BigInt as well. Here’s a quick reminder why BigInt is useful. In this example we’re multiplying two numbers. Now, I’m no math genius, but this doesn’t look right to me. Looking at the least significant digits, 9 and 3, we know that the result of the multiplication should end in 7 (because 9 times 3 is 27) but instead the result ends in a bunch of zeros.

That cannot be the correct result! Now let’s try this again with BigInts instead. And this time we do get the correct result. BigInts make it possible to accurately perform large integer calculations in JavaScript. Now what’s new compared to last year is that BigInt now has much better API support within the language. For example, you can now format a BigInt in a locale-aware manner by using the `toLocaleString` method. This now works just like it does for regular numbers. In English for example, it’s common to use commas to group the digits per thousand. In German, periods are used instead. And in French, it’s spaces. If you plan on formatting multiple numbers or BigInts using the same locale it’s more efficient to use the Intl.NumberFormat API. That way you can create a single formatter instance, and then just reuse that as many times as you need it. This API now supports BigInts as well.

And of course, numeric separators work with BigInt literals as well! This means that you can now both use separators to keep your source code readable, and produce strings with correctly formatted numbers using locale-specific separators, all in vanilla JavaScript! I think that’s pretty cool. Last year BigInts had just shipped in Chrome, and they were not available anywhere else yet. But now BigInts are shipping in Firefox Nightly and in Node.js, and an implementation is also underway in Safari. On top of that, there’s now a transpiler and a polyfill story available for BigInts — it’s called JSBI. Now let’s talk about some new exciting features that we’ve been working on since last year. First up is Array#flat and flatMap. Array#flat returns a flattened version of a given array. The array in this example is two levels deep: it contains an array which in turn contains another array.

We can call `flat` to flatten the array by one level. The default depth is 1 but you can pass any number to recursively flatten up to that depth. To keep flattering recursively until the result contains no more nested arrays, we can pass `Infinity`. Here’s another example: we have a `duplicate` function that takes a value and returns an array that contains the value twice. If we apply `duplicate` to each value in an array, we end up with a nested array. You can then call `flat` to flatten the array. But since this pattern is so common in functional programming, there’s now a dedicated `flatMap` method for it. flatMap is a little bit more efficient compared to doing a `map` followed by a `flat` separately. Array#flat and flatMap are already available in Chrome, Firefox, Safari, and Node.js. Another cool new addition to the built-in JavaScript library is Object.

fromEntries. You may have used the Object.entries API before — that one has been around for a while. For each key-value pair in an object, it gives you an array where the first element is the key, and the second element is the value. And this is especially useful in combination with `for-of`, because you can then very elegantly iterate over all the key-value pairs in an object. Unfortunately, there’s no easy way to go from the entries result back to an equivalent object — until now! The new Object.fromEntries API performs the inverse of Object.entries. This makes it really easy to reconstruct an object based on its entries. Now why is this useful? Well, one common use case is transforming objects. You can now do this by iterating over the object’s entries, and then using array methods that you are probably already familiar with. In this example we’re filtering the object to only get keys of length 1, that is, we only want the keys `x` and `y` but not the key `abc`.

We then map over the remaining entries and return an updated key-value pair for each. In this example, we double the value by multiplying it by 2. And the end result is a new object containing only the properties `x` and `y` with the new values. JavaScript also supports maps, which are often a more suitable data structure than regular objects. So in code that you have full control over, you might already be using maps instead of objects. However, as a developer you don’t always get to choose the representation: sometimes the data that you’re operating on comes from an external API or from some library function that gives you an object instead of a map. Object.entries made it easy to convert objects into maps, but the inverse is equally useful! Even if your code is using maps, you might need to serialize your data at some point, for example to turn it into JSON to send an API request, or maybe you need to pass the data to another library that expects an object instead of a map. In these cases you need to create an object based on the map data. Object.

fromEntries makes this trivial. With both Object.entries and Object.fromEntries in the language, you can now really easily convert between maps and objects, both ways. Object.fromEntries is already shipping in Chrome, Firefox, Safari, and in Node.js. For older browser versions, a polyfill is available. Another new feature seems like a small one but it’s a big improvement. Here’s the problem: libraries and polyfills sometimes need access to the global `this` value. To write universal JavaScript that works everywhere regardless of whether you’re in a browser, in Node.js, or in a JavaScript engine shell directly, you need code like this to access the global `this`. In browsers, you can use `window`… except in web workers or service workers, `window` is not available, so you have to check for `self` as well. In Node.

READ  Read2Go video with short download demo

js, you can use `global` instead, but in standalone JavaScript shells, none of these work, so you can try falling back to whatever `this` object is currently available. But outside of browsers, that still won’t work within modules, since they don’t run in the global scope, or in strict mode functions since their `this` is undefined. Also, bundlers often wrap source code, in which case `this` might refer to something else entirely. You cannot rely on this code being run in the global scope in all cases. So even though we’re trying really hard for this code snippet, it still doesn’t support standalone JavaScript engine shells, it doesn’t support modules in all environments, it doesn’t support strict mode functions in all environments, and it might even break in more scenarios when you start bundling it. Getting the global `this` sounds like it would be simple, but it’s actually painful to do so in practice.

And that’s why we have a new `globalThis` feature that gives you easy access to the global `this`, regardless of the environment. `globalThis` is already supported in Chrome, Firefox, Safari, and Node.js. Note that most modern code won’t need access to the global `this` — with JavaScript modules you can decoratively import and export functionality without messing with global state. `globalThis` is still useful for polyfills and other libraries that need global access. Stable sort is another one of those changes that sounds like a small improvement, but it actually has a big impact. Let’s say you have an array of dogs and each dog has a name and a rating. If this sounds like a weird example, you should know that there is a Twitter account that specializes in exactly that (don’t ask). Anyway, the array is pre-sorted alphabetically by name, but what if you want to sort this array by rating so that the highest rated dogs show up first? You would use Array#sort for this, and you would pass in a custom callback that compares the ratings.

And this is the result that you would probably expect. The dogs are now sorted by rating, but within each rating they’re still sorted alphabetically by name — they retain their relative original order. For example Choco and Ghost have the same rating of 14, but Choco appears before Ghost in the sort result, because that’s the order they had in the original array as well. To get this result however, you cannot just use any sorting algorithm — it has to be a so-called stable sort. And for a long time, the JavaScript spec didn’t require sort stability for Array#sort. Instead, it left it up to the implementation and because this behavior wasn’t specified you could also get this sort result, where Ghost now suddenly appears before Choco. In other words, JavaScript developers could not rely on sort stability. And in practice, it was even more confusing than that, because some JavaScript engines would use a stable sort for short arrays but an unstable sort for larger arrays. That was really confusing because developers would test their code, they would see a stable result, but then suddenly get a completely unstable result when the array was slightly bigger.

But there’s some good news: we proposed a spec change that makes Array#sort stable, and it was accepted. All major JavaScript engines now implement a stable array sort. It’s just one less thing for you as a JavaScript developer to worry about. V8 also implements several Intl APIs that provide key locale-specific functionality, such as date formatting, number formatting, plural form selection, and collation in JavaScript. These APIs allow you to localize your websites without having to ship hundreds of kilobytes of locale data to the user. Let’s look at some of the new features we’ve added recently. Modern web applications often use phrases like “yesterday”, “42 seconds ago”, or “in three quarters” instead of full dates or timestamps. The Intl.

RelativeTimeFormat API can generate these phrases for you for each language you support. This code example creates a relative time formatter for the English language. We set the `numeric` option to `'auto'` to tell the formatter it can use phrases like “yesterday” instead of “one day ago”. The formatter recognizes several time units such as seconds, minutes, hours, days, months, quarters, and weeks. We pass it a number and a unit, and it returns a string that represents the relative time. And this doesn’t just work for English, but for other languages like Tamil as well. Previously developers had no choice but to implement such APIs themselves. One problem with implementing a localized relative time formatter is that you need a list of customary words or phrases such as “yesterday” or “last quarter” for each language you support.

The Unicode CLDR provides this data, but you use it in JavaScript, it has to be shipped alongside other library code. This unfortunately increases the bundle size for such libraries, which negatively impacts load time, parse/compile time, and memory consumption. With the new Intl.RelativeTimeFormat API, the browser ships the data, so you get the functionality without paying the cost. The RelativeTimeFormat API is available in Chrome, Firefox, and Node.js. Modern web applications often use lists consisting of dynamic data, and they require locale-specific formatting of such lists. For example a photo viewer app might display a message like “this photo includes person A, B, and C”. The Intl.ListFormat API can help you format such strings for any given language using the locale-specific list conventions. A text-based game might have a different kind of list: it could say something like “choose your favorite hero: X, Y, or Z”.

The ListFormat API supports that too, using the `disjunction` type. Because each language has different list formatting conventions and words, implementing a localized list formatter in JavaScript is non-trivial. Not only does this require a list of all the words such as “and” or “or” for each language you want to support — in addition you need to encode the exact formatting conventions for all those languages. The Intl.ListFormat API takes care of all of that for you. The ListFormat proposal is available in Chrome and Node.js. For other browsers, a polyfill is available. It’s common for websites to display date intervals or date ranges to show the span of an event, such as a hotel reservation, the billing period of a service, or I don’t know, a big tech developer festival in Mountain View. The `formatRange` method provides a convenient way of formatting ranges in a locale-specific manner. In the above example, we create two dates and print the date range using `DateTimeFormat`. Intl.DateTimeFormat is an existing API that has been shipping in all browsers for a while.

One way to print the date range is to use the regular locale-unaware string formatting: you format the start date, you format the end date, and piece them together into a string. Here the second date’s month and year calendar fields are redundant — only the day provides new information. So instead, with the new `formatRange` method, we can display all the relevant fields and none of the repeating ones. The `formatRange` method is available behind a flag in Chrome, and we plan to ship it very soon. In the previous examples, you may have noticed the locale ID that we passed to the various Intl constructors, such as `'en'` for English. Intl.Locale offers a powerful mechanism to deal with such locales. It enables easily extracting locale-specific preferences, such as not only the language, but also the calendar, the numbering system, the hour cycle, the region, and so on. The Intl.Locale proposal is now available in Chrome and Node.

READ  Garmin Descent Mk1: Using Garmin Connect Mobile

js. You can use a polyfill for other browsers. If you’ve used promises before, you might already be familiar with the lovely async/await syntax. Instead of chaining promise callbacks using `then`, you can nicely `await` the result of a promise. This syntax has been around for a while. However, `await` can only occur within an async function. There are use cases for wanting to use `await` at the top level, but currently this isn’t possible. One workaround is taking all your top- level code and wrapping it up in an async function that you then call. Another approach is to wrap your top-level code in an immediately-invoked async function expression. But a new proposal enables the use of `await` at the top-level, removing the need for these workarounds. The Chrome DevTools Console already wraps your input in an async function behind the scenes if the input contains `await`, so it looks like top-level `await` already works in the console. But that’s not because we implement the proposal — we don’t! The exact details of the top-level `await` proposal are still being worked out, and as such it’s still too early to implement it. It’s not currently supported everywhere.

Now that we’re on the subject of promises and async code, let’s talk about promise APIs. Currently there are two promise combinators in JavaScript: the static methods `all` and `race`. Promise.all lets you know when either all input promises have fulfilled, or when one of them rejects. Promise.race lets you know as soon as one of the input promises settles, which means it either fulfills or rejects. These are independently useful, and have different use cases. Imagine the user clicks a button and you want to load some stylesheets you can render a completely new UI. This program kicks off an HTTP request for each stylesheet in parallel. Then you only want to start rendering the new UI after all the requests succeeded, but if something goes wrong you want to instead display an error message as soon as possible, without waiting for any other work to finish.

In such a case, you could use Promise.all: you want to know when all promises are fulfilled, or as soon as one of them rejects. Promise.race is useful if you want to run multiple promises and either do something with the first successful result that comes in, in case one of the promises fulfills, or do something as soon as one of the promise rejects. That is: if one of the promises rejects, you want to preserve that rejection, and treat that error case separately. Here, we do exactly that: we kick off a computationally expensive task that might take a long time, but we race it against a promise that rejects after two seconds. Depending on the first promise to fulfill or reject, we either render the computer result, or the error message in two separate code paths. There was a top-level await in that example, by the way.

So those are the existing promise combinators: `all`, and `race`. Two new proposals are currently making their way through the standardization process: Promise.allSettled, and Promise.any. With these additions there will be a total of four promise combinators in JavaScript, each enabling different use cases. Promise.allSettled gives you a signal when all of the input promises are settled, and that means they’re either fulfilled or rejected. This is useful in those cases where you don’t really care about the state of the promise — you just want to know when the work is done, regardless of whether it was successful. For example, you can kick off a series of independent API calls and then use Promise.allSettled to make sure that they’re all completed before doing something else, like removing a loading spinner. Promise.any gives you a signal as soon as one of the promises fulfills. this is similar to Promise.race, except `any` doesn’t reject early when one of the promises rejects. This code example checks which endpoint responds the fastest, and then logs it.

Only if all of the requests fail, do we end up in the `catch` block where we can then handle the errors. Promise.any is still in the early stages of being standardized, and it’s not supported anywhere yet. Promise.allSettled on the other hand is already available in Chrome 76 and in Firefox Nightly. For other browsers, a polyfill is available. Next up are weak references. Generally references to objects are strongly held in JavaScript, meaning that as long as you have a reference to an object, that object won’t be garbage-collected. Currently WeakMaps and WeakSets are the only way to weakly reference an object. Adding an object to a WeakMap or a WeakSet doesn’t prevent it from being garbage-collected. Weak references are a more advanced API that provide a window into the lifetime of an object. So here we have a `getImage` function that takes a name and performs some expensive operation to generate another object, like a binary blob of image data. To improve performance, we store the image in a cache.

Now we don’t have to perform the expensive operation again for the same name. But there’s a problem: maps hold on to their keys and values strongly, so the image names and data can never be garbage-collected so this steadily increases memory and causes a memory leak. Note that using a WeakMap would not help here, as WeakMaps don’t support strings as keys. A new proposal makes it possible to solve the memory leak by creating a weak reference to the image and storing that in the cache instead of the image itself, so when the garbage collector realizes that it’s running out of memory, it can clean up some of the images. But there’s still a problem here: the map still holds on to the name strings forever, because those are the keys in the cache. Ideally those strings would be removed as well. The WeakRefs proposal has a solution for that as well. With the new `finalizationGroup` API, we can register a callback to run when the garbage collector zaps a registered object. So here, we register a callback to remove the keys from the cache when the image objects are garbage- collected.

Our final implementation looks like this: given an image name, we look up its corresponding weak reference in the cache. If the weak reference still points to something, we can return the cached image data. If there’s no cache entry yet, or if the cached data has already been garbage-collected, we compute the image data, create a new weak reference to it, store the image name and weak reference in the cache, register a finalizer that removes the image name from the cache once the image data is garbage- collected, and return the image. The WeakRefs proposal is still going through the standardization process. We have an experimental implementation in V8 behind a flag already, but we won’t ship it until the proposal is finished. We’ve talked about lots of amazing JavaScript features today with for varying degrees of support.

We’re very excited to see how much the JavaScript landscape has evolved over the past year, and we look forward to increased support and adoption of these new features across the entire ecosystem. And who knows maybe next year, we’ll be back here at Google I/O announcing that all these cutting-edge features are now supported everywhere. Wouldn’t that be nice! Fingers crossed. If you have any feedback at all on this session, or have any questions about modern JavaScript, then don’t hesitate to let us know on Twitter. Thanks for listening and enjoy the rest of I/O. Thank you!.