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.
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.
>> 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.
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.
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.
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.
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.
There was just a comment on GitHub [1] that updates this a bit:
> 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...)
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.
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.
I think the long-term solution is to drop V8. The V8 developers pretty much do not care about Node at all. Perhaps Chakra can come to some agreement to keep their APIs stable and if so they can become the new default engine.
I said long-term. V8 makes changes all the time that breaks Node, degrades performance in certain ways and essentially says "tough shit". Why wouldn't you look for an alternative?
Sure, but we're talking realllllly long term here.
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.
Node's and V8's APIs changed so frequently that someone created an abstraction layer called NaN ("Native Abstractions for Node.js") for people developing Node binary plugins.
Even NAN2 is breaking some things. Or at least deprecating. It's hard to keep up, and the docs and examples suck. I tried converting a node v0.10 module to using it and flailed horribly.
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.
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.
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.
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.
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.
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.
For now, it's different because Node + Chakra doesn't run on all the supported platforms, but v8 does.
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).
It shouldn't be merged into core if it doesn't work on the rest of the platforms core works on. Keep it in some experimental branch until it is ready and more important why would they even submit the PR if a ton of tests are failing?
If it's a compile-time switch to build v8 or Chakra and it's not impeding Node development, there's no harm.
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.
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.
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]
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"
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.
> 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.
Yes, you need to account for that, and potentially make the decision that you should investigate targeting a different engine as the one you develop against. Your infrastructure should absolutely not be set in stone, and this includes looking at different compilers, different javascript engines, and different operating systems. If the most straightforward way of writing your code involves lots of try/catch blocks, then it sounds reasonable that you should target an engine that provides better speed for try/catch blocks.
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.
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.
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!
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.
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...
>>> I don't believe the web is stronger with more rendering engines and more JS runtimes... I think it's weaker
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.
The place for that part of cooperation is the standards bodies. Having good, frequent communication between parties means that everyone can build their own implementation in their own style, yet still have an end product that renders thing the same. One engine may want to focus on raw speed at the cost of memory consumption, one may want the opposite, a third may want to strike a balance, and getting all of those parties cooperating would be like herding cats. So no, competing engines are a good thing, because it results in you being able to choose the best tool for the job, instead of needing to compromise.
> 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
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.
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.
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.
The Node fork JXCore supports Chakra, SpiderMonkey and V8 right now. It's pretty fast, probably because it's based on a pre-0.12 node fork when node was known to be faster than it is presently.
I'd be curious about Nitro/JavaScriptCore (in WebKit). For certain workloads (haste-compiler JS output from compiling Haskell) it performs much better than Chrome or Firefox for me.
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!
I'm wondering is whether ChakraCore will continue emulating V8 APIs into the future?
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."
Chakra only works on Windows. They have on their roadmap plans to work on the interpreter on other platforms, but nothing about getting the JIT running. So I sincerely doubt we'd see a switch.
> 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)
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.
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)
Same reason you should care that there are different web server engines, or that there are different programming languages. ChakraCore has a different set of pros and cons that you should weigh against to figure out what the best engine for your organization is, one of the examples being brought up elsewhere being that it has a better exception handler. One can and should occasionally benchmark against other stacks, or portions of stacks, to see if best practices then match up with current tech.
Fear, Uncertainty, Doubt. Stop spreading those things. The most likely thing to happen if ChakraCore starts getting more popular is that Google ups their game with V8, and the Javascript speed war that made browsers much faster starts hitting server space. Additionally, the entire stack is Free Software. There is absolutely nothing precluding you from pulling a copy of the repo "just in case"
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.
Looks like this is a trolling attempt. The comment was subtly changed and the author, https://github.com/ingIor, is a misspelling of inglor and has no contributions.
This got downvoted? Lighten up HN, it's a joke. The same comment on DN would have gotten a ton of upvotes, and the coldness of HN's lack of humor makes this place really off-putting.
Yeah, and it's actually really anti-intellectual, since a well adjusted person is capable of both humor-depth and logical-depth understanding among many other things.
On the other hand, the subthreads complaining about them inevitably take up more space than the offending comments themselves, and are arguably of less value.
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.
Its not off-topic, embrace extend extinguish is a well documented policy of Microsoft (documented by internal memos that have been in the public domain for some time). Microsoft has been fined massive amounts for anti-trust issues. The web platform is the primary threat to Microsoft's business model since it constantly chips away at the near-monopolies in business and gaming software markets.
Many of the managers and team leads at Microsoft aren't aware of this policy or are in denial, but the people really running the programs are aware of the business reality and affect things like priorities, such as the design goals for this project.
The fact that Hacker News censored my comment is just evidence that Hacker News is in bed with large corporations, or just has no ability to stomach the harsh realities of our imperfect society.
I used to be a Microsoft developer many years ago, until I got a taste of what Microsoft was doing to web development. For the last several years I have been a Node developer.
Microsoft has contributed almost nothing important to Node, and this referenced effort is simply a danger to the Node ecosystem. That is the reality.
Censorship is a big part of the reason that I do not recommend Hacker News to people anymore.
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