
Enable Node.js to Run with Microsoft's ChakraCore Engine - bpierre
https://github.com/nodejs/node/pull/4765
======
domenicd
It's important to remember that ChakraCore only currently builds on Windows,
so this is only for Windows Node.js builds.

The ChakraCore roadmap [1] shows that they plan on porting the interpreter to
Ubuntu, but not to Mac OS, and they don't plan on porting the JIT. So even it
does go Windows + Linux, it will still be a low-performing toy on Linux.

This is vaguely interesting from a technical point of view, but doesn't seem
like it'll majorly impact the future of Node.js, except maybe as something
Microsoft can offer for Azure customers that choose Windows Server.

[1]:
[https://github.com/Microsoft/ChakraCore/wiki/Roadmap](https://github.com/Microsoft/ChakraCore/wiki/Roadmap)

~~~
bterlson
The goal is for all of ChakraCore to be broadly cross-platform eventually,
including the JIT, and including many more platforms than just Ubuntu x64. The
roadmap reflects our next steps for the next 6 months but is not the entire
journey.

Disclosure: I work on Chakra

~~~
shawn-butler
>> An implementation of ChakraCore interpreter and runtime, no JIT, on Linux.

You should update the wiki if you work on the project then. The stated roadmap
goal seems fairly clear and aligns with a typical Microsoft strategy to ensure
Windows remains the premium platform for its "open source" efforts.

Not being negative that is just the way it has gone in the past so you are
fighting an uphill battle.

Disclosure: None

~~~
jeswin
Even the updated Roadmap suggests that Windows remains the primary platform.
This Windows-first backend is a bad idea for Node.js, unless the team (and MS)
commits to supporting Linux and Mac on par with Windows. That includes not
releasing unless they have performance/feature parity on all major OSes, and
committing equal resources to all.

While MS is nowhere as powerful as it was in the 90s, this is exactly how MS-
Java happened and why Sun went to court.

~~~
Sanddancer
Almost all software has a primary platform. There are a lot of free software
apps where windows is either not a priority, or where the devs refuse to
implement patches that improve how it works under windows. Additionally, this
is just one engine that node supports, in addition to v8, and I assume that
with this, other engines can, or could be added in the future. Node's goal is
to be a javascript server platform, and that means having hooks both upward
and downward to make developers' jobs easier.

~~~
jeswin
> Almost all software has a primary platform.

I have no disagreement with software having a primary platform. However, it
would make a lot of sense for open source software to choose an open source
platform as primary.

Add: I guess what I'm saying is, if you're making enhancements to an existing
Open Source project which already works on non-proprietary platforms, it would
be better if those enhancements work equally well on non-proprietary
platforms.

~~~
dogma1138
There are tons of FOSS/OSS projects for which OSX is the main platform.

Windows isn't exactly a "proprietary" platform, the OS is closed source and
proprietary is but it's the wrong definition to use to describe it as a
platform especially today with PAAS/IAAS.

Windows isn't free that's true but as far as PAAS (Azure/Azure-Like) goes it's
not really a critical part of the pricing, and even for IAAS it's not that
important.

One could also say that RHEL, SLES and the likes are proprietary distributions
of Linux, they are open source, but proprietary none the less.

~~~
malandrew
What remarkable or known FOSS/OSS projects are OS X as the main or only
platform that aren't inherently platform specific like homebrew?

I can't think of one open source project that I use that is only available on
OS X or primarily an OS X project.

------
tbrock
This is awesome, but before anyone uses this for something real keep in mind
that the way this works is that Microsoft has created a shim on top of Chakra
that exposes a V8 API.

If V8 changes its API drastically (which it frequently does) this little
experiment is basically over. There is only so much work people can do to keep
up with a moving target.

Barring NodeJS creating an abstract JS engine API that developers can create
v8/chakra/spidermonkey adapters for I can't see this being a success.

That being said, I hope that Node and V8 coupling becomes less tight and the
interface between the two does become abstract so that we can all benefit from
a choice of engine that implements the requirements of NodeJS.

~~~
cwyers
The thing is, Node needs to keep up with those same APIs.

~~~
smegel
It needs to call them, not implement them. I am guessing the former is a lot
simpler than the latter.

------
morebetterer
Many posters in that Github Chakra pull request thread appear to be in the
"Node is V8 and only V8" camp. This is disappointing. Since when is having a
bigger developer community, supporting the latest ES6 standards, and having
wider reach for NodeJS a bad thing? Look at what the friendly rivalry has done
for the various browsers - the competition benefitted everyone and advanced
technology immeasurably.

~~~
Osiris
I'm a node.js developer and I don't really care what interpreter is being used
as long as any code submitted to NPM is compatible with any version of node.js
regardless of the JavaScript engine.

The only issues would be in ChakraCore were to support additional ES6/7
features that people started to use that wouldn't work on a V8 node.js
instance, or the other way around.

~~~
Arnavion
How is that different from how node v5 supports additional ES6/7 features that
don't work in node v4? In the end you can only rely on package authors to be
aware of their targets' capabilities and code to the minimum baseline
accordingly.

~~~
Osiris
npm needs to learn how to deal with that. For example, if a package is marked
as requiring 5.4, but you have 4.2, then it should automatically use a tool
like babel to convert unavailable ES6 syntax to ES5 for compatibility. I
really want to be able to write my modules to take advantage of ES6 while not
having to build all that babel stuff into my module for compatibility.

~~~
dcherman
Some of that is possible, but some of that is not. Consider the use case of
WeakMaps or Proxies that cannot truly be polyfilled, they need to be
implemented at the language level.

Suppose you could transpile what is possible, then throw errors otherwise,
however that would involve parsing each file in an NPM module which is
probably an unreasonable task performance wise.

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

~~~
dsp1234
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)

