Slashdot Mirror
Microsoft Open-Sources Its JavaScript Engine Chakra (windows.com)
An anonymous reader writes: As promised, Microsoft has open-sourced the core components of Chakra, the company's JavaScript engine used in Microsoft Edge and Internet Explorer. The project, dubbed ChakraCore, has been released under the MIT License on GitHub. The official blog post reads in part: "The ChakraCore repository provides a fully supported and open-source standalone JavaScript engine, with the same characteristics as the Microsoft Edge’s Chakra engine, to embed in projects, innovate on top of and contribute back to. We will be accepting community contributions and input to ChakraCore. Once the changes from any pull request have been vetted, our goal is to ensure that all changes find their way to be shipped as a part of the JavaScript engine powering Microsoft Edge and the Universal Windows Platform on Windows 10."
The missing bindings are expected. The browser bindings expose Windows APIs into the JS engine within the browser ("standard + extensions"), and the COM bindings on the debug API not being present are there to make it platform agnostic.
The part that I find really amazing is that they are targeting x86, x64, and ARM binary support, with two levels of JIT, with feedback optimization. That's a pretty cool thing to have out there in the wild, under an MIT license:
https://github.com/Microsoft/C...
I think that some of the first contributions need to be buildability support on other platforms, which means CLang/LLVM and GCC support. Ideally, it would handle agnostic conversion from some common representation into both the project build mechanism in Java ("Jenkins"), and Makefiles. Not sure if I'm willing to jump on this, since it would mean a familiarity with both, and I'm not sure they'd accept something like that back (it looks like they specifically picked Jenkins for its cross-platform-ness, even though it adds a Java dependency).
This would enable someone external to Microsoft to run *at least* nightly builds and regression testing for other platforms.
I really have to wonder if it's been thought through, however, to enable people to identify the JavaScript engine, and decide *not* to use the Microsoft specific extensions to the Core platform, so as to keep the things that try to use it portable, or if that's of interest to them. A long time ago, I tried, and failed, to get a common cross-platform ABI adopted, and one of the *key* requirements for it would have been the ability to *turn off* vendor extensions in the runtime, so that you could build cross-platform software targeting it, by causing it to error out when the software used a vendor private API/ABI component.
Without something like that, I fear, it will become an "embrace -- then extend and make incompatible", similar to gcc'isms being incorporated into otherwise portable source code, or the bash extensions to the Bourne shell that resulted in shell scripts actually not being runnable on any shell, but instead only runnable on bash due to bash'isms.
A nice barrier enforcement mechanism that extended up through browser space to enable committing to portability would be nice. Otherwise, when a remote website sent JavaScript content down because of the runtime it though it was hitting, it could include them, unintentionally or no, and non-Microsoft browsers based on the Core implementation would fail to operate.
I'll tell you why those didn't succeed where javascript did - proprietaryness.
Java wanted to be "pure java" where you only wrote Java. Flash and Silverlight were the same, in all cases you had to drink the kool-aid and become one of "them". Javascript was just so boring and crap that the major players ignored it, but as it was there, developers knocked out little bits of code using it until eventually everyone could program javascript but only a third could do Java, a third could do Flash and a third do Silverlight (you get my point, hopefully - nobody became a developer for all three of those competing proprietary platforms)
And so the impetus for each of the big platforms waned while javascript kept growing.
To replace it would have to be a standards thing, and get implemented in every browser and be recognised as better. Not Dart or Typescript or whatever, which are all failing too.
At the very least, a monoculture for anything is bad. So any competitors to V8 are good, especially open source competitors.