ES11 - The JS show - Part 2

Photo by Tiago Alves on Unsplash

How far JS has grown from its initial date which flows back to 1997, with a different name of LiveScript, been abused, cursed, and made fun of by developers of the age. That was acceptable, because, JS at that time was a little bit bad.

But now it has grown to a notable position. Been used by most developers, ahead of Java, Python, and moreover been used in all stack of applications like front-end, back-end, cross-platform desktop app, hybrid mobile apps.

Its all because, down the years, it has been standardized by ECMA(European Computer Manufacturing Association), and from then, they've been providing a set of rules, and standards to be followed by browsers to make the life of developers easy. Because before this standardization, each browser at that time, primarily Netscape, Internet Explorer were all having their own set of rules for bringing more interactive content into the webpage displayed in their browser. So developers had to write code for more than one time for the same functionality. But ECMA was a lifesaver. From then, they've been releasing and making JS a standard language. So this year is for ES11 or ECMA2020, and the rules have been standardized and all major browsers will have these features within this year.
Let's dig into those features here.

BigInt

Next to string, int, boolean, undefined, null, symbol, here comes the 7th and the most expected primitive type BigInt. Previously, JS accepts only a range of numbers up to 2^53, which is denoted as Number.MAX_SAFE_INTEGER in JS.(~ 9 quadrillions). This range is because JS uses a double-precision floating-point number(64 bits). If any number crosses this range, it will lose its precision. With increased numerical computation, our people thought there is a need for a much bigger number, for good precision. Hence this BigInt.


But, this BigInt has its own disadvantages. It has some similarities with Number, but the methods accessible by Number in Math object are not accessible by BigInt. It can be coerced to a Number to access the functions, but it may lose its precision. And also normal float precision cannot be achieved in BigInt.

String.protoype.matchAll

JavaScript regular expression had already a way to capture groups with the method match(). But it doesn't return other named properties like the index, input, groups with a global flag. When we need these named properties, we must remove the g flag, but with this removed, we cannot ensure whether any other matched group is present inside the string in the further index or not. Solving this problem is the main objective of matchAll().

No big difference between those two. Although one catch is that, the results from the matchAll will be a RegExpStringIterator object. Hence to obtain the results, we must spread the output. And matchAll must be only used in global flagged regular expression syntax.

So an additional tip here: What do the named properties from the result of the regex contain?
  • result: The text matched with the given pattern.
  • index: The index at which the match occurred with the original string.
  • input: The string against which the regular expression has run.
  • groups: The name of the group to which the matched string belongs. This will be undefined unless you give the regex generator a name to the group. For example:

 

Promise.allSettled

This returns a Promise that gets settled only when all the given promise is settled. I say that again. All the given promise. Here is the catch between Promise.all and Promise.allSettled. The former returns a promise which gets fulfilled at any of the given cases
  1. When at least one promise gets rejected.
  2. When all the promise gets resolved.
On the other hand, the promise of the latter gets resolved only when all the promises are settled. Settled can be either resolved or rejected, that doesn't matter. So, if you need to wait for at least for a single promise to resolve, even if another promise has been rejected, it's good to go for Promise.allSettled.

 Dynamic import

Imports previously cannot by dynamic. That is it cannot load a module based on a condition, based on user input, and in other dynamic cases. But on interpreting the core functionality of import, we can understand that imports return a Promise, which upon resolving gives us the requested module.


With these, now development could reduce the overhead of module bundlers like Webpack, which has been used mainly for dynamic import, but for sure it has been also used for other development and performance reasons like bundling, code splitting, etc.

Standardized global object

This has been around even from ES10 but gets to be introduced in all browsers in given standards only from ES11, and it is a new and very much appreciated concept. Before this standardized global object, if a developer finds the same set of code and logic works in different environments say, a web worker or a node or the web. The dev can't simply use that code because the global object in each environment is different.
  • self in the web worker
  • global in the node
  • window, self or frames in web
So resolving this is the main concept in globalThis, which dynamically gets mapped to the respective global object in each environment, in which the code runs.

Nullish coalescing Operator

Nullish operator is useful in the context where you need to catch only the null or undefined values. Because, till now we might be using the logical OR operator to do this. But the glitch here is, JS has a bunch of falsy values that might confuse us while getting the logic done. So this Nullish operator(??) moves the control to its right side only if the left side operands are either undefined or null.

 

Optional Chaining

The optional chaining operator ?. permits reading the value of a property located deep within a chain of connected objects say, an implementation of a file hierarchy, without worrying whether the value for that key exists or not, instead of using the short-circuiting the control with logical and operator every time you check the value is defined or not before fetching the child's value from the key.


Remember the Optional chaining(?.) operator functions similarly to the (.) chaining operator, except that instead of throwing an error if the reference is null or undefined, the expression gets short-circuited along with a return value of undefined.

So, if you come this far, I hope you would be happy knowing the 7 new powerful functions of modern JavaScript. Yes, there are still many features, but I wish to stop here with the most significant features been elaborated. JS has evolved and still evolving. It shows a good healthy growth which is good for the development side and developer side.

Feel free to ping me or comment below if you find anything irrelevant, annoying, or even if you wish to appreciate it.

Written By,
Balaji SV

Comments

  1. Need to work on your grammar, please proof read it before hand

    ReplyDelete
    Replies
    1. Thanks for the feedback. Will take care in that.

      Delete
  2. JS has come a long way and is evolving constantly as well. Great post

    ReplyDelete
    Replies
    1. Yeah. That isn't great! And, Thanks for the Kudos.

      Delete

Post a Comment