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...
It works well in practice depending entirely upon your goals - and depending entirely on your never ever comparing it to ANY other possible solution to the problem.
Well, we've got PNaCl to compare too, which is trying to accomplish similar things.
As an outsider, it sure doesn't seem to be getting as much traction as asm.js or have compelling advantages, though.
I think developers have a tendency to underestimate how important it is to integrate well with your environment, start up quickly, and have a good deployment story. asm.js nails these things.
Compiling to asm.js isn't the same thing as compiling to JS. asm.js is just a funny-serialized bytecode. Someday they can trade it out for a sane serialization and hardly anything will blink.
Worst case, I expect individual compilers will develop their own bytecode serialization format that generates asm.js on the client. There are various reasons to do it already (compression, debug vs release readability/minification concerns, etc) and future revisions of asm.js (like v2, which introduces Java/C#-oriented heap structures) will make it worthwhile.
Compiler -> Bytecode -> Normal JS/ASM.js is the long term strategy for asm support in JSIL, since it will depend on currently-experimental asm features and using asm+polyfills on all browsers would have obscenely bad performance characteristics.
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.
>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.
...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.
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...
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.
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.
Still, considering that the underlying browsers are implemented in C++, I don't think anyone is under the impression that this is some kind of wonderful security feature.
VMs with a direct asm.js compilation mode (like SpiderMonkey) can compile directly to native code (in advance) with the vast majority of the JS attack surface disabled (including heap allocations, for asm.js v1)
In practice it's similar to the way NACL/pNACL can sandbox code due to the limited instruction set & validation guarantees.
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, for example).
So I'd be interested to know what you base this claim on.
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.
> 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.
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.
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.
But that's kind of the whole point of asm.js - it defines a subset of Javascript that is far more optimizable than the full Javascript specification. Do you feel that there are still parts of the asm.js spec that are holding optimisations back? If so, I would be interested to hear your thoughts as to what the problems are.
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.
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...
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? :)
The real-world differences between asm.js and PNaCl are really not that big (basically only whether threads are true POSIX threads, or WebWorkers). Here's a (shameless plug) demo page which has the same demos as emscripten and PNaCl compiled from the same C++ code (warning: most of the PNaCl demos need the latest Chrome Canary): http://floooh.github.io/oryol/
And it looks like that in the future we will have something like JVM and its classloaders. Just with different names (LLVM? v8? RequireJS? JS AMD?) and a lot more kludges. And without Gosling, Joy and Steele.
The history of the web is very much a series of mad hacks and patchups cobbled together to keep the whole thing progressing and evolving - the ultimate "legacy application" if you will; the endearing zaniness of asm.js is just another milepost in this well-trodden road.
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 ?
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.
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:
Not C++ but C, but I did get a basic port of my program info-beamer running in a few hours. It's a C program that's controlled by Lua scripts and renders to OpenGL. The example scene just shows an image that gets modified by a GLSL shader.
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:
- 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.
(I should note that technically, AppCache + bookmarking provides installable web apps, but nobody seems to want to program with AppCache, and bookmarking doesn't really feel like installing an app, which it should.)
Desktop applications with a Web Based UI I think is the way to go. I love Desktop applications, but being able to just open a browser and use an app from my phone or tablet, regardless of whether they're iOS or Android, or whatever is better than developing a full blown native application that doesn't work "everywhere". There's more applications like that, but I leave that fun to others.
What's completely broken about it? If you use it the way it was intended to be used, as a cache for apps, then it works perfectly fine in my experience. It behaves like a native app that updates itself in the background (Chrome itself does this, for example). If you try to use it as a HTTP cache then yes, it's completely the wrong tool for the job and you're gonna have a bad time.
To prevent MITM attacks, Service Workers _require_ HTTPS. HTTPS isn't as accessible as unencrypted HTTP and self signed certs trigger user scarring warning messages. I do think HTTPS is better for privacy to an extent, but unless people can get signed certs for cheaper than their domain name, part of me feels like were only allowing additional web functionality for those able to afford SSL certs. Of course, cheap certs makes this argument null and void. Does anyone have any recommendations?
Also, I think it's been shown that the overhead of encryption isn't that expensive these days.
I have worked with Internet services for many years. I think we have missed quite some opportunity to build great web app platform.
For example, we could package web apps in .apk/.jar package, so they can run like native apps without worrying about missing a resource during offline. JS engine can have more freedom optimizing the code and cache the result.
There is no need to install web app like Chrome Web Store does. All we need is bookmarking and implicit app cache (with smart caching policy). Most people don't use more than 100 apps on regular basis, so 1GB app cache is enough for most people. One major mistake with installable web apps like Chrome Web Store is they often come with security permissions, which defeats major value of web, security and privacy.
Offline can be done with smart API design. For example, browser can let web apps create cache files that sit next to cached .apk and share the same lifespan, then web apps can use sqlite to work with such files for storage. It is essentially the same model as Android/iOS native apps. All these can be done without any app install or security permission. The only risk would be you will lose data if an app is purged during offline, therefore it doesn't have chance to sync the state back to server. If you really about data loss, browser can support pinned apps, so they never get purged by caching policy. That pretty much solves the fundamental problem with web app model.
PS: the usability of JavaScript, web APIs and performance are separate issues. That would also need to solved.
"- 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.
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.
Code signing isn't about cloned apps or privacy violations, it's a mechanism to communicate DISTRUST by revoking it. How does removing that help the consumer?
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.
True, apologies for that. It is because I've been working with iOS and Android longer and take their advantages for granted (although I find it hard to find much nice things to say about C/C++ development on Android). emscripten and the web is still the "new platform" for me.
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.
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.
>you would be basically open-sourcing something that is closed source
From my perspective, reading optimized builds is practically the same as reading assembly. In my opinion, it'd be easier to work from an unstripped mac/linux binary (i.e. with function symbols) than from optimized emscripten output.
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.
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.
Besides performance, the big appeal for me is being able to build largish systems with the sanity-checking and refactoring support provided by strongly typed languages.
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.
99 comments
[ 3.1 ms ] story [ 185 ms ] threadAs an outsider, it sure doesn't seem to be getting as much traction as asm.js or have compelling advantages, though.
I think developers have a tendency to underestimate how important it is to integrate well with your environment, start up quickly, and have a good deployment story. asm.js nails these things.
Compiler -> Bytecode -> Normal JS/ASM.js is the long term strategy for asm support in JSIL, since it will depend on currently-experimental asm features and using asm+polyfills on all browsers would have obscenely bad performance characteristics.
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.
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.
emscripten is pretty cool technology, the paper presenting the tech (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
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.
https://github.com/hakimel/reveal.js
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.
Now you have separate processes for each tab.
Still, considering that the underlying browsers are implemented in C++, I don't think anyone is under the impression that this is some kind of wonderful security feature.
In practice it's similar to the way NACL/pNACL can sandbox code due to the limited instruction set & validation guarantees.
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, for example).
So I'd be interested to know what you base this claim on.
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.
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.
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.
It's not open, it's locked to legacy languages.
I am really betting on Apps, for setting the web straight for interactive documents.
As for Prezi, I had to search for it. No idea it existed.
No thanks, I rather use Powerpoint as well.
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...
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...
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 ?
I myself have modified an emulator to run aswell.
http://www.flohofwoe.net/history.html
"The ffmpeg.js file is around 24.1 MB or so. It ends up being around 6.1 MB gzipped.
The ffmpeg-all-codecs.js file is around 27.5 MB or so. It ends up being around 6.9 MB gzipped."
EDIT: With a fast connection it´s actually not so bad. https://video-funhouse.herokuapp.com/
I imagine it would be possible to generate a smaller version selecting only a subset of features/codecs.
Has someone tried it ?
http://dividuum.de/experiments/info-beamer-js/
- 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...)
- 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/)
- 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]
Mobile web usage went from 20% to 14% according to flurry from 2013 to 2014.
That trend could be reversed with a new movement towards the web, but it seems like it would take quite a trend reversal.
We're stuck with apple- and google- based rent seeking platforms.
http://www.flurry.com/bid/109749/Apps-Solidify-Leadership-Si...
They are working on it, but it is late.
https://github.com/w3c/manifest
(I should note that technically, AppCache + bookmarking provides installable web apps, but nobody seems to want to program with AppCache, and bookmarking doesn't really feel like installing an app, which it should.)
CherryMusic - https://github.com/devsnd/cherrymusic SABnzbd - http://sabnzbd.org/
Desktop applications with a Web Based UI I think is the way to go. I love Desktop applications, but being able to just open a browser and use an app from my phone or tablet, regardless of whether they're iOS or Android, or whatever is better than developing a full blown native application that doesn't work "everywhere". There's more applications like that, but I leave that fun to others.
At least we have the Service Workers spec[0] coming soon, though, which should solve the problem.
[0] https://github.com/slightlyoff/ServiceWorker/
Also, I think it's been shown that the overhead of encryption isn't that expensive these days.
Heer you can find Comodo PositiveSSL Wildcard at $58.36/Year.
For example, we could package web apps in .apk/.jar package, so they can run like native apps without worrying about missing a resource during offline. JS engine can have more freedom optimizing the code and cache the result.
There is no need to install web app like Chrome Web Store does. All we need is bookmarking and implicit app cache (with smart caching policy). Most people don't use more than 100 apps on regular basis, so 1GB app cache is enough for most people. One major mistake with installable web apps like Chrome Web Store is they often come with security permissions, which defeats major value of web, security and privacy.
Offline can be done with smart API design. For example, browser can let web apps create cache files that sit next to cached .apk and share the same lifespan, then web apps can use sqlite to work with such files for storage. It is essentially the same model as Android/iOS native apps. All these can be done without any app install or security permission. The only risk would be you will lose data if an app is purged during offline, therefore it doesn't have chance to sync the state back to server. If you really about data loss, browser can support pinned apps, so they never get purged by caching policy. That pretty much solves the fundamental problem with web app model.
PS: the usability of JavaScript, web APIs and performance are separate issues. That would also need to solved.
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.
For example, see how Firefox OS handles it: https://developer.mozilla.org/en-US/Marketplace/Options/Pack...
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.
The browser vendors are gate keepers. They decide what your code can and can't do inside the very restrictive javascript sandbox.
1. They are a group of vendors instead of a single vendor that can do whatever it wants, and
2. They don't have arbitrary rules that they apply inconsistently, which we see on app stores sometimes
Or is it in the pipeline?
Also, most of the work on it is actually the API and libraries, not the core language, which would have been necessary either way.
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.
From my perspective, reading optimized builds is practically the same as reading assembly. In my opinion, it'd be easier to work from an unstripped mac/linux binary (i.e. with function symbols) than from optimized emscripten output.
(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.
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.