4 ms·

"The Node.js Foundation would be wise to migrate to Chakra" Actually it would be extremely unwise, and here's why: "In order to use Microsoft's fork, you need

by krisdol 11y ago

"The Node.js Foundation would be wise to migrate to Chakra" Actually it would be extremely unwise, and here's why: "In order to use Microsoft's fork, you need a Windows 10 machine with the November update" When Chakra is open-source and cross-platform, its differentiating "killer" features will be merged into node's V8. SpiderMonkey has been beating V8 in ES2015 adoption and V8s own benchmarks, but even that wasn't enough for it to become the new node.js runtime. We have yet to see if what Microsoft brings to the table is more convincing.

deleted 11y ago
[deleted]
brazzledazzle 11y ago
>"In order to use Microsoft's fork, you need a Windows 10 machine with the November update" That does take the wind out of the post's sails a bit.
cwyers 11y ago
Chakra is being opensourced this month. I really doubt that V8 will be able to just pull features from it as easily as you suggest here.
- yuhong 11y ago
  I was hoping for a open source Windows x64 ABI compliant JavaScript JIT for a while now.
taspeotis 11y ago
https://blogs.windows.com/msedgedev/2015/12/05/open-source-chakra-core/ https://blogs.windows.com/msedgedev/2015/12/05/open-source-c... "...we are committed to bringing ChakraCore to other platforms in the future."
- SwellJoe 11y ago
  And, when that future arrives, maybe it'd be useful to revisit the topic.
mambodog 11y ago
Google doesn't care about the server-side use case for V8. Microsoft, on the other hand, has some skin in the game, as they are pushing Node on their Azure platform. While I wouldn't want to see Node controlled by Microsoft (or any single vendor for that matter), it's not outside the realm of possibility that Node will be better off using (open source) ChakraCore over V8.
- scriptproof 11y ago
  See at Google Coder (https://googlecreativelab.github.io/coder/ https://googlecreativelab.github.io/coder/). A Node based server of applications.
comex 11y ago
> When Chakra is open-source and cross-platform, its differentiating "killer" features will be merged into node's V8. You don't just merge features between JS engines - there may be one or two big wins that others will copy, but they're not like, say, C compilers, where different compilers by and large produce fairly similar machine code, because for the most part the language semantics correspond reasonably directly to machine semantics and the problems involved are well-studied, so the machine code is pretty close to optimal. JS has higher level semantics that admit varying implementation strategies - for example, all major engines use tagged pointers, but they all do it somewhat differently (e.g. V8 does not use NaN-boxing but others do); or on a macro level, those semantics require a garbage collector, which has a ton of implementation choices. Because JS engines are JITs, they perform optimizations informed by runtime information, which are more flexible but for that reason far more prone to guesswork, e.g. about what information to record, what kinds of assumptions to make about types mostly being static in practice, etc. And all JS engines have to balance runtime against compilation time, even to some extent for very hot loops, so they tend to have relatively simple optimization pipelines that value pragmatism over being able to cover every possibility. The result is a lot of idiosyncrasy and a large number of little decisions and strategies that together can be highly significant but are hard to just port from one engine to another. Notably, perhaps as a result, there seems to be a trend to basically rewrite JS engines' JITs while keeping the same name. V8 did this with Crankshaft in 2010 and is in the process of doing it again with Turbofan (dunno whether it will ultimately replace Crankshaft or just complement it, but I wouldn't be surprised at the former, considering that there is currently a large amount of duplicated functionality between them). I know SpiderMonkey has done it too but not the details. > SpiderMonkey has been beating V8 in ES2015 adoption and V8s own benchmarks, but even that wasn't enough for it to become the new node.js runtime. We have yet to see if what Microsoft brings to the table is more convincing. citation needed. "V8's own benchmarks" would be Octane, so this, which seems to be about evenly split between V8 and SpiderMonkey in the lead: http://arewefastyet.com/#machine=28&view=breakdown&suite=octane http://arewefastyet.com/#machine=28&view=breakdown&suite=oct...

by krisdol 11y ago

deleted 11y ago

[deleted]

brazzledazzle 11y ago

>"In order to use Microsoft's fork, you need a Windows 10 machine with the November update" That does take the wind out of the post's sails a bit.

cwyers 11y ago

Chakra is being opensourced this month. I really doubt that V8 will be able to just pull features from it as easily as you suggest here.

yuhong 11y ago
I was hoping for a open source Windows x64 ABI compliant JavaScript JIT for a while now.

taspeotis 11y ago

https://blogs.windows.com/msedgedev/2015/12/05/open-source-chakra-core/ https://blogs.windows.com/msedgedev/2015/12/05/open-source-c... "...we are committed to bringing ChakraCore to other platforms in the future."

SwellJoe 11y ago
And, when that future arrives, maybe it'd be useful to revisit the topic.

mambodog 11y ago

Google doesn't care about the server-side use case for V8. Microsoft, on the other hand, has some skin in the game, as they are pushing Node on their Azure platform. While I wouldn't want to see Node controlled by Microsoft (or any single vendor for that matter), it's not outside the realm of possibility that Node will be better off using (open source) ChakraCore over V8.

scriptproof 11y ago
See at Google Coder (https://googlecreativelab.github.io/coder/ https://googlecreativelab.github.io/coder/). A Node based server of applications.

comex 11y ago

> When Chakra is open-source and cross-platform, its differentiating "killer" features will be merged into node's V8. You don't just merge features between JS engines - there may be one or two big wins that others will copy, but they're not like, say, C compilers, where different compilers by and large produce fairly similar machine code, because for the most part the language semantics correspond reasonably directly to machine semantics and the problems involved are well-studied, so the machine code is pretty close to optimal. JS has higher level semantics that admit varying implementation strategies - for example, all major engines use tagged pointers, but they all do it somewhat differently (e.g. V8 does not use NaN-boxing but others do); or on a macro level, those semantics require a garbage collector, which has a ton of implementation choices. Because JS engines are JITs, they perform optimizations informed by runtime information, which are more flexible but for that reason far more prone to guesswork, e.g. about what information to record, what kinds of assumptions to make about types mostly being static in practice, etc. And all JS engines have to balance runtime against compilation time, even to some extent for very hot loops, so they tend to have relatively simple optimization pipelines that value pragmatism over being able to cover every possibility. The result is a lot of idiosyncrasy and a large number of little decisions and strategies that together can be highly significant but are hard to just port from one engine to another. Notably, perhaps as a result, there seems to be a trend to basically rewrite JS engines' JITs while keeping the same name. V8 did this with Crankshaft in 2010 and is in the process of doing it again with Turbofan (dunno whether it will ultimately replace Crankshaft or just complement it, but I wouldn't be surprised at the former, considering that there is currently a large amount of duplicated functionality between them). I know SpiderMonkey has done it too but not the details. > SpiderMonkey has been beating V8 in ES2015 adoption and V8s own benchmarks, but even that wasn't enough for it to become the new node.js runtime. We have yet to see if what Microsoft brings to the table is more convincing. citation needed. "V8's own benchmarks" would be Octane, so this, which seems to be about evenly split between V8 and SpiderMonkey in the lead: http://arewefastyet.com/#machine=28&view=breakdown&suite=octane http://arewefastyet.com/#machine=28&view=breakdown&suite=oct...