5 ms·

I don't understand what the goal is here. Honest question, not a criticism. Can someone please explain. Is the intention to have node work on multiple Javascrip

I don't understand what the goal is here. Honest question, not a criticism. Can someone please explain. Is the intention to have node work on multiple Javascript engines like spidermonkey? I can see why Chakra developers could want this but as a developer using node I don't see how I would benefit.

rom1504 11y ago
For example the chakra engine has a better coverage of es6 than v8. see edge score there https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/
- s3th 11y ago
  We're working on updating Kangax, but V8 now has 92% ES6 coverage in Chrome Canary (on track for shipping in Chrome M49)! Disclaimer: I work on V8
  - sonnyp 11y ago
    How so? I just loaded es6 kangax table in Canary "Version 49.0.2566.0 canary (64-bit)" and it reports 62% for current browser. EDIT: 92% reported for "Version 50.0.2626.0 canary (64-bit)" nice job!
johannes1234321 11y ago
As long as they stay compatible to each other it might create competition between engines, leading to innovation and improvement in both.
inglor 11y ago
I think the goal is to have Node applications in the windows store. Having a v8 dependency there would be a big problem with embedded devices. Microsoft is trying to get into the whole IoT hype. This would help them a lot. It also means they can write servers on Azure that don't need to be able to run V8. Mostly windows store apps though.
- pori 11y ago
  This will certainly help with the development of .NET development. My team has been burned a few times by Windows specific compilation errors. Hopefully this will reduce the necessity to have a non-Windows machine around. That aspect has made things tedious for us.
dsp1234 11y ago
Competition in the space leads to better engines. I put a link in another comment to last week's discussion on the topic. But my main concern is developers writing code that tries to bend around then V8 implementation, even if it's not required by the language. One great example from that thread was about try/catch: "For example, a try/catch in V8 triggers deoptimization for the entire function it's in, while it might not in other engines. So this leads to many developers avoiding try/catch in performance critical code. This ends up with them avoiding it in general usage, which means that now "avoiding try/catch" is considered a general purpose performance tip in javascript, even though it might only apply to one engine (and the v8 team has expressed interest in trying to stop that deopt)"[0] "It is a good example actually. Chakra does fully optimize functions with try/catch. Caveat: we don't optimize try/finally yet... Disclaimer: I work for MSFT on Chakra."[1] "try/catch has pretty much no runtime overhead in SpiderMonkey unless an actual exception is thrown."[2] [0] - https://news.ycombinator.com/item?id=10896729 https://news.ycombinator.com/item?id=10896729 [1] - https://news.ycombinator.com/item?id=10896971 https://news.ycombinator.com/item?id=10896971 [2] - https://news.ycombinator.com/item?id=10897851 https://news.ycombinator.com/item?id=10897851
- deleted 11y ago
  [deleted]
- Klathmon 11y ago
  And that was just the first thing off the top of my head, there are tons of other little performance things that many people consider a "JavaScript thing" instead of a "V8 thing"
  - Touche 11y ago
    Does it matter? If V8 deoptimizes code with try/catch, then I as a developer need to account for that.
    - kuschku 11y ago
      Why? Most users aren’t on V8.
cybice 11y ago
Node v8 memory limit is the big problem for me http://stackoverflow.com/questions/7193959/memory-limit-in-node-js-and-chrome-v8 http://stackoverflow.com/questions/7193959/memory-limit-in-n... Sometimes I need to move data outside heap memory - Buffers etc. Looks like chakra have no such problem.
- krisdol 11y ago
  Isn't it just --max-old-space-size=whateveryouwant? The default of 512mb seems pretty reasonable.

rom1504 11y ago

For example the chakra engine has a better coverage of es6 than v8. see edge score there https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/

s3th 11y ago
We're working on updating Kangax, but V8 now has 92% ES6 coverage in Chrome Canary (on track for shipping in Chrome M49)! Disclaimer: I work on V8
- sonnyp 11y ago
  How so? I just loaded es6 kangax table in Canary "Version 49.0.2566.0 canary (64-bit)" and it reports 62% for current browser. EDIT: 92% reported for "Version 50.0.2626.0 canary (64-bit)" nice job!

johannes1234321 11y ago

As long as they stay compatible to each other it might create competition between engines, leading to innovation and improvement in both.

inglor 11y ago

I think the goal is to have Node applications in the windows store. Having a v8 dependency there would be a big problem with embedded devices. Microsoft is trying to get into the whole IoT hype. This would help them a lot. It also means they can write servers on Azure that don't need to be able to run V8. Mostly windows store apps though.

pori 11y ago
This will certainly help with the development of .NET development. My team has been burned a few times by Windows specific compilation errors. Hopefully this will reduce the necessity to have a non-Windows machine around. That aspect has made things tedious for us.

dsp1234 11y ago

Competition in the space leads to better engines. I put a link in another comment to last week's discussion on the topic. But my main concern is developers writing code that tries to bend around then V8 implementation, even if it's not required by the language. One great example from that thread was about try/catch: "For example, a try/catch in V8 triggers deoptimization for the entire function it's in, while it might not in other engines. So this leads to many developers avoiding try/catch in performance critical code. This ends up with them avoiding it in general usage, which means that now "avoiding try/catch" is considered a general purpose performance tip in javascript, even though it might only apply to one engine (and the v8 team has expressed interest in trying to stop that deopt)"[0] "It is a good example actually. Chakra does fully optimize functions with try/catch. Caveat: we don't optimize try/finally yet... Disclaimer: I work for MSFT on Chakra."[1] "try/catch has pretty much no runtime overhead in SpiderMonkey unless an actual exception is thrown."[2] [0] - https://news.ycombinator.com/item?id=10896729 https://news.ycombinator.com/item?id=10896729 [1] - https://news.ycombinator.com/item?id=10896971 https://news.ycombinator.com/item?id=10896971 [2] - https://news.ycombinator.com/item?id=10897851 https://news.ycombinator.com/item?id=10897851

deleted 11y ago
[deleted]
Klathmon 11y ago
And that was just the first thing off the top of my head, there are tons of other little performance things that many people consider a "JavaScript thing" instead of a "V8 thing"
- Touche 11y ago
  Does it matter? If V8 deoptimizes code with try/catch, then I as a developer need to account for that.
  - kuschku 11y ago
    Why? Most users aren’t on V8.

cybice 11y ago

Node v8 memory limit is the big problem for me http://stackoverflow.com/questions/7193959/memory-limit-in-node-js-and-chrome-v8 http://stackoverflow.com/questions/7193959/memory-limit-in-n... Sometimes I need to move data outside heap memory - Buffers etc. Looks like chakra have no such problem.

krisdol 11y ago
Isn't it just --max-old-space-size=whateveryouwant? The default of 512mb seems pretty reasonable.