5 ms·

JavaScript – The monkeys in 2013

141 points by quenlinlom 13y ago

ZeroGravitas 13y ago
Those graphs should really start at 0, the improvements (as good as they are) are needlessly exaggerated.
- saosebastiao 13y ago
  I agree, but it is rarely the fault of the person presenting them. Unfortunately most "easy to use" graphing technologies (with Excel being the worst offender) take the most deceptive graphing techniques and make them defaults.
  - brandonbloom 13y ago
    > most deceptive graphing techniques They are deceptive because they exaggerate features of the data in order to improve perception of configuration changes. If every graph started at zero, many datasets would look like flat lines... not a great user experience when graphing.
  - deleted 13y ago
    [deleted]
  - TwoBit 13y ago
    Of course it's the fault of the person presenting them. If they are competent enough to understand what they are presenting, they are competent enough to adjust a y axis baseline.
- ville 13y ago
  One could argue that it's not so bad in this case, since the variable is not an absolute value but just a "score".
  - rictic 13y ago
    I believe that they are absolute values though. IIUC, a browser doubling their score on one of these benchmarks is an approximation for being twice as fast at performing the benchmarked functionality. Firefox's improvement was enormous in 2013, but these graphs make their improvement seem (eyeballing it) about 5 to 10x more than it was.
- nnethercote 13y ago
  Good news! Hannes updated the graphs to fix this.
leephillips 13y ago
Dang, I thought my favorite band was getting back together.
- sirduncan 13y ago
  I knew I couldn't have been the only one who thought that after reading the title.
pjmlp 13y ago
Insteresting to see the VM to go into the meta-circular direction with code being written directly in JavaScript.
ii 13y ago
We really need a monkey version of nodejs and node-webkit. Mozilla's engine looks more solid for universal use, there are more interesting features and experimentation. The only problem is that it's harder to embed in another software, but it looks that it is changing and I really hope it will change.
- camus2 13y ago
  > Mozilla's engine looks more solid for universal use > The only problem is that it's harder to embed in another software Well , you cant have it both ways. There was spideymonkey-node a few years ago , but Mozilla doesnt seem interested in maintaining that. In fact there are quite a few mozilla abandonned projects,(XULRunner...) that could have competed with node-webkit.
  - BrendanEich 13y ago
    You are thinking of SpiderNode, and/or NodeMonkey. Other than the principals leaving Mozilla for Facebook, this work was superseded by Tim Caswell's Luvmonkey: https://github.com/creationix/luvmonkey https://github.com/creationix/luvmonkey Turns out Node is really well factored, so emulating the V8 API on top of SpiderMonkey, especially back in 2011 as the Spider-Node-Monkey project tried, is harder. It's the "long way 'round". Binding libuv to any engine that implements ES5+ is easier and gives Node interop. As for XULRunner, sorry -- no leverage. If you see some, make it a business and show us up.
    - oscargrouch 13y ago
      >Turns out Node is really well factored, so emulating the V8 API on top of SpiderMonkey, especially back in 2011 as the Spider-Node-Monkey project tried, is harder. It's the "long way 'round". Also: (i know i will get downvoted for saying that) but nodejs code is poorly written[0].. leaking v8 internals all over the place.. so to plug another js engine backend into it would be a very good exercise in tour-de-force [0] - In a enginnering perspective, not pragmatic : cause nodejs does whats supposed to pretty well :)
    - 13y ago
badman_ting 13y ago
Kudos. And I wish you all would reconsider your nomenclature.

141 points by quenlinlom 13y ago

ZeroGravitas 13y ago

Those graphs should really start at 0, the improvements (as good as they are) are needlessly exaggerated.

saosebastiao 13y ago
I agree, but it is rarely the fault of the person presenting them. Unfortunately most "easy to use" graphing technologies (with Excel being the worst offender) take the most deceptive graphing techniques and make them defaults.
- brandonbloom 13y ago
  > most deceptive graphing techniques They are deceptive because they exaggerate features of the data in order to improve perception of configuration changes. If every graph started at zero, many datasets would look like flat lines... not a great user experience when graphing.
- deleted 13y ago
  [deleted]
- TwoBit 13y ago
  Of course it's the fault of the person presenting them. If they are competent enough to understand what they are presenting, they are competent enough to adjust a y axis baseline.
ville 13y ago
One could argue that it's not so bad in this case, since the variable is not an absolute value but just a "score".
- rictic 13y ago
  I believe that they are absolute values though. IIUC, a browser doubling their score on one of these benchmarks is an approximation for being twice as fast at performing the benchmarked functionality. Firefox's improvement was enormous in 2013, but these graphs make their improvement seem (eyeballing it) about 5 to 10x more than it was.
nnethercote 13y ago
Good news! Hannes updated the graphs to fix this.

leephillips 13y ago

Dang, I thought my favorite band was getting back together.

sirduncan 13y ago
I knew I couldn't have been the only one who thought that after reading the title.

pjmlp 13y ago

Insteresting to see the VM to go into the meta-circular direction with code being written directly in JavaScript.

ii 13y ago

We really need a monkey version of nodejs and node-webkit. Mozilla's engine looks more solid for universal use, there are more interesting features and experimentation. The only problem is that it's harder to embed in another software, but it looks that it is changing and I really hope it will change.

camus2 13y ago
> Mozilla's engine looks more solid for universal use > The only problem is that it's harder to embed in another software Well , you cant have it both ways. There was spideymonkey-node a few years ago , but Mozilla doesnt seem interested in maintaining that. In fact there are quite a few mozilla abandonned projects,(XULRunner...) that could have competed with node-webkit.
- BrendanEich 13y ago
  You are thinking of SpiderNode, and/or NodeMonkey. Other than the principals leaving Mozilla for Facebook, this work was superseded by Tim Caswell's Luvmonkey: https://github.com/creationix/luvmonkey https://github.com/creationix/luvmonkey Turns out Node is really well factored, so emulating the V8 API on top of SpiderMonkey, especially back in 2011 as the Spider-Node-Monkey project tried, is harder. It's the "long way 'round". Binding libuv to any engine that implements ES5+ is easier and gives Node interop. As for XULRunner, sorry -- no leverage. If you see some, make it a business and show us up.
  - oscargrouch 13y ago
    >Turns out Node is really well factored, so emulating the V8 API on top of SpiderMonkey, especially back in 2011 as the Spider-Node-Monkey project tried, is harder. It's the "long way 'round". Also: (i know i will get downvoted for saying that) but nodejs code is poorly written[0].. leaking v8 internals all over the place.. so to plug another js engine backend into it would be a very good exercise in tour-de-force [0] - In a enginnering perspective, not pragmatic : cause nodejs does whats supposed to pretty well :)
  - 13y ago

badman_ting 13y ago

Kudos. And I wish you all would reconsider your nomenclature.