
Bringing ChakraCore to Linux and OS X - bevacqua
https://blogs.windows.com/msedgedev/2016/07/27/chakracore-on-linux-osx/
======
bevacqua
To everyone thinking we already have V8 - competition is necessary for the
ecosystem not to go stale. For it to thrive, we need competition.

Just look at JavaScript. Dozens of libraries that do the same thing, a vibrant
ecosystem as a result.

~~~
Klathmon
For example, in V8 a try/catch statement triggers the whole function to be
deoptimized [1]

Chakra and SpiderMonkey fully optimize these functions even with a try/catch
statement (according to 2 devs last time I talked about this [2]).

Without alternate engines, people start to think that implementation details
in one engine apply to javascript as a whole.

Just look around at most javascript "performance tips". Most of them talk
about how you should avoid try/catch in performant code, even though it's only
one engine that doesn't optimize it, and they have talked about how they want
to fix it, but just haven't [3].

And that's just one example, there are hundreds of examples of bugs,
performance tricks, and even differences in spec interpretation that can cause
issues and can inadvertently become a "standard" without multiple competing
engines.

[1] More accurately, the function will never be optimized in the first place
if it contains a try/catch at all since Crankshaft doesn't support try/catch.

[2]
[https://news.ycombinator.com/item?id=10896729](https://news.ycombinator.com/item?id=10896729)

[3] IIRC they haven't devoted time to optimizing it because the architecture
of V8 doesn't work well with something like try/catch, but also because it's
fairly simple to work around, and most people already do. So you kind of get a
catch 22 where V8 won't spend time to fix it because it's not worth it, and it
won't be worth it because V8 doesn't support it.

~~~
avar

        > Most of them talk about how you should avoid try/catch in
        > performant code, even though it's only one engine that doesn't
        > optimize it
    

That still sounds like great advice even though it's "only" slow on one
engine. Very few performant JS applications have the luxury of not worrying
about how Chrome performs, as opposed to only IE, Firefox & Safari.

~~~
Analemma_
The problem is that perf tips have a strong tendency to become "cargo cult
knowledge" that keep getting passed around even though no one knows the
original reason for their existence, or that they have long since stopped
applying. This has been a problem in the C world for ages, and now it looks
like it's coming to JavaScript as well. Even if Google were to fix this issue
tomorrow, we'd probably still see programmers in 2025 writing convoluted code
to avoid try/catch because "it's bad for performance, I heard that somewhere".

If Microsoft had released Chakra around the same time, it never would've been
an issue, because people would've known "Oh, this is just Google's bug",
gotten on their case to fix it, and it would've been gone a long time ago.

~~~
magicalist
> _If Microsoft had released Chakra around the same time, it never would 've
> been an issue, because people would've known "Oh, this is just Google's
> bug", gotten on their case to fix it, and it would've been gone a long time
> ago._

But this is the exact situation that the browser world is in (V8 is only one
vendor among many) and that hasn't come to pass.

------
zwetan
Having different engine is good, even "non-obvious" ones

If you look at the sources of TypeScript you can see it supports: Node.js,
Windows Script Host and ChakraHost (see [1])

I made a little experiment to support another engine: the ActionScript Virtual
Machine (AVM2) which not only support ActionScript 3.0 but also JavaScript
(see [2])

Personally it's not that I don't like Node.js, but I do like the idea to take
the JS sources of some command-line tool and bundle them in one independent
executable to then distribute it as a deb package or Mac OS X pkg etc. without
having to first install node.js/npm

[1]:
[https://github.com/Microsoft/TypeScript/blob/master/src/comp...](https://github.com/Microsoft/TypeScript/blob/master/src/compiler/sys.ts)

[2]: [https://discuss.as3lang.org/t/the-case-when-you-dont-want-
no...](https://discuss.as3lang.org/t/the-case-when-you-dont-want-node-js/307)

~~~
skratlo
It's all about resource efficiency. If you do that (bundle), you're not
resource efficient (memory), but the resulting solution is easy to use (no
dealing with dependency conflicts where A depends on X-v1 and B on X-v2, and
you need A and B running in the same system). How important is resource
efficiency, and what it even means today vs. yesterday varies wildly.

~~~
zwetan
I experienced different results.

One of the main problem with JS engines is that they load external code on
demand, even with something like JSDB (see [1] based on SpiderMonkey engine)
where you can bundle all of your JS inside a zip that you then bundle/merge
with the runtime, the JS files still have to be extracted from the zip and
loaded "as file" from memory.

In the case of the AVM2, wether the files are AS3 or JS they are first
compiled to bytecode (like Java) and that's what you bundle with the runtime,
the bytecode still have to be loaded but it is "one big file", so wether your
sources are many 100s of JS files it does not matter.

That matter a lot for the resource efficiency, and it influence a lot the
memory footprint (~10MB for AVM2, ~50MB for a Node.js, see [2]), eg. the more
files you load the more memory you gonna use.

For the dependencies conflict yep it make things easier too, not only for the
versioning of libraries as you describe but also for the versioning of the
runtime itself, eg. runtime v2 could be installed system wide but your self-
contained exe could use an older runtime v1.

[1]: [http://www.jsdb.org](http://www.jsdb.org)

[2]:
[https://github.com/eclipse/kura/wiki/Footprint](https://github.com/eclipse/kura/wiki/Footprint)

------
aravindet
This is good news for a healthy Node.js ecosystem, but I can't see what’s in
it for Microsoft. V8-based Node.js works fine on Windows and Azure, so they
don’t need this to attract Node.js developers and the npm ecosystem to their
platform.

Are there any theories about how this (presumably substantial) investment
makes business sense for MS?

~~~
niftich
It's a hedge against Google.

Google, through V8, Chromium, Chrome, Chrome OS, Android, and Dart, has a
large say in the future of the web platform, browsers, apps, the future of
Javascript, etc.

Time and time again, Google has used their substantial influence and market
share to make unilateral decisions affecting the web platform
[1][2][3][4][5][6]; the individual merits of each decision notwithstanding,
Google can do just about anything and it will affect enough of the userbase
that others must compensate or follow suit.

By offering an alternative to V8 monoculture, they can protect against Google
using its influence to drive the Javascript platform in its own direction.

[1] SHA1 sunset: [https://security.googleblog.com/2014/09/gradually-
sunsetting...](https://security.googleblog.com/2014/09/gradually-sunsetting-
sha-1.html)

[2] NPAPI discontinuation: [https://blog.chromium.org/2014/11/the-final-
countdown-for-np...](https://blog.chromium.org/2014/11/the-final-countdown-
for-npapi.html)

[3] Block Flash by default:
[https://groups.google.com/a/chromium.org/forum/#!searchin/ch...](https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-
dev/HTML5$20by$20default/chromium-dev/0wWoRRhTA_E/__E3jf40OAAJ)

[4] Chrome ignoring autocomplete=off:
[https://bugs.chromium.org/p/chromium/issues/detail?id=468153...](https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164)

[5] VP9 available in WebRTC:
[https://developers.google.com/web/updates/2016/01/vp9-webrtc...](https://developers.google.com/web/updates/2016/01/vp9-webrtc?hl=en)

[6] H.264 in WebRTC still gated behind a flag:
[https://bugs.chromium.org/p/chromium/issues/detail?id=500605](https://bugs.chromium.org/p/chromium/issues/detail?id=500605)

~~~
kuschku
#5 and #6 are even worse, because it basically means Google can dictate
whatever terms onto you, if you develop a competing browser.

As VP9 is heavily patented, and the license only allows you to use it if you
don't ever sue Google, you're out of luck if Google ever fucks you over
somewhere else.

~~~
themihai
The alternative is worse(H.264)

~~~
kuschku
H.264 is worse, but at least it's available with pretty straightforward
license terms (just pay).

VP.9's license might actually violate antitrust laws.

~~~
vetinari
> H.264 is worse, but at least it's available with pretty straightforward
> license terms (just pay).

That's pretty much discriminating against a wide range of software - namely
Free and Open Source. VP9 on the other hand, is compatible with a such
development model.

~~~
kuschku
Sure, yet VP9 is discriminating against about every startup with innovative
patented algorithms that also wants to support VP.9

At the example of Pied Piper from SiliconValley: If they used VP.9 for video
encoding before compressing and sending it, Google/hooli would now have the
right to use their (potentially) patented algorithm for whatever they want,
without ever getting sued.

Now that's great, eh?

~~~
vetinari
The VPx cross-license does not work that way.

You are granted patents to use VPx (you can not use these patents outside VPx
scope) and you are granting patents necessary to use VPx[1]. If you have some
other patents that are not necessary for the VPx, they are not subject of the
cross-license.

[1] - "that must necessarily be infringed by the act of Exploiting Licensed
Products in the Licensed Field of Use"

------
kogir
I've not tried recent versions of node but have had to port things like
Brendan Gregg's flamegraph tools from node to other languages because node
would die with even pedestrian memory use (well under 4GB).

Does anyone know if ChakraCore has better memory management? Could be a big
win for longer running applications or those that simply need a larger working
set.

------
duaneb
Does this indicate a desire to bring Edge to macOS/Linux? Finally some more
browser competition!

~~~
hellojs
[disclosure - I work for MSFT] It's only ChakraCore that is going cross-
platform at the moment, and existing platform support matrix for Microsoft
Edge remains unchanged now. That said, we'd welcome input from developers and
users who want to see Edge on the platform of their choice.

Limin

edit - typo

~~~
dhritzkiv
One reason for Edge on other platforms: not having to spin up a Windows
virtual machine or boot up a PC for cross-browser testing.

~~~
pyre
It's possible for there to be _platform_ -specific bugs / quirks even in the
same engine.

~~~
dimal
True, but if you could do day to day testing without a VM, even running
automated tests against it, that would be a huge timesaver. Then you fire up
the VM once a week (or some reasonable interval) to confirm it's 100%. There
are platform specific bugs, but most issues I see now with Chrome or Firefox
are specific to the browser, not the platform.

------
stonewhite
What does ChakraCore bring on to the table V8 currently doesn't? Can someone
elaborate?

~~~
azakai
All JS engines make different tradeoffs, so they are better at some things
compared to other engines.

For example, Chakra has had full asm.js optimization support for a long time
now, while v8 still doesn't (but it's coming).

We now have 4 high-quality JS engines that are cross-platform and open source
(v8, SpiderMonkey, JavaScriptCore, and now Chakra). This is great!

------
tombert
This is interesting enough, I suppose, but I think they should have included
some kind of interesting benchmark where Chakra outperformed V8 or something
for Node.

~~~
hiteshk_msft
Thanks for the suggestion, great idea! However, it's really early days for us
still- as the blog post mentions, we are still working on implementing the JIT
and concurrent GC which are quite important to awesome performance. When we
complete that work, we'd definitely keep a close eye on current industry
benchmarks

~~~
tombert
Heh, I didn't actually think an actual MS developer would respond to my
comment.

As it stands, I can appreciate what MS is doing; you guys aren't probably
going to compete with or replace V8 or SpiderMonkey on Linux overnight, hence
why getting a working Node port is a good first step of presumably many.

Regardless, this is definitely an interesting step; it would be really trippy
if I end up using an entire MS stack on my Linux desktop, but it appears that
might be a legit possibility.

------
purohitpavan
Super

------
xutopia
What's the point of this exactly? Why would someone chose this over V8?

~~~
nitinreddy88
Why would someone buy Benz when there is BMW. Every engine is better in some
aspect and suffer in another aspect. There is already benchmark link provided,
which already prooves one reason to choose over V8.

