
Emscripten and asm.js: C++'s role in the modern web - ndesaulniers
http://kripken.github.io/mloc_emscripten_talk/cppcon.html#/
======
flohofwoe
There's a couple of points going around in my head which I find interesting /
relevant when it comes to emscripten/asm.js, the web and mobile platforms:

\- asm.js code runs faster then Java code running through the Dalvik VM on
Android ([https://blog.mozilla.org/javascript/2013/08/01/staring-at-
th...](https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-
dalvik-vs-spidermonkey/))

\- porting and cross-compiling code to JS with emscripten is (arguably) easier
then setting up and working with the Android NDK

\- the new Javascript LLVM backend in iOS8 Safari runs asm.js code very well,
and Safari on iOS8 adds WebGL support

\- the web is a the only open software distribution platform without gate
keepers (seriously, this is starting to get ridiculous:
[https://developer.apple.com/app-
store/review/guidelines/](https://developer.apple.com/app-
store/review/guidelines/))

\- web apps don't need all the code-signing and certification hoopla that
native mobile apps need to go through

\- app shops are becoming saturated and have the same or worse visibility
problems as the web even though they are 'curated'

\- you don't pay the 30% platform tax on the web (or rather: you're free to
choose your store front-end)

\- in the end, most successful mobile games need so little CPU and GPU
performance that it really doesn't make a difference whether they run native
or in BASIC, WebGL or Metal

I think that the advantages that a single centralized app-shop offered in the
past over the web have already or will erode very fast once they have to
manage a very high number of apps, basically modern AOLs but with shitty
search engines. The open web is the only way out, even if it just means that
multiple, decentralized app shops will be built on which compete with each
other.

[edit: formatting]

~~~
phaer
"\- web apps don't need all the code-signing and certification hoopla that
native mobile apps need to go through"

You mean that's a good thing? I'd prefer a clear signing process for software
to a web service running its backend on some random server where it's
impossible for me to establish trust.

~~~
fulafel
Google and Apple stores are full of clone apps, privacy violations, and worse.

They still have ad networks and other backend services that the apps
communicate with.

Those conspire to sell your personal info to the highest bidder (or exploit
you in some other creative manner) and have no incentive to do nice by you.

~~~
phaer
Correct, my argument was more about the concepts than the concrete
implementations. I don't use Apples AppStore and I don't like Googles
Playstore, but things like fdroid are quite nice.

------
aroman
This talk just keeps getting more and more relevant:
[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
mateuszf
It may become self-fulfilling prophecy.

------
cheepin
I really wish we had a proper 'web assembly' instruction set to compile to.
JavaScript has proved itself to be a surprisingly adequate language over the
years, but there is only so much optimization you can do with its language
specification.

~~~
ceronman
There is a proper 'web assembly' instruction set. It's Google 's Portable
Native Client [1]. The problem with this solution is that Google is the only
one supporting it. But there other players in the web. Creating such a
standard making all of the vendors happy might be impossible.

ASM.js might not be the perfect solution, but it has the huge advantage of
being compatible with all major browsers. Practicality beating purity is a
common pattern in Web's history.

[1] [http://www.chromium.org/nativeclient/pnacl/introduction-
to-p...](http://www.chromium.org/nativeclient/pnacl/introduction-to-portable-
native-client)

~~~
repsilat
The sandboxing provided by NaCl is nice, but I'm not sure binary portability
is really a worthwhile goal -- I think we really want cross-compilation,
native binaries and the OS providing most of the sandbox.

That way we get maximum performance on the hardware we're targeting (not the
"lowest common denominator" of common bytecodes), an ability to run self-
modifying code if we want to send a JIT down the wire...

~~~
flohofwoe
A bit off-topic, but I would really like to see (P)NaCl apps directly
supported on Android outside the browser, no need to mess with the NDK or
Java. One can dream, right? :)

