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

https://github.com/Microsoft/node

by chcokr • 11 years ago

170 84 11 years ago

github.com

Hansi• 11 years ago

Is there a benchmark comparison available anywhere?

cmwelsh• 11 years ago

Can I browse my node_modules folder in Explorer yet? [1]

[1] https://github.com/joyent/node/issues/6960

rational-future2• 11 years ago

With every new version of Windows, Explorer gets worse and worse. I personally switched to Directory Opus long time ago.

chimeracoder• 11 years ago

With every new version of Windows, Explorer gets worse and worse.

This criticism is a bit misplaced here, since the whole reason for this limitation is due to backward compatibility with older versions of Windows (and software written for older versions).

It's not like this is a new change in Windows; it's been there for ages.

orik• 11 years ago

This isn't a limitation of Explorer, but actually is a very well documented part of the Windows API. MAXPATH has always been 260 characters.

https://msdn.microsoft.com/en-us/library/aa365247(VS.85).asp...

dyscrete• 11 years ago

Wow, what's up Microsoft?

pionar2• 11 years ago

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?

rational-future2• 11 years ago

Will this work on Raspberry Pi?

doczoidberg• 11 years ago

the chances are good: http://blogs.windows.com/buildingapps/2015/05/12/bringing-no...

elisee2• 11 years ago

This tweet from May 1 might be related: https://twitter.com/conoro/status/594196246727774208

sgv• 11 years ago

Yes, this works on Raspberry Pi 2 and MinnowBoard MAX, running Windows 10 IOT Core preview - http://ms-iot.github.io/content/Downloads.htm

elisee2• 11 years ago

"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/2015/05/12/bringing-no...

They're doing this to be able to run Node.js apps on Windows 10 ARM (on which V8 supposedly doesn't run?)

"We will be submitting a pull request to Node.js after stabilizing this code, fixing key gaps and responding to early community feedback."

"Going forward, we plan to work closely with the Node Foundation, the Node.js Technical Committee(s), IO.js contributors and the community to discuss and participate in conversations around creating JavaScript engine agnostic hosting APIs for Node.js, which provide developers a choice of JavaScript engine that they would want to use in their Node.js workflow"

Looks like the pull request will consist mostly of exposing new hooks to integrate with Chakra / other JS engines and won't involve pulling any Chakra code into Node.js (which would be unlikely to be merged). Might lead to a SpiderMonkey version of Node.js at some point, too. Nice to see IO.js mentioned. Looks like a very positive initiative (assuming it doesn't complicate Node core too much)

magicalist4• 11 years ago

They're doing this to be able to run Node.js apps on Windows 10 ARM (on which V8 supposedly doesn't run?)

V8 definitely has an ARM runtime, so maybe this is a result of the restrictions on what's allowed to run on the platform? (e.g. iOS and Windows Phone don't allow JIT compilers except the ones provided by the platform itself)

gsnedders4• 11 years ago

I'd guess, at the very least, that it doesn't support the Win/ARM ABI.

silverwind• 11 years ago

The question is why should node/io.js take such a pull request. It adds support for an irrelevant platform and would add the burden of maintaining the 'wrapper' which will probably break on every v8 update.

rlidwka• 11 years ago

If it adds an engine abstraction layer which would allow users to choose an engine (and somebody implements SpiderMonkey support there), sure why not.

Though this is a job that is already done by JXCore.

zpao• 11 years ago

Might lead to a SpiderMonkey version of Node.js at some point, too.

I worked on that 4 years ago :) <http://zpao.com/posts/about-that-hybrid-v8monkey-engine/>. The Node community at the time wasn't a huge fan, though it's effectively the same thing that MS just did (build a minimal V8 API shim on top of another JS engine). I guess everybody is ok with a little fragmentation now. Our intention was also to try to get this upstreamed, however with low interest and other things to do, we didn't follow through.

