
Temporary fork enables Node.js to optionally use the Chakra JavaScript engine - chcokr
https://github.com/Microsoft/node
======
elisee
"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...](http://blogs.windows.com/buildingapps/2015/05/12/bringing-node-js-to-
windows-10-iot-core/)

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)

~~~
zpao
> 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/>](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
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.

~~~
bsimpson
Using @zpao's example, most Python developers use CPython and either don't
know about PyPy or have never used it. As such, I'd expect most of the long-
tail of Python libraries to have been written and tested against CPython.

That hasn't prevented PyPy, IronPython, JPython, etc. from existing/thriving.

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

~~~
consptheorist
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

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

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

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

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

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

~~~
orik
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...](https://msdn.microsoft.com/en-
us/library/aa365247\(VS.85\).aspx#maxpath)

~~~
frik
How long will Microsoft wait till the fix MAXPATH and other limitations? (and
various other Win32 limitations that are usually a legacy porting helper thing
from Win16). There would have been a good point with the introduction of
Win64API - but Microsoft forgot about it and was apparently busy with
something else.

~~~
CHY872
I doubt it's _too_ high up on the list of priorities. It would require really
careful work to work in a backwards compatible way (there are almost certainly
a tonne of apps that expect <=260 character filenames).

I guess the main thing is that it's one of those 'who cares' problems. The
only time I've ever seen this limitation being complained about, it's by
people who've had problems with npm.

That directory structure is _undoubtedly_ horrible and is not mirrored by any
other piece of software that I've seen.

~~~
jessaustin
Meanwhile it's also a "who cares?" problem for the npm people. They don't use
this OS, and don't expect ever to do so.

I think the node_modules directory structure is a novel, though
straightforward, solution to the problem of interdependent module versioning.
It's very Unix; it reminds me a bit of GNU stow. It makes perfect sense that
it will be tweaked in the new npm to be less redundant, but it only really
makes sense to tweak systems that already work perfectly. (Otherwise they
should be fixed first, then tweaked.) Certainly it's better than having a
separate LD_LIBRARY_PATH setting for every command invocation! (even _that_
doesn't fix everything...)

~~~
xienze
It doesn't even seem like an obvious solution to the problem. Take Maven for
instance: a global dependency repository under which the dependencies are
stored in the form <groupId>/<artifactId>/<version>. If X depends on Y.1 and Z
depends on Y.2, so what? You have all the dependencies stored on your
filesystem in a relatively flat structure.

~~~
jessaustin
If I had coded in Java on Windows for years, I wouldn't trust my sense of
what's "obvious". I'm not too impressed by a "global" repository either.
Python struggled against that stupid architecture for years before they got
virtualenv in good working order. Node just took a shortcut to the future.

"All direct dependencies are in the node_modules directory, full-stop" is a
pretty simple rule. Really, that's the only rule, and that's all of it. You
don't need to worry about second-order dependencies, because those are direct
dependencies of some other module, which means... they are in _that_ module's
node_modules directory.

------
cpeterso
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
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...](https://github.com/Microsoft/node/tree/ch0.12.2/deps/chakrashim)

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

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

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

------
Hansi
Is there a benchmark comparison available anywhere?

------
frik
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)](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](http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish)
and
[http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt](http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt)

~~~
coldtea
> _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.

~~~
magicalist
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](https://github.com/joyent/node/blob/master/LICENSE)
(some overlap but quite a bit that doesn't)

~~~
coldtea
> _If you 're asking if software licenses are important, the answer is yes,
> they're very important._

I'm not asking about their importance, I complain about their existince (and
need).

------
rational-future
Will this work on Raspberry Pi?

~~~
doczoidberg
the chances are good:
[http://blogs.windows.com/buildingapps/2015/05/12/bringing-
no...](http://blogs.windows.com/buildingapps/2015/05/12/bringing-node-js-to-
windows-10-iot-core/)

~~~
elisee
This tweet from May 1 might be related:
[https://twitter.com/conoro/status/594196246727774208](https://twitter.com/conoro/status/594196246727774208)

~~~
aeroevan
I'm betting raspberry pi 2 only (i.e. armv7 only) since that's all Windows IoT
runs on. Doubt they'd put the effort into armv6 for all of the existing
raspberry pi 1 devices.

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

------
flipchart
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
They are using this API: [https://msdn.microsoft.com/en-
us/library/dn903710.aspx](https://msdn.microsoft.com/en-
us/library/dn903710.aspx)

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

[x] embrace

[x] extend

[ ] extinguish

~~~
nivla
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?

~~~
pluma
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
I don't see how anyone can rationally trust Microsoft here given their track
record.