------
hippich
Shameless plug - I am using Emscripten to compile scrypt miner as a proof-of-
work code at [https://hashcash.io/](https://hashcash.io/)

~~~
Mahn
Interesting idea. Any plans on open sourcing the server as well so as to save
the round trip to verify the proof of work?

~~~
hippich
Not at this time, as it is potential core profit center :)

------
lohankin
There was a recent article on code optimization technique in Safari involving
on-the-fly javascript -> LLVM compilation. So the entire chain now will look
as C++ -> LLVM -> javascript (asm.js) -> LLVM Things are getting curiouser by
the day...

~~~
masklinn
[https://www.webkit.org/blog/3362/introducing-the-webkit-
ftl-...](https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/) for
those who missed it.

The LLVM phase is really an alternative to the existing DFG JIT, and more
precisely to the final phase thereof: the front of the DFG JIT is still used
up to CPS optimisations, then it branches right before codegen: DFG generates
its code directly while FTL converts DFG to SSA, applies SSA optimisations,
converts to LLVM IR and passes the IR to LLVM for codegen.

------
AlexeyBrin
Does anyone know where/if the video of the presentation will be available ?

~~~
azakai
The conference said they would be doing editing on the videos before posting
them, so I assume that will take some time (this talk was today).

------
PudgePacket
Very cool, does anyone here know the compile time differences to clang/gcc?
Does compiling to Emscripten take longer than to binary?

~~~
overgard
It takes a little bit longer, but not a huge amount. Basically the linking
step takes a few more seconds.

------
_pmf_
> Emscripten and asm.js: C++'s role in the modern web

C++'s role in the modern web is that every relevant browser since 1998 is
written in it. It does not need JS wankery to be relevant, thank you very
much.

~~~
72deluxe
Probably true that C++ has always been relevant. But not necessarily in the
minds of web developers - they would not have considered writing C++ for
generating a webpage.

I didn't have a clue about Emscripten; looks really really useful so that I
don't have to think too much about writing in other languages and can write
EVERYTHING in C++. That'd be great.

------
inDigiNeous
Very interested in this technology, would like to see some examples created
with this technology, more than games. Are there any cpu/gpu heavy
applications out there that compile from C++ to asm.js ?

Or any good examples of writing the whole webpage with C++ somehow? All the
current examples I've seen utilize webgl canvas and handle the interaction
there. How about interaction with a regular HTML interface ?

~~~
andrewchambers
There are examples of python and lua interpreters being compiled, a pdf
renderer, graphviz, a 2d physics engine, and a speech synthesizer. you just
need to google it.

I myself have modified an emulator to run aswell.

~~~
flohofwoe
Oh right! I almost forgot another cool side project I did last christmas with
emscripten: use JSMESS to restore some of my old 8-bit games I wrote as kid in
the 80's on an obscure East-German home computer:

