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.
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.
Following up on part one of this series last week, here's another (hopefully interesting) episode about optimization patterns for JavaScript (based on my background working on the V8 engine for more than four years). This week we're going to look into an optimization called Function Context Specialization, that we introduced to V8 with TurboFan (other engines like JavaScriptCore implement similar optimizations). The name is a bit misleading. What it essentially does is to allow TurboFan to constant-fold certain values when generating optimized code, and it does that by specializing the generated machine code for a function to its surrounding context (which is V8 speak for the runtime representation of scope).
It's been a while since my last blog post, mostly because I didn't really have the time or the energy to sit down and write up all the stuff that I wanted to write about. Part of it was because I have been pretty busy with the Ignition and TurboFan launch in Chrome 59, which fortunately was a huge success thus far. But also partly because I took some time off with my family. And last but not least I went to JSConf EU and Web Rebels, and at the time of this writing I'm at enterJS, procastinating on doing the final tweaking for my talk.
I'm again running late for the March Edition, so that might turn into some kind of pattern. The last month was pretty exciting: We finally turned on Ignition and TurboFan by default for Chrome M59. It took two attempts, but it seems to stick now. Overall it went surprisingly well, despite the complexity and impact of this change; as my site director used to put it: "Changing from Crankshaft to TurboFan in Chrome was like changing the engine of a F1 car at 250 km/h."