I'm excited to see this, and especially to have the MS folks involved with the TC. I'd love to see an engine-agnostic API but realistically I don't think it'll happen, at least not anytime soon. Right now Node itself definitely relies pretty heavily on the V8 APIs. Those APIs can be abstracted for the most part (even if each engine is just shimming those parts of the V8 API) but the other problem is the longer tail of binary npm modules. Right now they have the full V8 API to work with. If they do a shim layer then it will come at cost for every vendor except V8. And then maintaining that layer as V8 changes APIs. If you go the engine-agnostic API route, then you will need coordination between engine vendors. That opens the doors to a multitude of problems.

Twirrim• 11 years ago

Also that's going to potentially add a ton of work for people developing libraries. With a single engine behind it, the coding efforts can be focussed on writing and profiling something to be fast on v8. If you get replaceable engines, now developers have to either: 1) Ignore all but V8 (or spidermonkey, or chakra etc.) 2) Create different versions of their libraries for different engines. ( 3ish) write multiple paths in their code depending on the target engine)

I'm not sure exactly where I sit on this one. In many regards I think I like it, allowing developers to use the right engine for the right job, for example. Each engine has its own strengths and it may be that v8 isn't the engine for you / your workload. It's just this could hurt as much as it helps.

themgt• 11 years ago

I wonder how difficult it will be to manage pull requests for merging against node.js & io.js simultaneously - also, creates an interesting political situation if one project accepts the PR but the other doesn't (I would guess io.js will be more eager to do a release against the new code)

flipchart• 11 years ago

I wasn't aware that Chakra could be used standalone in this manner. I had assumed that it was tightly bundled to IE. Is this new?

mmozeiko• 11 years ago

They are using this API: https://msdn.microsoft.com/en-us/library/dn903710.aspx

bhouston• 11 years ago

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.

consptheorist2• 11 years ago

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

magicalist4• 11 years ago

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

agumonkey• 11 years ago

This reinforce my feeling that most of the issues with Firefox is the GUI framework.

esailija• 11 years ago

How do you live in such a bliss ignorance where supposedly an order of magnitude difference in performance between two state of the art browsers doesn't make you reconsider even for a second that you might have not written a working benchmark? :)

Sorry but unless you have deep knowledge of how both engines and browsers work (knowing how `appendChild` is actually implemented for starters), you simply cannot write a working benchmark. Even then, it's very hard and tedious.

If you don't have time to obtain such expertise, you could take a shortcut and compare realistic end-to-end benchmark. E.g. if your game runs at 210-270 fps in firefox but only at 30 fps in chrome, then you could claim that "firefox blows chrome out of the water".

It's very easy (just look at 80%+ of jsperfs) to construct benchmarks that don't look completely broken to the untrained eye but actually are. The common theme is the benchmark missing many aspects of realistic code and being reduced to measuring irrelevant optimizing compiling features. For example the benchmark could only be measuring how thorough the engine's dead code elimination pass is even though what you wanted to benchmark is string concatenation performance.

petercooper• 11 years ago

For anyone who wants to run Spidermonkey with Node, JXcore is a Node fork that enables this.

cleverjake• 11 years ago

and chakra is currently faster than both on the octane and jet stream benchmarks

TazeTSchnitzel• 11 years ago

Given node.js supports native code modules I can't see why it'd matter, but SpiderMonkey has a special asm.js compilation unit, OdinMonkey, giving best-in-class asm.js speed.

cpeterso2• 11 years ago

Interesting that Microsoft forked Node instead of io.js. The Microsoft repo says, "This branch is 16 commits ahead, 29 commits behind joyent:master".

jjcm• 11 years ago

I work for MS, right now we're working on win10. Some of the UI is written in html/js now, so I'm not surprised by this at all. I'm guessing we'll see some native node.js apps on windows in the future.

untog• 11 years ago

I think what the OP meant was that it is interesting that MS forked Node, and not the io.js project that's more advanced than Node.

IMO it's not too surprising - it's relatively simple to fast forward to io.js from where it is now, wheras reverse engineering it backwards to Node compatibility would be mayhem.

htilford• 11 years ago

This was a long time coming. I remember some MS folks talking to Ryan Dahl about doing this back at nodeconf 2011.