[http://www.flohofwoe.net/history.html](http://www.flohofwoe.net/history.html)

------
EmmanuelOga
Hmmm late to the conversation but I always wonder why emscripten focuses so
much on C++, my understanding is that it compiles LLVM IR to javascript, and
clang is used to generate the LLVM IR from C++ in the first place.

Wouldn't it make more sense to market it as llvm-ir-to-javascript compiler?
That way it would be more attractive to users of any language with a llvm
frontend.

------
ascotan
Although this is very cool stuff, I have a hard time trying to understand
where this is going to prove useful.

I would image that the major target for something like this will be in doing
ports of old games to the browser. Anything other than that would seem like a
non-starter.

I'm not sure why a developer would take the long road to write a c++ app with
the intention of eventually converting it to javascript. Also, If your a
company has the expertise you would be basically open-sourcing something that
is closed source. So the business logic doesn't make sense unless you don't
stand to make money on the code.

Maybe i'm not being imaginative enough.

~~~
flohofwoe
There are at least 2 major scenarios where C++ ported to JS is useful:

(1) the web as "just another platform" next to desktop, game consoles and
native mobile apps, the advantage here is that you can use the same code base
for all platforms and only need a small percentage of platform specific code
(about 2% platform specific code from my experience)

(2) cross-compile existing C/C++ middleware libs for use in "traditional" JS
web apps, this has been demonstrated for physics engines (bullet), but would
also work for pathfinding, AI, and other specialized libs

If you're concerned about opening up your precious source code by cross-
compiling to JS, restoring the original code is just as complicated as
restoring from a compiled binary, since the JS code has been generated from
LLVM bitcode, and is additionally minified. You're basically getting a big,
opaque ASCII blob out of an emscripten compile.

The only disadvantage of cross-compiled code is that you get a certain static
size overhead for parts of the C/C++ runtime that gets compiled into the
generated Javascript file which is somewhere between 100 and 300 kByte. This
overhead gets (relatively) smaller the more complex the application is, and
emscripten/LLVM is very aggressive about dead code removal.

So, a small web page which just wants to use some WebGL effects doesn't make
much sense to write in C++, but once you start to write a real game and use JS
libs like three.js (currently at 424kByte minified), the size advantage of
manually written JS quickly disappears.

~~~
wffurr
It's hard to overstate how fantastic (1) is. A single code base for all
platforms is really amazing. C++ is much closer to universal than Python,
Java, etc.

------
fiatjaf
Here's some nice usage of emscripten: [https://github.com/amatus/gnunet-
web](https://github.com/amatus/gnunet-web)

------
vfclists
Why don't/didn't Mozilla implement Shumway in C++ and apply Emscriptem to it?
I thought that would be much easier.

Or is it in the pipeline?

~~~
azakai
I did propose trying something like that, actually, but the people working on
the project preferred to go a different way. It's hard to guess which approach
would be better, each has advantages and disadvantages, and Shumway is in fact
doing well on performance.

Also, most of the work on it is actually the API and libraries, not the core
language, which would have been necessary either way.

------
CmonDev
"Largest open platform in existence"

It's not open, it's locked to legacy languages.

~~~
illumen
Um... not it's not. This article is about using C/C++, and there's dozens of
other languages that work on it, if not hundreds.

~~~
CmonDev
I meant not via hacky work-arounds like transpilation. Proper DOM access etc.
So it is closed.

------
rtpg
OT but I really hate how these sorts of slide decks break the back button.

emscripten is pretty cool technology, the paper presenting the tech
([http://davideglintine-
new.googlecode.com/hg/docs/paper.pdf](http://davideglintine-
new.googlecode.com/hg/docs/paper.pdf)) is actually a really easy read. Cool
stuff.

I hope it doesn't become a norm to try and write "normal" websites in C++,
though things like games do seem to be easier

~~~
Touche
How does it break the back button? Back button works as I would expect it to.

------
tbrownaw
...seriously?? Normal slide decks are annoying enough, but one that doesn't
have the fade ins/outs stripped and progressively adds things instead of
showing the whole screen (er, slide) at once?

WTF happened to usability?

Slides are meant to _support_ a _talk_. Putting everything on the slides,
while it does let you just read from them, gives a bad UX for the talk
attendees. Posting proper (ie, _supporting_ ) slides -- like these appear to
be -- online, gives a bad UX for the online readers. Leaving in transitions
and progressiveness just makes it that much worse.

So what's up with places line HN posting links to online slide decks? They're
a seriously lousy way to communicate. Put some thought into what's appropriate
for the audience -- not just _who_ sees it, but also _how_ they get it.

~~~
drawkbox
It uses reveal.js. You can ESC or Pinch on device to go to the overview, then
click a slide that way as well.

[https://github.com/hakimel/reveal.js](https://github.com/hakimel/reveal.js)

~~~
tbrownaw
...yeah, it's still unreadable even with that tip. :(

------
pjmlp
This just feels wrong.

I am really betting on Apps, for setting the web straight for interactive
documents.

~~~
frozenport
And I kill you if you replace Office 2013 with an app like Prezi!

~~~
pjmlp
Office is an App. I just went into the new fad of calling App to what used to
be called native applications.

As for Prezi, I had to search for it. No idea it existed.

No thanks, I rather use Powerpoint as well.

------
spencermountain
this is a very impressive project; also a humiliation of the field of computer
science.

~~~
skrebbel
Why?

------
latiera
I like how he says 'compiled c++ (to javascript) is immune to buffer
overflows' yet completely sidesteps the real issue at hand: Every major
javascript virtual machine is riddled with security holes. In Firefox case (no
sandbox, no process-per-tab, one of the worst C++ codebases I've ever seen
security-wise, _infested_ with memory leaks and UAFs) these holes can
effortlessly lead to system compromise. In Chrome case, significantly more
work is required.

~~~
nnethercote
> _infested_ with memory leaks and UAFs

Really? That doesn't match my experience -- the full Firefox test suite is run
through ASAN on every check-in. (See the "Linux x64 ASAN" results at
[https://tbpl.mozilla.org/?tree=Mozilla-
Inbound](https://tbpl.mozilla.org/?tree=Mozilla-Inbound), for example).

So I'd be interested to know what you base this claim on.

~~~
Ono-Sendai
I wonder how many functions are suppressed from issuing error reports, if any.

~~~
nnethercote
There are suppressions for LSAN ([http://mxr.mozilla.org/mozilla-
central/source/build/sanitize...](http://mxr.mozilla.org/mozilla-
central/source/build/sanitizers/lsan_suppressions.txt)) and TSAN
([http://mxr.mozilla.org/mozilla-
central/source/build/sanitize...](http://mxr.mozilla.org/mozilla-
central/source/build/sanitizers/tsan_suppressions.txt)). But none for ASAN
that I could find.

I've talked to the person who implemented the LSAN support, and he says that
the LSAN leaks being suppressed are not particularly large.

I also know a person who has recently been running the main test suite through
Valgrind. (We do smoketests with Valgrind on every checkin, but not the full
suite because it's too slow.) He found a few undefined value errors, which
ASAN cannot detect, and which are getting fixed, but no UAFs as far as I know.

~~~
Ono-Sendai
Interesting, thanks! Valgrind is indeed very very slow :) I have tried
'undefined behaviour sanitizer' (part of ASAN project I believe), it's not
bad.

------
otakucode
Compiling to Javascript is nothing short of a mental illness. The perversions
that the terrible design of the web has driven people to are simply
breathtaking...

~~~
macspoofing
Nobody would compile to JavaScript if there was an analogous platform on the
Web. There isn't one.

~~~
otakucode
You are entirely correct on both counts. The fact that we have been driven to
madness by the horrible design of the web does not, in any way, mean that it's
not still madness to do it.

The ultimate goal is to deliver functionality to users. Users don't give a
damn what the platform is. They want application functionality which is as
easy to access as typing an easy to remember name in an address bar. The means
of achieving this goal taken by developers have been convoluted in the
extreme. Each step has its own 'reasonable argument' defending the decision
made, but it still adds up to madness.

~~~
macspoofing
>The fact that we have been driven to madness by the horrible design of the
web does not

I wouldn't characterize it as such. The reality is, we are pretty effin lucky
the Web turned out the way it did. It does it what it does very well. I mean
we have an open platform that every major tech company is on-board with, that
isn't controlled, wholly, by any single one of them, a platform that works on
almost every capable device out there. Those same companies cannot agree on
anything else and are openly hostile to each other in every other space,
except this one. It could have been worse. And future versions of JavaScript
are looking pretty good too!

I'd prefer that HTML/CSS was better designed for building web-applications
(right now it's a Frankenstein that doesn't know whether it wants to be a UI
toolkit or markup for text). I'd prefer a language like Dart or Python to
power web-pages, instead of JavaScript. But oh well.

>The ultimate goal is to deliver functionality to users. Users don't give a
damn what the platform is.

And that's part of the reason why JavaScript sticks around. Users don't care,
and you can get far with JavaScript.

