
Bringing asm.js to the Chakra JavaScript engine in Windows 10 - bpierre
http://blogs.msdn.com/b/ie/archive/2015/02/18/bringing-asm-js-to-the-chakra-javascript-engine-in-windows-10.aspx
======
corysama
Prior to asm.js I spoke out against Mozilla's hard stance that making JS
faster was the _only_ option -as opposed to making a whole new VM or at least
working to make PNACL more portable.

But, this here is exactly why I changed my tune. The primary advantage of
asm.js is not technical. It's political. It would work without requiring Apple
or Microsoft to take _any stance at all_. The big, slow, stubborn players did
not need to be convinced to make any investment of any form. And once it
worked, it would not be embarrassing or risky for them to join the party late.

And, here is the evidence that asm.js is working where no other option would.
I look forward to the day when we can move on from JS to a better-designed VM.
But while I wait, I'll be satisfied for a while with asm.js (once the SIMD
support goes mainline).

~~~
camgunz
I have doubts about asm.js. I'm not super informed so I might be wrong, feel
free to correct me :)

1\. I don't know how helpful open source is if that source is inscrutable. The
JS generated by Emscripten isn't super useful.

2\. The only reasonable way to use a non-JS language with asm.js is to use
Emscripten to compile its runtime or compile a "native" binary. One of the
arguments against PNaCl is that you basically need to use Google's
implementation. While the tie-in with asm.js is for developers, whereas the
tie-in with PNaCl is for users, I think it's tie-in nonetheless.

3\. asm.js is billed as an 'open platform', but it's still limited to
platforms that can run browsers with asm.js optimizations implemented. The
number of these platforms, when you consider phones, consoles, appliances, and
legacy platforms, is pretty small. They can also ill-afford a 50% speed
decrease. Since this is basically Windows, Mac OS X, and Linux, your native
applications are going to work just fine on those platforms. Sure you might
have to do some platform abstracting, but not tons, and especially little if
using something like Unity.

~~~
azakai
> Since this is basically Windows, Mac OS X, and Linux, your native
> applications are going to work just fine on those platforms.

But, you need people to download and install your app in that case. The reason
major game companies are investing in asm.js ports, even though their engines
work great natively, is because the web is a very good distribution platform.
That's really all there is to it - no one controls the web, there's no charge
to ship a game there.

~~~
camgunz
The web is a great distribution platform for one subset of applications (news,
email, social, etc.) and a bad distribution platform for basically all others.
Pixlr is a great example; GIMP will do everything Pixlr does, faster, and
without a network connection (yeah load time is bad, but that's a GIMP-
specific problem). GIMP doesn't have to pay any money, other than hosting
(which an asm.js application also would have to pay) to distribute their app.
I can use GIMP without downloading it every time. I can also continue to use
GIMP if/when its developers decide to give up. When Pixlr's developers give
up, it's gone for good.

I also think pouring millions of man hours into a transpiler and JavaScript
engine optimizations is probably the least efficient and most convoluted way
to take advantage of the web as a distribution platform. I think the way this
should all be framed is, "it would be better if browsers supported a lower-
level bytecode, or more languages, or both, but that's politically impossible
to achieve, so we have asm.js". That's the only thing that makes sense to me
here.

------
realityking
Apparently Google's toying with the idea of using "use asm" as a signal to opt
into TurboFan[1]. While not the AOT compilation envisioned by the asm.js
creators, it speaks to the importance asm.js has already gained.

That said, personally I'd rather see time spend optimising the new ES6
features so they can be used without a big performance hit.

