crafting (and) JavaScript

Hermes Analysis

I have been digging a little bit into Hermes (a mobile first JS engine) focused on React Native. Since I shared most of it on twitter, I want to "copy" the content here to persist it for me, I know I am coming back to this eventually and this way I get up to speed faster.

Object vs. Map

I think I have an idea of how a bytecode based VM works, so I was curious to dig a little deeper. And I am going to use an example that I remember @Benedikt told me about once, where a v8 is struggling with. It is the usage of the very overloaded and powerful object literal in JavaScript, while one actually is "just" doing the work that a JavaScript Map is way more ideal for.

Besides the speed gain a VM might give you when using a Map, I also like the explicitness in code. A piece of code that reads map.has('key') is way more explicit than any way you can write this with an object. And you also know it does ONLY that.

So I thought I would like to see what kinda code hermes produces when I use an object literal vs. a Map. Find my annotated tweets below.

Hermes bytecode for Map code
Hermes bytecode for Map code
Hermes bytecode for object code
Hermes bytecode for object code

I have generated and screenshotted the images in the hermes playground.

With uxebu we used to build a flash parser and a VM for ActionScript 3 bytecode, so I think I have seen some alike stuff being developed and I can't get rid of the feeling that there is a certian type of programmer, that likes to write this code :).

Besides the style of code, it seems that I need to dive even deeper. Just looking at the bytecode is not very conclusive and reveals a different picture to what I expected. The bytecode for the Map-version is longer. So I guess the VM code under the hood might reveal some more insights.

Besides all the analysis and the time spent, I can't say I understand all of it. But I get some feeling for hermes. I am wondering if there are more optimziation possible. Especially given, that hermes dismisses some JS features already. There might be more possible to get to a smaller but still very usable JS engine, that might has some good tradeoffs for an even bigger resource consumption gain.

I keep look out.