Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

github.com

Post reply on HN
Print view View original

41–50 of 104 posts

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#41

Post by magicalist »

consptheorist wrote: post #36
bhouston wrote: post #10

It would be cool if the JavaScript engine was interchangable in NodeJS and IO.JS so you could pick Chakra, V8 or SpiderMonkey very easily. SpiderMonkey is faster than V8 these days on a lot of benchmarks.

I can attest to that. I was experimenting a couple of days ago with high duty and extreme DOM nodes crunching and FF's SpiderMoneky blew Chrome's V8 out of the water for 7 - 9 multiples gain in performance measured in time elapsed to complete the operations. Chrome's V8 engine at this point is so overrated

> I was experimenting a couple of days ago with high duty and extreme DOM nodes crunching and FF's SpiderMoneky blew Chrome's V8 out of the water for 7 - 9 multiples gain in performance measured in time elapsed to complete the operations.

This likely has nothing to do with the JS engines themselves and everything to do with the browser they were running in. To actually benchmark something like that you'd need to simulate the dom with something like https://github.com/tmpvar/jsdom

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#42

Post by [deleted] »

frik wrote: post #35
mkr-hn wrote: post #24

Earlier quoted context omitted.

Looks like it's been close to a decade. The CEO responsible for that whole ordeal is gone. When do people decide Microsoft has behaved long enough to be given a second chance?

> The CEO responsible for that whole ordeal is gone. When do people decide Microsoft has behaved long enough to be given a second chance? If the company clearly changes it's course, right? Though it doesn't seem to be the case, despite two CEO changes since Bill Gates. Recent news show more or less what they are still up-to. Yesterdays plans to stop producing Windows and "Win10 as a service": https://news.ycombinator…

[deleted]

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#44

Post by streamline92 »

cpeterso wrote: post #22

JXcore is another fork of Node that makes the VM pluggable, supporting both V8 and SpiderMonkey. I wonder how similar Microsoft's and JXcore's VM abstraction layers are and whether Node upstream would accept them. Drawing a hard line between the Node native code and the VM would make binary addon compatibility more stable (and lessen the need for NaN, the "Native Abstractions for Node").

The problem with the way JXcore did the SpiderMonkey port is their extensive use of C++ macros - not unlike NAN for Node.js. This makes the code hard to debug and maintain. The Microsoft Chakra Node port is more elegant because they've mimicked the V8 C++ API making it much more likely that it will be merged into Node.js and IO.js. In time I suspect Mozilla and other javascript engines will make V8-compatible API shims similar to what Microsoft did:

https://github.com/Microsoft/node/tree/ch0.12.2/deps/chakras...

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#45

Post by chralieboy »

pluma wrote: post #43

I know Microsoft apparently has changed, but just to play devil's advocate: [x] embrace [x] extend [ ] extinguish

They are very open that this is not their plan here. They are _temporarily_ forking Node.js to add support for their JS engine. They want to extend Node to abstract away the JS engine so that it doesn't rely on V8 or Chakra or SpiderMonkey but can sit on any one of them.

It's actually exactly the opposite. Their API abstraction work will only increase competition, especially since they aren't trying to run a competing fork. Despite their history, those in favor of a more open Node.js platform should commend this.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#46

Post by mkr-hn »

frik wrote: post #35
mkr-hn wrote: post #24

Earlier quoted context omitted.

Looks like it's been close to a decade. The CEO responsible for that whole ordeal is gone. When do people decide Microsoft has behaved long enough to be given a second chance?

> The CEO responsible for that whole ordeal is gone. When do people decide Microsoft has behaved long enough to be given a second chance? If the company clearly changes it's course, right? Though it doesn't seem to be the case, despite two CEO changes since Bill Gates. Recent news show more or less what they are still up-to. Yesterdays plans to stop producing Windows and "Win10 as a service": https://news.ycombinator…

All you did is make a list. Can you expand this into something coherent?

Office uses a documented XML format now, Silverlight is dead, and I don't see how Xbox One is in any way relevant.

Not sure how making Windows free is "embrace, extend, extinguish." Most operating systems are free.

People make new languages based on old ones all the time, so you're going to have to expand on the problem with TypeScript.

I could go on, but I'm not a teacher running through an essay with a red pen. You won't convince anyone with a comment-free list of events.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#47

Post by consptheorist »

magicalist wrote: post #41
consptheorist wrote: post #36

Earlier quoted context omitted.

I can attest to that. I was experimenting a couple of days ago with high duty and extreme DOM nodes crunching and FF's SpiderMoneky blew Chrome's V8 out of the water for 7 - 9 multiples gain in performance measured in time elapsed to complete the operations. Chrome's V8 engine at this point is so overrated

> I was experimenting a couple of days ago with high duty and extreme DOM nodes crunching and FF's SpiderMoneky blew Chrome's V8 out of the water for 7 - 9 multiples gain in performance measured in time elapsed to complete the operations. This likely has nothing to do with the JS engines themselves and everything to do with the browser they were running in. To actually benchmark something like that you'd need to simu…

Are you suggesting that the remarkable disparity in performance was DOM specific?

Strange because I used a very common method appendChild() and I was under the impression that both browsers had optimized their respective inner workings a long time ago to the point that we should not notice such divergence in performance.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#48

Post by [deleted] »

elisee wrote: post #5

"This temporary fork enables Node.js to optionally use the Chakra JavaScript engine on Windows 10, allowing Node.js to run on Windows on ARM." (the submission title has been updated after I posted this, was initially "MS releases a fork of Node that uses the Chakra JavaScript engine instead of V8") Looks like they intend to merge back with node mainline... ? EDIT: Found this: http://blogs.windows.com/buildingapps/201…

[deleted]

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#49

Post by tracker1 »

pionar wrote: post #20
dyscrete wrote: post #9

Earlier quoted context omitted.

Wow, what's up Microsoft?

Actually, I was thinking, what's up node? Each dependency keeps a private copy of its dependencies? How messed up is that? Or am I just reading that wrong?

npm 3 will adjust dependencies to flatten these things out as much as possible, only creating nested dependencies when there's a version conflict between modules.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#50

Post by dpe82 »

consptheorist wrote: post #47
magicalist wrote: post #41

Earlier quoted context omitted.

> I was experimenting a couple of days ago with high duty and extreme DOM nodes crunching and FF's SpiderMoneky blew Chrome's V8 out of the water for 7 - 9 multiples gain in performance measured in time elapsed to complete the operations. This likely has nothing to do with the JS engines themselves and everything to do with the browser they were running in. To actually benchmark something like that you'd need to simu…

Are you suggesting that the remarkable disparity in performance was DOM specific? Strange because I used a very common method appendChild() and I was under the impression that both browsers had optimized their respective inner workings a long time ago to the point that we should not notice such divergence in performance.

Yes. DOM manipulation in all major browsers is implemented in C/C++. The JS engine is just a wrapper; any noticeable performance difference in DOM manipulation is almost certainly due to differences in the underlying layout engine and not in the JS engine.
Post reply on HN