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.
Everyone here tries hard to look "smart".
I don't try to look smart at all. I am smart and so don't need to try.
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.
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.
Google use a lot of Java, I believe. That probably has something to do with it.
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…
> 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.
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…
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 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.
Dont be silly. 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.
> Dont be silly.
While not silly is existing at the whim of a single commercial vendor's browser decisions?
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
>> 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: No…
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.
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"
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.
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).
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.
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.
Dont be silly. 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.