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."
Not that there is much use to this
It's MIT licensed and they're upstreaming patches to make Node.js work with it. They're also working on cross-platform support. Oh, and Microsoft has a history of being a lot better than Google at maintaining stable APIs (and ABIs). V8 has a nasty habit of breaking everything that's not Chromium by changing public APIs that everyone relies on. If this works well and becomes cross platform, I can see a lot of utility in it.
I am TheRaven on Soylent News
As if you can just commit changes directly to Linux, Apache, MySQL, PHP, PostgreSQL, Android, Firefox, Gnome, KDE etc with no one related to those projects "vetting" them.
Fucking lamest argument against MS doing this...
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.
Install base. JavaScript is installed on almost every PC/mobile platform in existence, and has been in some shape or form for nearly a decade. You can't say the same about iOS, Windows, Python etc.
Sun tried to make Java into a universal platform, Adobe came close with Flash, and Microsoft had a go with Silverlight/.NET. None of these have endured in the same way JavaScript has. Why it did is a complex question.
JavaScript isn't as bad as you might think, but does require a lot of discipline (much like C++) to be done well. It definitely shouldn't be the universal language. I consider it really a high level language builder, rather than a high level language in itself. It is actually quite incredible that some newbie can naively bash out decently structured imperative code using it, while an advanced user creates quite well formed functional stuff. But, like C, the downside of this flexibility is that it is extremely easy to shoot yourself in the foot - something that I don't think should be a characteristic of a high level language.
Anyway, the way things are trending in the JavaScript world, eventually most people won't work directly in JavaScript but use derivative languages (such as CoffeeScript is doing now) better suited to their problem domain, so longer term you'll probably have your wish of developing in Python/C++ and then having that compiled to JavaScript. For now though, if you want the best performance (particular on mobile), you need to be developing in JavaScript and have a reasonable understanding of how the interpreter is working for you.
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.