The most anticipated chrome release V8, hits its long-awaited v8.0 and will be shipping with chrome 80 release in February.

The v8.0 release with some new features — optional chaining, Nullish coalescing, faster higher-order builtins and 40% less memory use thanks to pointer compression, these features and changes will improve the performance and code productivity. Let’s see them one by one — Optional chaining (?.)

When accessing the nested object properties we need to do a manual check for properties existence, i.e., if they are nullish ( null or undefined ) or not. // Error prone-version, could throw. const nameLength = db.user.name.length; TypeError: Cannot read property 'length' of undefined, if user is nullish If they are nullish and we try to access it, JavaScript would throw an error: TypeError: Cannot read property 'property name' of undefined . In many cases where an object is heavily nested, the if condition or ternary operator check becomes verbose and has the unwanted consequence of all truth values instead of only non-nullish values like below — // Less error-prone, but harder to read. let nameLength; if (db && db.user && db.user.name) nameLength = db.user.name.length; // OR nameLength = (db ? (db.user ? (db.user.name ? db.user.name.length : undefined) : undefined) : undefined); Optional chaining ( ?. ) help us with the above issue. It helps us write less code and get a robust chain of property accesses that are easy to read and check if intermediate values are nullish. If it is, then the entire expression evaluates to undefined . const nameLength = db?.user?.name?.length

We can use optional chaining in the following 3 forms. object?.property — used to access a static property as we saw above. object?.[expression] — used to access a dynamic property or an array item

const array = null; array?.[0]; // => undefined

3. object?.([arg1, [arg2, ...]]) — executes an object method

const object = null; object?.method('Some value'); // => undefined

These forms can be combined to create a long optional chain if you need it: const value = object.maybeUndefinedProp?.maybeNull()?.[propName]; Nullish coalescing (??)

It’s a new short circuit operator meant to handle default values. Currently, default values are sometimes handled with the logical || for falsy values and && operator for truthy, such as in the following example. function test(props) { const res = props.isTrue || true; // return true if props.isTrue is set to false also, // whereas the required result should be the value of props.isTrue } With the nullish coalescing operator, a ?? b evaluates to b when a is nullish ( null or undefined ), and otherwise evaluates to a . So in the above case — function test(props) { const res = props.isTrue ?? true; // return true only when props.isTrue is nullish or true // In case of false it evalutes to false }

The nullish coalescing operator and optional chaining are companion features and work well together. The example may be further amended to handle the case when no props argument is passed in. function test(props) { const enable = props?.isTrue ?? true; // … }

Faster higher-order builtins To understand the above performance optimization, we should know about TurboFan in V8. So let’s quickly see what it is. TurboFan is a JIT compiler architect as a multi-layered translation and optimization pipeline in V8 that translates and optimizes the code to progressively lower forms until a better quality machine code is generated. It uses a concept called the sea of node. const charCodeAt = Function.prototype.apply.bind(String.prototype.charCodeAt); // before charCodeAt(string, 8); // a lot slower string.charCodeAt(8); // a lot faster // After optimization - same performance charCodeAt(string, 8); string.charCodeAt(8); Till now, the call to charCodeAt was completely opaque to TurboFan, which led to the generation of a generic call to a user-defined function. With this new change, we are now able to recognize the calling of built-in String.prototype.charCodeAt function and are thus able to trigger all the further optimizations that TurboFan has in stock to improve calls to builtins, which leads to the same performance as the direct usage of builtin. Pointer compression The awesome V8 team, upon inspection of the heap, discovered that the tagged values (which represent pointers or small integers) occupy the majority of the heap! Upon further inspection, they found that the tagged values are as big as the system pointer: they are 32 bits wide for 32-bit architectures, and 64 bits in 64-bit architectures. Then, when comparing the 32-bit version with the 64-bit one, we are using twice as much heap memory for every tagged value. So, to solve above, they stored only the unique lower bits into the heap, and then use them to generate top bits for 64 bits architectures thus saving precious memory resources. The above solution improved the performance on real websites in the time spent in V8, and in its garbage collector!