[1]
[https://code.google.com/p/v8/issues/detail?id=2599#c77](https://code.google.com/p/v8/issues/detail?id=2599#c77)

~~~
cpeterso
Mozilla tracks TurboFan performance on its "Are We Fast Yet?" benchmarks.
TurboFan is clearly a work-in-progress because it is not scoring well on the
common JS benchmarks:

[http://arewefastyet.com/](http://arewefastyet.com/)

~~~
reissbaker
To be fair, the arewefastyet benchmarks are intentionally very broad, and
stress test many different parts of a JS engine. It may be the case that
TurboFan has a very fast sweet spot for numeric code (which would explain why
they'd want to use it for asm.js), but is slower for the more general cases.

I'd be interested to see how TurboFan performs on individual test cases; for
example, Octane has several asm-specific tests, and based on their planning I
wonder whether TurboFan is faster than Crankshaft for those individual tests
even if it's slower for the rest of them.

~~~
bzbarsky
You can see breakdowns for various subtests on awfy. Of possible interest are
[http://arewefastyet.com/#machine=28&view=breakdown&suite=asm...](http://arewefastyet.com/#machine=28&view=breakdown&suite=asmjs-
ubench) and
[http://arewefastyet.com/#machine=28&view=breakdown&suite=asm...](http://arewefastyet.com/#machine=28&view=breakdown&suite=asmjs-
apps) as well as
[http://arewefastyet.com/#machine=28&view=breakdown&suite=oct...](http://arewefastyet.com/#machine=28&view=breakdown&suite=octane)

~~~
reissbaker
Huh super interesting. It looks like currently TurboFan is competitive
w/Crankshaft on the asm.js benchmarks, and much, much slower on everything
else. I wonder if the V8 team expects TurboFan to someday beat Crankshaft on
the asm benchmarks, given current perf differences.

------
gitaarik
Nice, now that Firefox, Chrome and IE will support it, I think asm.js will
become available in most serious browsers, which is a great thing.

It will be interesting to see what kind of impact it will have. For example,
will asm.js eventually take over traditional web development? Theoretically,
you can compile any compiled language to asm.js, so you'll have a lot more
choice for the language you want to use to create your webapps. It won't
really be web though: no markup, no links, but yeah, with the current heavily
based javascript apps that's also debatable. Also asm.js still has a lot of
limitations and disadvantages that won't make it just as easy yet.

~~~
jerf
"For example, will asm.js eventually take over traditional web development?
Theoretically, you can compile any compiled language to asm.js, so you'll have
a lot more choice for the language you want to use to create your webapps."

I've outlined this progression before, which seems obvious to me, but I
haven't seen anyone else discuss it.

    
    
        1. Get asm.js into every browser.
        2 or 3. Observe that asm.js is very verbose, define a simple
                binary bytecode for it.
        3 or 2. Figure out how to get asm.js decent DOM access.
    

The last two can come in either order.

And the end result is the language-independent bytecode that so many people
have asked for over the years. We just won't get there in one leap, it'll come
in phases. We in fact won't be using Javascript for everything in 20 years
[1], but those of you still around will be explaining to the young bucks why
certain stupid quirks of their web browser's bytecode execution environment
can be traced back to "Javascript", even when they're not using the
increasingly-deprecated Javascript programming language.

[1]: [https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
adamnemecek
I think that eventually we might ditch DOM and use WebGL or canvas or
something instead of it, like on the desktop.

~~~
RussianCow
You use WebGL to create standard GUI applications on the desktop? WebGL and
canvas are in no way replacements for the DOM.

~~~
adamnemecek
E.g. Mac OS X uses OpenGL to render GUI, I guess I should have made myself
more clear.

> WebGL and canvas are in no way replacements for the DOM.

That's kind of debatable. If you have access to a fast graphics layer from the
browser, you can build a DOM replacement of sorts. I think that famo.us works
kind of like that.

~~~
pavlov
It's true that OS X uses OpenGL for GUI compositing, but that's only the
lowest level. Above, there's a very important piece of the GUI stack called
Core Animation which provides layer compositing.

Core Animation is used by both the native GUI as well as the browser DOM. When
you use layer-backed compositing on a web page (e.g. CSS 3D transforms),
WebKit implements it with a Core Animation layer. So DOM-based rendering
enjoys the same benefits of GPU-accelerated compositing as native apps --
although obviously with rather different semantics since HTML+CSS doesn't map
directly to Core Animation.

If you implement your own GUI framework on top of WebGL or Canvas, you're not
getting Core Animation compositing for free, so you need to replicate that
functionality in your custom framework. (This applies equally to native apps:
a WebGL app is equivalent to a Cocoa app that renders everything into a single
OpenGL view, and a HTML Canvas app is equivalent to using a single
CoreGraphics view.)

I don't think the WebGL/Canvas route makes sense for most apps other than
games and highly visual 3D apps. You'll just spend a huge amount of time
building your own implementations of all high-level functionality that is
already provided by the OS and/or the browser: layer compositing, text layout,
view autosizing, and so on. If you're doing standard GUIs, why go to all that
trouble?

~~~
RussianCow
> You'll just spend a huge amount of time building your own implementations of
> all high-level functionality that is already provided by the OS and/or the
> browser

Not only that, but you can't make a 100% guarantee that your implementation
will look and work exactly the same as the native one on the underlying OS.
For instance, I can re-create all the native Windows UI controls and re-
implement all their behavior in exactly the same way, but what if the user has
a custom theme installed? Everything breaks. (WPF has a similar problem.)

------
h43k3r
I don't know why but I am starting to like Microsoft. Things seems to have
changed quite a lot in the past 6-12 months. .Net going open source ,new web
browser spartan, CM acquisition are some of the things.

~~~
aikah
Never forget that the core product of Microsoft is Windows, and most of people
are forced paying a new license with each new computer. So any decision MS
makes is,as an ultimate goal to sell windows licenses. Today there is a
consensus on Open Web Techs. Nobody can tell if it will still be the case 5
years from now.

~~~
jongalloway2
Latest financials here:
[http://www.microsoft.com/Investor/EarningsAndFinancials/Earn...](http://www.microsoft.com/Investor/EarningsAndFinancials/Earnings/FinancialStatements/fy15/q2/SegmentRevenues.aspx)

It's a little tricky to read the Windows impact since (as I read it) it falls
into both Commercial Licensing (for business sales) and Devices and Comsumer
(for consumer sales). Some articles which break it down a bit:

[http://www.anandtech.com/show/8936/microsoft-q2-fy-2015-fina...](http://www.anandtech.com/show/8936/microsoft-q2-fy-2015-financial-
results-8-revenue-gain)

[http://arstechnica.com/business/2015/01/hardware-
surprisingl...](http://arstechnica.com/business/2015/01/hardware-surprisingly-
strong-windows-weak-as-microsoft-posts-solid-q2/)

So while the exact percentages aren't obvious, the big picture is that Windows
is definitely significant, but Microsoft has become a lot more than Windows.

[I work for Microsoft until they notice I'm wasting time on Hacker News and
"fix the glitch".]

------
nwienert
Would be cool to see TypeScript compile to asm.js, would open up some cool
optimizations for hybrid development.

Seems like there was some discussion[1].

[1]
[http://typescript.codeplex.com/discussions/438243](http://typescript.codeplex.com/discussions/438243)

~~~
ndesaulniers
I've been playing around with compiling small subsets of JS to C++, then
running it back through emscripten.

It works, but you have to keep the subset small, otherwise you end up
implementing a meta circular interpreter. The problem will be that the subset
is never the subset that pleases everyone. When your implementation doesn't
support one person's code, it's labeled 'crap', and the negative cheerleading
begins.

------
ethana
Who's putting their bets on Microsoft going open source with Trident and
Chakra next? Spartan is an opportunity for them to clean up the mess before
releasing the codes I think.

~~~
quonn
At least for Chakra, this would make a lot of sense - I can't think of a
downside for them. For Trident there is the theoretical downside that IE
becomes fully independent of Windows. This currently doesn't matter, but might
decrease lock-in in the future.

~~~
higherpurpose
Windows dependency of IE is one of the worst things about IE - like having to
restart your PC to update your browser. What year is this again?

~~~
integraton
The fact that it was stagnant, ubiquitous, limited to Windows, and encouraged
ActiveX were the major issues, since it made it more difficult and expensive
to develop and transition to web applications for about a decade.

------
josteink
Nice to see Mozilla provide some good, portable standards, as opposed to
Google with their own "native client" ActiveX-like nonsense.

I honestly just see Google retiring NPAPI-plugins as a way to push their own
non-standard, at the cost of all other browsers. I'm glad to to see that's not
winning them any wars.

~~~
camgunz
All of Google's development of NaCl and PNaCl is open source. The only thing
stopping other browser vendors from working on it is themselves.

It's also worth pointing out (being maybe just a bit too pedantic) that asm.js
isn't a standard. It's a subset of ECMAScript, which is a standard, and
Mozilla has published a spec for it. The spec is more how to use asm.js, not
how to implement asm.js optimizations. I'm not saying this is bad, but if
you're arguing that Google's stance is, "hey here's the code for PNaCl and how
to use it, good luck!", you can't argue that Mozilla's stance is any
different.

~~~
josteink
While what you're saying can't be said to be "incorrect", it isn't the full
story either.

What Google did was in-house, behind closed doors, develop a solution, embed
it in Chrome, push it out in production, and start using it according to their
own specs right away.

Then they told other browser makers "Hey. Here's a neat ActiveX-like idea,
which kinda makes the web platform-specific again, which you will have no say
in how is implemented, because it's already in production, and unless you
implement it as we see fit (and will continue to in the future), exactly as
fits our browser-model and code (although it may not fit yours). Take it as is
or we will be discriminating your browser on our web-services". And so they
did.

It may not be proprietary by definition, but it's not "open" by a mile either.

Counter that with what Mozilla did: They proposed a way to make highly
optimizable code-sections even faster, machine-code fast, in a backwards-
compatible, web-friendly and portable way and invited people to join in. Those
who didn't, would not suffer a lock-out, but those who joined could benefit
from the work already done.

I don't think there's any point even _pretending_ that these two actors are
playing on the same moral level here. Google is acting scumbaggy and everyone
but apologists knows it.

------
MisterWebz
Does this mean we'll soon have mobile web apps that rival native apps in terms
of performance or will DOM manipulation still slow everything down?

~~~
untog
JS is already plenty fast, it's just the DOM manipulation that screws it up.
But asm.js with direct access to a <canvas> tag, WebGL or not, would probably
be interesting.

~~~
natmaster
Which is why ReactJS native is so compelling.

~~~
untog
And React Canvas: [https://github.com/Flipboard/react-
canvas](https://github.com/Flipboard/react-canvas)

------
riquito
Other languages compilers/interpreters may be compiled in asm.js and let us
program in something different than Javascript (e.g.
[https://github.com/replit/empythoned](https://github.com/replit/empythoned)
). Is this realistic?

------
munificent
I feel like I must be missing something but I fundamentally don't get why
people are so excited about asm.js.

Does the web really need more people manually managing their memory? Do they
not get that that's what asm.js is? It has no GC.

~~~
tree_of_item
I mean, you must know that applications with particularly high performance
requirements can't afford a GC.

asm.js is really about trying to turn the "web" in to a true runtime for
applications and a direct competitor to "closed" ecosystems like iOS.

------
itsbits
Would be cool to see TypeScript compile to asm.js, would open up some cool
optimizations for hybrid development.

Seems like there was some discussion[1].

[1]
[http://typescript.codeplex.com/discussions/438243](http://typescript.codeplex.com/discussions/438243)

------
perdunov
asm.js + WebGL allow to completely skip the web stack making the browser just
another platform of execution.

Strangely or not, C/C++ strike back.

------
elcct
I think since IE6 Microsoft should be banned from touching anything related to
the internet.

