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.
"- 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.
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 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.
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.
> 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.
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 ?
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.
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.
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.
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.
...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.
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.
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...
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.
[+] [-] flohofwoe|11 years ago|reply
- 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]
[+] [-] octaveguin|11 years ago|reply
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...
[+] [-] anon1385|11 years ago|reply
The browser vendors are gate keepers. They decide what your code can and can't do inside the very restrictive javascript sandbox.
[+] [-] phaer|11 years ago|reply
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.
[+] [-] micampe|11 years ago|reply
[+] [-] aroman|11 years ago|reply
[+] [-] mateuszf|11 years ago|reply
[+] [-] cheepin|11 years ago|reply
[+] [-] antimagic|11 years ago|reply
[+] [-] ceronman|11 years ago|reply
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...
[+] [-] tragomaskhalos|11 years ago|reply
[+] [-] frozenport|11 years ago|reply
[+] [-] hippich|11 years ago|reply
[+] [-] Mahn|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] lohankin|11 years ago|reply
[+] [-] masklinn|11 years ago|reply
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.
[+] [-] chisophugis|11 years ago|reply
[+] [-] AlexeyBrin|11 years ago|reply
[+] [-] azakai|11 years ago|reply
[+] [-] PudgePacket|11 years ago|reply
[+] [-] overgard|11 years ago|reply
[+] [-] _pmf_|11 years ago|reply
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|11 years ago|reply
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|11 years ago|reply
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 ?
[+] [-] EmmanuelOga|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] mischanix|11 years ago|reply
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.
[+] [-] flohofwoe|11 years ago|reply
(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.
[+] [-] mrec|11 years ago|reply
[+] [-] fiatjaf|11 years ago|reply
[+] [-] vfclists|11 years ago|reply
Or is it in the pipeline?
[+] [-] azakai|11 years ago|reply
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|11 years ago|reply
It's not open, it's locked to legacy languages.
[+] [-] illumen|11 years ago|reply
[+] [-] rtpg|11 years ago|reply
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
[+] [-] Touche|11 years ago|reply
[+] [-] tbrownaw|11 years ago|reply
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|11 years ago|reply
https://github.com/hakimel/reveal.js
[+] [-] pjmlp|11 years ago|reply
I am really betting on Apps, for setting the web straight for interactive documents.
[+] [-] frozenport|11 years ago|reply
[+] [-] spencermountain|11 years ago|reply
[+] [-] skrebbel|11 years ago|reply
[+] [-] latiera|11 years ago|reply
[+] [-] otakucode|11 years ago|reply
[+] [-] dilap|11 years ago|reply
[+] [-] jerf|11 years ago|reply
[+] [-] cbsmith|11 years ago|reply