Enable Node.js to Run with Microsoft's ChakraCore Engine
github.com
github.com
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.
I don't know of anyone voluntarily using GccGo.
> For cross-platform support, the key target for next six months on the roadmap is to get the interpreter & runtime working. JIT would come after that (don't read it as no JIT forever - it was just a breakdown of what we need enable and its ordering for next 6 mos).
So maybe eventually it will be fully supported. (No update on Mac OS yet, but I can give them the benefit of the doubt there...)
[1]: https://github.com/nodejs/node/pull/4765#issuecomment-172942...
Disclosure: I work on Chakra
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
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.
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.
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.
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.
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.
One of the issues that spawned io.js was the lack of keeping up with V8 changes. I was asking the same question of what happens when V8 does something MS don't follow? It'll be interesting to see in the future. Good thing this happened when Node has an open governance model, so we can follow developments in future.
There may at some point be an effort to build an 'abstract node api interface' and main maintain bindings to various engines...
...but there's no way v8 will be dropped at any point in the foreseeable future.
What would you replace it with?
This? no way. We're years away from that even being plausible.
Is there any real point in trying to write a roadmap for something more than 2 years (at least) in the future?
No one has any idea what will be going on at that point; there isn't even a roadmap for an engine independent node api; and even when one is made (never mind implemented...), it will certainly not include 'drop v8' as part of it.
So we're talking about some nebulous future in which something may or may not happen after another thing which may or may not happen at some point in the future.
It's pointless to speculate about such obscure possibilities.
V8 isn't going away any time soon.
While not silly is existing at the whim of a single commercial vendor's browser decisions?
Quaint definition.
Edit: I don't mean to say the project sucks - docs sucking is just a general open source problem I can't really blame the authors for.
Edit: even if they had waited until the JITless builds for OS X and Linux were ready I'd be happier. This definitely feels like jumping the gun.
Node is a large code base. The Chakra merge will eventually work and pass all tests - give it some time. One cannot reasonably expect such a large merge to work flawlessly out of the gate. Even the IBM PowerPC port of the V8 engine took many months to stabilize - and it's the same v8 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.
It's easy to install NodeJS 5 with v8, it is however unacceptable to be required to switch to Windows.
This could change if they get around to porting it completely. For now the only thing they've committed to in the next 6 months is porting the ChakraCore interpreter(but not the JIT).
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.
Disclaimer: I work on V8
EDIT: 92% reported for "Version 50.0.2626.0 canary (64-bit)"
nice job!
Microsoft is trying to get into the whole IoT hype. This would help them a lot.
It also means they can write servers on Azure that don't need to be able to run V8.
Mostly windows store apps though.
Hopefully this will reduce the necessity to have a non-Windows machine around. That aspect has made things tedious for us.
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
You are just turning V8 into the new IE6 by adapting to it.
(Although, in reality, you probably won’t be able to do this, and will end up having to support the non-standard behaviour of V8.)
try/catch just isn't supported by V8's Crankshaft so some people avoid putting it in potentially hot code.
That's like not using CSS3 because IE6 doesn't support it.
Sure, some users of an antiquated browser will not get the full performance, but I have no sympathy for them.
If something doesn't work on Firefox, it's always "just switch to Chrome, our site only works on Chrome". If it doesn't work on Chrome, all hell breaks loose.
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.
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.
Why? Switch out V8 for ChakraCore. Having multiple engines means you, as a developer, get to pick the right tool for the job. That's not always V8.
Supporting additional JS engines would ultimately lead to a healthier ecosystem and higher quality JS implementations.
Great work everyone.
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.
I disagree. I'm happy to see numerous JS engine implementations that embrace a common standard. If you have just one common code base you also have a common set of bugs. Competition is a great way to raise the bar and try out radically different design approaches. Take GCC and LLVM for example - who can argue that friendly competition hasn't helped them both immeasurably? Link Time Optimization, C++14 compliance - choice is a good thing.
GCC vs EGCS, Xemacs vs Emacs, X.org vs Wayland, KDE vs Gnome, Firefox vs Chrome, GCC vs LLVM, etc., etc.
Competition is good even for Open Source projects.
Who has the fastest JS core these days?
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!
One of the comments on the pull request talks about this a little.[0]
"I have separately reached out to each of the V8 and Chakra teams and invited both to sit down face to face to work through the API/ABI impact of this change and figure out how we can make the ABI layer more robust."
[0] - https://github.com/nodejs/node/pull/4765#issuecomment-172935...
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
I guess Google has a few conflicts of interest with Go and Dart.
Only then can someone really say but so far this PR doesn't make me feel very comfortable with the Node ecosystem going forward.
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.
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.
Right above your clone of this comment on the thread. :/
Hacker News is already host to memes, trite boilerplate and pseudo-intellectual posing - drawing a line in the sand at humor seems like a futile gesture.
I also appreciate humor. What I don't appreciate are simple Reddit-level karma-grubbing jokes, and I will vote them down every single time.
You should be less cavalier with that broad brush. It isn't appreciated here.
What would be cool though, is if we could use vbScript in Node. Because vbScript is even easier to learn then JavaScript!