~~~
Klathmon
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
Does it matter? If V8 deoptimizes code with try/catch, then I as a developer
need to account for that.

~~~
Klathmon
It does!

V8 has expressed interest in fixing the try/catch deopt, but it keeps falling
behind on their list because not many people are using it.

Most people aren't using it because V8 (and in some minds, mine included until
5 days ago, all of Javascript) doesn't optimize it.

It's a bit of a catch 22, and having alternate engines where that deopt
doesn't happen can be the way out.

Basically having an alternate engine makes sure that stuff like this doesn't
become _permanent_. You'll probably avoid try/catch in performance code for
the near future (and i'll most likely do it as well), but the hope is that
multiple implementations will force V8 to fix that issue (if it can be called
that) at some point and eventually this little bit of optimization will no
longer be necessary.

~~~
STRML
> it keeps falling behind on their list because not many people are using it.

How can that be true? try/catch is as common a JS idiom as a for loop.

This causes significant trouble all over React and many other libraries, as
many hot areas of code are covered in try/catches to ensure developer error
doesn't blow the whole render. Optimizing it could lead to pretty serious
performance gains.

------
kojoru
There's a Microsoft blog post which gives much more details:
[https://blogs.windows.com/msedgedev/2016/01/19/nodejs-
chakra...](https://blogs.windows.com/msedgedev/2016/01/19/nodejs-chakracore-
mainline/)

------
morebetterer
I hope the V8 C++ API doesn't become the defacto Node engine API. Node really
needs a proper engine-neutral API. This way the native node modules can truly
be portable across engines and across node versions.

Supporting additional JS engines would ultimately lead to a healthier
ecosystem and higher quality JS implementations.

------
tjfontaine
Congratulations Microsoft and the Node.js team! Providing alternate JavaScript
run times is critical to the success of a platform that requires predictable
performance on a variety of environments. I'm so proud of everyone making this
come true!

Great work everyone.

------
jorangreef
I'm not sure if Google and V8 have always gone out of their way to embrace
Node and optimize V8 for Node. Perhaps they have. I'm not sure.

But this is Microsoft going out of its way to provide a swap-in engine for
Node, with a focus on optimizing the engine for Node through benchmarks, and
cross-platform builds in the pipeline.

Hopefully, Microsoft will be able to achieve the following:

1\. A smaller Node binary through a stripped-down engine.

2\. A GC optimized for Node and server applications.

3\. An engine optimized for Node, working closely with Node's core technical
team.

Perhaps this might encourage Google to do the same.

------
dsp1234
Some HN comments on this topic from when ChakraCore was announced last week.

[https://news.ycombinator.com/item?id=10896063](https://news.ycombinator.com/item?id=10896063)

------
taf2
I am sure I'm a minority on this thread - but does anyone else think that if
the engine is being developed in the open as open source then competition is
not a good thing. I believe it's similar to having io.js and node.js -
together it is a stronger platform. To this end, I think it would have made a
lot of sense for MS to collaborate with webkit/blink and vice versa... that's
the true spirit of open source IMO... I don't believe the web is stronger with
more rendering engines and more JS runtimes... I think it's weaker. What would
make it stronger is more open source and more collaboration. We have to be
very happy that MS is taking the first step in this direction. Open Sourcing
ChakraCore is a huge first step and now integrating it with other systems as
well . I just hope over the next 10 years we see more collaboration between
webkit, blink, gecko, and trident... as well as the JS engines...

~~~
smt88
If "together" means Google is involved, I absolutely prefer the separation.
Google has repeatedly screwed me over by letting their products stagnate and,
sometimes, killing them off. I find it incredibly frustrating that so much of
my work and digital life rely on the whims of Google.

------
bhouston
They should also have the option to use FireFox's engine as well.

Who has the fastest JS core these days?

~~~
inglor
Letting ChakraCore run means effectively "wrapping Chakra to emulate V8's
APIs". There was an experiment to do this for SpiderMonkey at one point but
it's a lot of work to maintain.

~~~
empyrical
Here's Mozilla's effort to implement the V8 api on spidermonkey if anyone's
curious:

[https://github.com/zpao/spidernode](https://github.com/zpao/spidernode)

------
nevi-me
Interesting development, a good one at that!

A few questions though. Node tracks V8 releases, so the first thing I'm
wondering is whether ChakraCore will continue emulating V8 APIs into the
future? What happens when ChakraCore adds breaking changes which V8 doesn't
support?

I presume MS will be supporting most development on the engine, as they
benefit from IoT Core and other applications relying on Node. If Mozilla were
to do the same and add SpiderMonkey, this would likely see the 3 major vendors
accelerate adoption of JS standards further. I'm more bullish on JS
development into the future.

If I were to predict, I'd see Node switching to ChakraCore as its primary
engine in a year. V8 has been 'we build you follow'. I know Domenic and other
Google developers have helped with the relationship with Node contributors,
but what will happen when MS offers a less-maintenance-prone engine? Embrace,
extend, extinguish!

~~~
sangnoir
> If I were to predict, I'd see Node switching to ChakraCore as its primary
> engine in a year.

Chakra doesn't even compile on Mac OS or Linux, where the majority[1] of
instances run. If I didn't know better, I'd say Microsoft isn't interested in
Chakra-Node running on other platforms - only on Windows, but with a
V8-beating performance or other 'desirable' Chakra-only extensions (extend).
Want high performance NodeJS? Find it on Windows/Azure (extinguish)

1\. This is an educated guess

~~~
Sanddancer
The roadmap for ChakraCore includes getting it to run cross-platform.
Additionally, as ChakraCore is Free Software, you're more than welcome to fork
it and/or submit patches as needed.

~~~
jmgao
"Patches welcome" is not a particularly compelling response to "it doesn't run
on any of the platforms people currently use".

------
git_son
Checking ChakraCore with static
analyzer:[http://www.viva64.com/en/b/0370/](http://www.viva64.com/en/b/0370/)

------
shad0wc0dex
With Microsoft starting to open source more projects, things like this really
start to become a reality. Awesome pull request, and I look forward to playing
around with this once the request has been merged. (If it does get merged)

------
jondubois
This is great. I still feel that Google isn't particularly excited about
Node.js. It's good to see that Microsoft puts faith in the platform.

I guess Google has a few conflicts of interest with Go and Dart.

~~~
TazeTSchnitzel
Google use a lot of Java, I believe. That probably has something to do with
it.

------
dev6563
Why should a developer care about this? What does ChkraCore bring to the table
that V8 doesn't ?

~~~
scope
ECMAScript 2015 coverage (even some ECMAScript 2016) by ChkraCore is better
than V8 (or SpiderMonkey) [1]

[1] [http://kangax.github.io/compat-
table/es6/](http://kangax.github.io/compat-table/es6/)

~~~
pritambaral
> V8 now has 92% ES6 coverage in Chrome Canary (on track for shipping in
> Chrome M49)

Source:
[https://news.ycombinator.com/item?id=10932790](https://news.ycombinator.com/item?id=10932790)

------
alkonaut
What is a potential benefit of using Chakra over V8? performance? licensing?

------
jordan801
Has anyone wrote up a Chakra vs V8 comparison?

------
minionslave
What does this mean for noje.js?

~~~
yarrel
Embrace, extend, extinguish.

~~~
geofft
Can you explain what you mean by this comment in this context?

~~~
mattkrea
We'll see how long it takes to go cross platform.

Only then can someone really say but so far this PR doesn't make me feel very
comfortable with the Node ecosystem going forward.

~~~
geofft
Linux support for ChakraCore is planned within the next few months:
[https://github.com/Microsoft/ChakraCore/wiki/Roadmap](https://github.com/Microsoft/ChakraCore/wiki/Roadmap)

We can see if that actually happens.

Can you explain what makes you feel uncomfortable about the Node ecosystem? I
believe Node.js already works on non-Windows platforms.

------
inglor
This is incredibly cool, I have a request.

Please do not post comments on the GH issue unless you have something
important to add. These issues gain a lot of attention and it makes it
_incredibly_ hard for collaborators to communicate.

Locking the issue to collaborators means other people from the outside who
have a significant contribution or want to help can't do that.

Comments like +1 -1 and such create a significant amount of noise.

Support open source, keep the discussion clean.

~~~
joshmanders
Looks like that didn't work out well.
[https://github.com/nodejs/node/pull/4765#issuecomment-172933...](https://github.com/nodejs/node/pull/4765#issuecomment-172933447)

Right above your clone of this comment on the thread. :/

~~~
ohnomrbill
Looks like this is a trolling attempt. The comment was subtly changed and the
author, [https://github.com/ingIor](https://github.com/ingIor), is a
misspelling of inglor and has no contributions.

------
z3t4
As a long time JS developer I was blown away by the V8 performance, and it
still amaze me. And it works very well on Windows.

What would be cool though, is if we could use vbScript in Node. Because
vbScript is even easier to learn then JavaScript!