frik2• 11 years ago

What about the license of Node.js/Chromium? Isn't linking a closed source library (Chakra) problematic?

You know it includes multiple code parts under various licenses, Wikipedia says: BSD license, MIT License, LGPL, MS-PL and MPL/GPL/LGPL tri-licensed ( http://en.wikipedia.org/wiki/Chromium_(web_browser) )

There is a reason why major open source projects like Linux, etc. choose licenses like GNU GPL v2+. http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish and http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

coldtea2• 11 years ago

Isn't linking a closed source library (Chakra) problematic?

Yeah, because the tech world didn't have enough problems with projects being immature, unreliable, stale 30+ year designs, abandoned, incompatible, not provided by a specific distribution, coflicting, patented and 100 other issues to consider.

It just had to also add 200 legal distinctions behind what you can and you cannot do, and how you can link stuff and under what circumstances.

magicalist4• 11 years ago

If you're asking if software licenses are important, the answer is yes, they're very important.

To the GP, though, I don't immediately see how linking to Chakra in this way would be a license issue. The more important thing is the license information for Node, though, not Chromium: https://github.com/joyent/node/blob/master/LICENSE (some overlap but quite a bit that doesn't)

poizan42• 11 years ago

It's already linked against tons of closed source libraries when built on windows, why would one more make a difference?

chc• 11 years ago

Based on that license list, I don't see how any of those would present a problem. Do you?

cpeterso2• 11 years ago

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").

streamline92• 11 years ago

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...

pluma2• 11 years ago

I know Microsoft apparently has changed, but just to play devil's advocate:

[x] embrace

[x] extend

[ ] extinguish

chralieboy• 11 years ago

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.

jbigelow76• 11 years ago

Extinguish Javascript? Good luck with that.

nivla• 11 years ago

To play the devil's advocate of the devil's advocate, how exactly would an [x]extinguish work in an open source world especially for something that is under a liberal licence (MIT vs GPL)? Isn't that the whole point of open source? That if even something gets abandoned or ignored, as long as there is still an active interest in it, it can still be used or improved upon?

pluma2• 11 years ago

You're probably aware I'm not considering it to be likely that this is Old Microsoft in action but to humour the thought experiment: I don't think they could succeed either. IE is still only barely recovering from Microsoft's history and Windows has largely been defeated by OSX both in the consumer and developer space. We're unlikely to see Microsoft Space Nazis descend upon us from a hidden moon base any time soon.

That said, there are plenty of examples of the extinguish phase not working out or resulting in less of a bang and more of a whimper. It's always been more of an infected blanket than nuclear warheads.

ilaksh• 11 years ago

I don't see how anyone can rationally trust Microsoft here given their track record.

Ezhik2• 11 years ago

I wonder if MS is going to end up open sourcing Edge? Between this and the fact that Visual Studio Code uses Chromium, it really seems like where MS should head, but who knows.

bastawhiz• 11 years ago

I'd expect them to open source various components of it before they open source the whole shebang. I.e., I'd expect to see them put Chakra out, maybe the browser chrome, the parsers, etc. before they put out all of edgehtml.dll. I could be wrong.

Edge (and particularly IE) are fairly heavily tied to the OS in a bunch of places. IE, for example, can do weird FTP and Windows Explorer stuff. The infamous "Internet Settings" dialog and the way IE deals with stuff like proxy servers is only sort-of part of IE. IE's network stack is largely dependant on the bits and pieces available in the OS below (consider IE11 can only use SPDY on Windows 8). I wouldn't be surprised if open sourcing the browser wholesale would start unraveling a lot of things that MS doesn't intend to be public.

Ezhik2• 11 years ago

I wonder if making it standalone will be a part of the whole 'ditching IE legacy' process?

z3t4• 11 years ago

I wonder if they have made it so that you can use milliseconds (1/1000) instead of (1/100) in setTimeout and setInterval. It was one of the things that annoyed me the most running Node.JS on Windows ...

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

Related Stories