I just realized that this is going to be the very first blog post of 2018 that I write myself - versus bugging someone else to write a blog post. It’s been quite a busy year for me already, plus I was sick a lot, and so was my family. Anyways, here’s something I’ve been meaning to send out for a while. And while the title mentions React explicitly, this is by no means limited to React, but probably affects a lot of code out there, including a lot of Node.js code bases, where this impact is even more severe.

Following up on my talk “A Tale of TurboFan” (slides) at JS Kongress, I wanted to give some additional context on how TurboFan, V8’s optimizing compiler, works and how V8 turns your JavaScript into highly-optimized machine code. For the talk I had to be brief and leave out several details. So I’ll use this opportunity to fill the gaps, especially how V8 collects and uses the profiling information to perform speculative optimizations.

The last months have been a hectic time for me. I was hosting my first intern Juliana Franco at Google working on the Deoptimizer during her internship on lazyiness. Then I was diagnosed with articular gout and almost couldn’t walk for a week. And we finally moved into our new house with a lot of help from my awesome colleagues on the V8 team. On the Node.js front, I became the tech lead of Node performance in the V8 team, joined the Node.js benchmarking working group, and I am now officially a Node.js collaborator. But I also had some time to close gaps in V8 performance now that Ignition and TurboFan finally launched everywhere.

When we launched Ignition and TurboFan earlier this year, we did so knowing it wouldn’t be overall positive, but that we’ll see performance regressions in several cases which we need to address in later releases. Most of these regressions were just a couple percent here and there, with a few significant regressions. Among the most serious regressions was the 4-5x performance hit on for..in peak performance, which was also highlighted in the Get ready: A new V8 is coming, Node.js performance is changing blog post in the summer, and led to some complaints in the community.

After all the recent drama in the Node.js community, which has been on-going for a long time actually, I was almost tempted to believe that a lot of this is really because problems deeply rooted within the american society leak into the (open source) tech community. And to a certain extent that’s probably true. But only to a certain extent. There’s more about the broader tech community that makes it an extremely hostile environment, without being influenced (directly) by the american society. A lot more than that.

Yesterday I was pointed to webpack#5600, which outlines how webpack v3 generates code for calls to imported functions, i.e. code like this

In this article (originally published on ponyfoo.com), we’ll discuss how Object.prototype.toString() performs in the V8 engine, why it’s important, how it changed with the introduction of ES2015 symbols, and how the baseline performance can be improved by up to 6x (based on findings from Mozilla engineers).

In the past couple of days there’s been lots of discussions and ramblings around the so-called Google Manifesto, and what it means for the tech industry, and maybe the world as a whole. I strongly and wholeheartedly disagree with what’s being said in that document, and I realize that not stating this publicly doesn’t help anyone! I don’t believe that inherent psychological or biological differences may explain why we don’t see equal representation of women in tech and leadership.

With the addition of Object.freeze and Object.seal in ECMAScript 5.1, there’s a way for developers to prevent various kinds of mutations to objects. For example, Object.freeze can be used to make an object essentially immutable:

The ECMAScript 2015 Language Specification introduced collections into JavaScript, specifically Maps and Sets (among others like WeakMaps and WeakSets). These collections are iterable via the newly introduced iteration protocol, which means you can use them together with language constructs like for-of and spreads. For example for Sets