11 ms·

Big web app? Compile it

philipbjorge 13y ago
The title seems irrelevant. With the exception of frameworks like Ocsigen/Eliom[0] and Dart[1] (Eliom being the closest thing to what the presentation hints about), I've never seen any production web apps that have been compiled from languages like Ruby, Python or C (I don't consider desktop applications like Banana Bread a web app). Lack of frameworks and best practices for DOM manipulation seem to be roadblocks. The presentation didn't list any examples of web apps written in other languages, so I'm forced to conclude that if I have a big web app, compiling it is not the most sensible option. [0] http://ocsigen.org/overview/eliomapplications http://ocsigen.org/overview/eliomapplications [1] http://www.dartlang.org http://www.dartlang.org
- jmillikin 13y ago
  > I've never seen any production web apps that have been > compiled from languages like Ruby, Python or C Ever used Google Groups or Docs? https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/
  - nijk 13y ago
    Groups is certainly not a production quality web app.
  - philipbjorge 13y ago
    I have used them and didn't know this was how they were implemented. Very cool. Thanks for dropping the knowledge.
garysweaver 13y ago
It would be a good idea to provide the following info in presentations like this: 1. URL to the source code for the tests and instructions to run the tests to produce the same results. 2. The hardware, OS version(s), and browser versions that were tested. Otherwise, the difference between Chrome and FF performance as listed in the slides is so great that it seems like it would quickly raise criticism, even though I personally like FF.
- azakai 13y ago
  I should put in a more direct link, yeah. But basically those numbers are the emscripten benchmark suite, get the code and run tests/runner.py benchmark The numbers are very dated by now, btw. Real-time information is here: http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench http://arewefastyet.com/#machine=11&view=breakdown&suite=asm...
jared314 13y ago
"Big web app? Compile it (To Javascript)" would be a better title. The presentation is confined to cross-compiling languages (C, C++, Java, Ruby, Lua, etc) to javascript and asm.js. The last ten, or so, slides actually has some content about the trade offs. My personal opinion is that most of the benefits from "compiling to asm.js" seem to be just removing the JS dynamic types and applying known compiler optimizations.
natch 13y ago
Nice presentation. Curious, why was WebKit/Safari excluded from the comparisons? Or is WebKit the engine in some of these browsers and it just didn't seem necessary to include it? I assume these results are applicable to mobile as well, where WebKit is pretty big as I understand it.
- deleted 13y ago
  [deleted]
- wtetzner 13y ago
  Webkit is a layout engine, not a JavaScript implementation. Also, Chrome uses WebKit.
- azakai 13y ago
  Hi, I wrote that presentation. The reason that I usually compare Firefox and Chrome and not others is basically because Firefox and Chrome are easy to test. It's very simple to get the shell versions of the two browsers' JS engines, build them, and run them, and benchmarking in the shell is much simpler than otherwise. In contrast: * Internet Explorer is Windows-only. I run Linux. There are some free VMs now, but you can't benchmark in a VM, it would be unfair. Also, even on Windows, I am not sure if Chakra has a shell version (does it?) * Safari is OS X only (and again, I run Linux). JSC, its JS engine, has a shell version. This would be great, but the only way to build it on Linux is apparently to build the Qt-WebKit port of WebKit (whereas apparently on OS X it is very simple). I've tried a few times to follow guides on how to do that, and it always fails somewhere in their dependencies. Not sure if the guides are wrong or if something in my distro's Qt deps is not a proper match. A few projects do embed JSC, and are easy to build on Linux, but the snapshots are dated - to benchmark I really want the very latest code, or else it would be unfair to JSC. (Btw, if there is a simpler way to build JSC on Linux, I would really like to know!) I do sometimes benchmark those two, but it means finding a machine I can borrow for that purpose, which takes time, so it is rare. (And I don't benchmark Opera because they are moving to V8, which I already benchmark anyhow.)
  - asveikau 13y ago
    > Also, even on Windows, I am not sure if Chakra has a shell version (does it?) I am not big on javascript but this question sparked my interest to google it. Apparently, and this is if I parse this correctly, if you apply the .reg file from this StackOverflow answer you can run chakra from cscript.exe which runs js from the command line: http://stackoverflow.com/questions/7167690/what-is-the-progid-or-clsid-for-ie9s-javascript-engine-code-named-chakra/7168837#7168837 http://stackoverflow.com/questions/7167690/what-is-the-progi... - however without this registry hack you'll get some other engine.
pathikj 13y ago
As a Tizen developer, this comes really to close to what I was looking for. Investors.. get your checks ready. :)
PommeDeTerre 13y ago
I'm somewhat disappointed with how this presentation portrays rather negative things as being positive in some way. It's not encouraging or enticing in any way for me to learn that I can compile my C and C++ to JavaScript, and it'll be "just 2X slower than native code" (but not until "later this year"). I don't consider that an accomplishment. Having to use at least twice the processing power to get the same result isn't something to laud, for example. It's wasteful, not beneficial. It surely shouldn't be something to be proud about. As an industry, we need to be moving forward. This means doing better than the best we already have. It does not mean only doing things half as well as we can already do, and pretending that we've somehow done something impressive.
- exit 13y ago
  performance isn't the only dimension along which things can move forward
  - PommeDeTerre 13y ago
    Improvements in runtime performance often translate directly to significant benefits in other areas, too. That's why it's one of the most important things to improve upon. Faster program execution means better CPU utilization. More processing resources becomes available for other uses sooner, or fewer resources are needed to begin with. Faster program execution means better memory utilization. A program that finishes faster holds memory for a shorter amount of time, freeing it up for other uses sooner. Faster program execution means saving more energy, as a given amount of work can be completed using less processing effort. Faster program execution means a better user experience, which means more satisfied users. Faster program execution means the users can be more productive, as they're not waiting as long for processing to complete. Runtime performance may even be the most important factor to improve upon, given how it impacts so many other factors.
- bradtgmurray 13y ago
  Half the speed of native, but you're not comparing apples to apples. This slower code is also run in an environment where it's safe to download a random blob from the internet and just start running. This comes at some cost.
laurent123456 13y ago
This presentation seems to be missing the point. It's about "web apps" so presumably JS apps running in the browser, however as far as I know you cannot access the DOM from ASM.js code, so creating a JS app is not going to be easy. Then there's the "small problem" of having to develop this in C++, which means you don't have access to all the nice new frameworks that are being developed - AngularJS, emberJS, etc. and have to deal with the joy of dangling pointers, memory leaks, slow compilation time, etc. (even though you might not even need the speed benefit of C/ASM.js). That makes development time a lot longer for no obvious benefits. And of course, there's also the nightmare of debugging cryptic ASM.js code in the browser if something doesn't work. I can see the point of ASM.js for games or apps where very high performance is required but for web apps I'd rather stick to regular JS.
- chii 13y ago
  if you are writing yet another TODO/agile trello/twitter clone, the hard parts isn't in the programming, and ASM.js (and compiling in general) doesnt concern you at all. The beauty of this form of programming is in being able to port large, existing code bases to new platforms with "relative" ease. This doesn't only apply to games (which in large part is the main reason for such things), but to things like a torrent implementation in the browser for example. Or, peer to peer chat ala skype in the browser, all without having to use a centralized server. Applications such as those is difficult write from scratch, but if a porting mechanism exists, it could be a boon to the amount of things you can do online now.
  - laurent123456 13y ago
    I agree with that, but the presentation makes it look like C++ + EMScripten is almost a drop-in replacement for writing large web applications. Even for very large web applications front-ends like Gmail, AMS.js is probably still not a good solution. It's for very specific use cases, where high performance is needed, and not as simple as "Big web app? Compile it".
    - neilxdsouza 13y ago
tantalor 13y ago
The bananaBench link 404s, http://kripken.github.io/mloc_emscripten_talk/banana/benchmark.html http://kripken.github.io/mloc_emscripten_talk/banana/benchma... Forgot to copy it to gh-pages?
tantalor 13y ago
See also http://langlangmatrix.com/ http://langlangmatrix.com/
nnq 13y ago
Why would you even think of compiling C or C++ to Javascript for any "big web app"? You may have a graphics engine that will be made like this, but definitely not the rest of your app... This is the realm of Dart and TypeScript and maybe others, but not of C++ -> Javascript compilers!
- neilxdsouza 13y ago
  My survey compiler compiles surveys to c++. Using emscripten I was able to compile and run the survey in a browser. You can include a web framework - I used Dojo and got it to work quite easily. I then used Dojo mobile - and was able to get that to work to (but may need some tweaking as Im neither a JavaScript nor Dojo Expert). I am able to easily access the DOM and I am able to pass data back to my c++ functions too (responses to the survey to be stored). However it's not ASM.js that is the novelty for me, but being able to target the browser with almost the same c++ runtime code.
ZenoArrow 13y ago
Was just wondering, what was used to put together this presentation? Any open-source tools or libraries?
- samspenc 13y ago
  Exactly what I was going to ask. Really impressive HTML5 slidedeck!
- tjohns 13y ago
  Looks like it was built using reveal.js: https://github.com/hakimel/reveal.js https://github.com/hakimel/reveal.js If you want a nice GUI tool, Slid.es (http://slid.es http://slid.es) will get you some thing similar. But it's not open source.
  - ZenoArrow 13y ago
    Thank you tjohns!
SunboX 13y ago
Is there some way to compile "normal JavaScript" to "asm JavaScript"?
- pepve 13y ago
  http://stackoverflow.com/questions/15626611/can-regular-javascript-be-converted-to-asm-js-or-its-only-to-speed-up-statical http://stackoverflow.com/questions/15626611/can-regular-java...
Roboprog 13y ago
Well, I thought this was pretty cool. Apparently you can mix in regular, UI oriented, Javascript with specialized library routines "compiled" from other languages that use the fast asm.js subset. I would not start an entire project like this, but if I discovered I had a computationally bound chunk of code on the browser side, this looks like a nice tool to pull out and attack the problem -- recode the "hot spots" in (emulated) C. Is there a FreePascal front end? :-)
joshguthrie 13y ago
Am I the only one completely unfazed by this? This seemed like a cool thing, I looked into it a little bit more wondering "How are graphic API calls translated? What about filesystem calls in browser? How do I manipulate the DOM?" and delighted of a new world that would open to me. And I ended up on my answer: https://gist.github.com/jgranick/5430948 https://gist.github.com/jgranick/5430948 Sure, that is pretty tame CPP code, nothing too hard. And then I looked at the JS demonstration and Chrome decided to give 120MB of RAM to displaying a triangle. Okay, Chrome may be slow sometimes, things happen,... curl --silent http://www.joshuagranick.com/examples/simplegl/SimpleGL.js | wc -l 125018 Oh shit. Well, right. The whole "CPP2JS" boilerplate is there. I won't even entertain the thought of reading past the first screen of 125K lines of computer-generated source code so I'm gonna ask: what is the point to this? There is no native "manipulate the DOM" function in CPP that could be translated to the original JS one and it takes me 125 thousand lines to draw a triangle: what can we gain from this? Don't tell me "speed", my computer lost it on I/O alone.

The title seems irrelevant. With the exception of frameworks like Ocsigen/Eliom[0] and Dart[1] (Eliom being the closest thing to what the presentation hints about), I've never seen any production web apps that have been compiled from languages like Ruby, Python or C (I don't consider desktop applications like Banana Bread a web app). Lack of frameworks and best practices for DOM manipulation seem to be roadblocks. The presentation didn't list any examples of web apps written in other languages, so I'm forced to conclude that if I have a big web app, compiling it is not the most sensible option. [0] http://ocsigen.org/overview/eliomapplications http://ocsigen.org/overview/eliomapplications [1] http://www.dartlang.org http://www.dartlang.org

jmillikin 13y ago
> I've never seen any production web apps that have been > compiled from languages like Ruby, Python or C Ever used Google Groups or Docs? https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/
- nijk 13y ago
  Groups is certainly not a production quality web app.
- philipbjorge 13y ago
  I have used them and didn't know this was how they were implemented. Very cool. Thanks for dropping the knowledge.

garysweaver 13y ago

It would be a good idea to provide the following info in presentations like this: 1. URL to the source code for the tests and instructions to run the tests to produce the same results. 2. The hardware, OS version(s), and browser versions that were tested. Otherwise, the difference between Chrome and FF performance as listed in the slides is so great that it seems like it would quickly raise criticism, even though I personally like FF.

azakai 13y ago
I should put in a more direct link, yeah. But basically those numbers are the emscripten benchmark suite, get the code and run tests/runner.py benchmark The numbers are very dated by now, btw. Real-time information is here: http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench http://arewefastyet.com/#machine=11&view=breakdown&suite=asm...

jared314 13y ago

"Big web app? Compile it (To Javascript)" would be a better title. The presentation is confined to cross-compiling languages (C, C++, Java, Ruby, Lua, etc) to javascript and asm.js. The last ten, or so, slides actually has some content about the trade offs. My personal opinion is that most of the benefits from "compiling to asm.js" seem to be just removing the JS dynamic types and applying known compiler optimizations.

natch 13y ago

Nice presentation. Curious, why was WebKit/Safari excluded from the comparisons? Or is WebKit the engine in some of these browsers and it just didn't seem necessary to include it? I assume these results are applicable to mobile as well, where WebKit is pretty big as I understand it.

deleted 13y ago
[deleted]
wtetzner 13y ago
Webkit is a layout engine, not a JavaScript implementation. Also, Chrome uses WebKit.
azakai 13y ago
Hi, I wrote that presentation. The reason that I usually compare Firefox and Chrome and not others is basically because Firefox and Chrome are easy to test. It's very simple to get the shell versions of the two browsers' JS engines, build them, and run them, and benchmarking in the shell is much simpler than otherwise. In contrast: * Internet Explorer is Windows-only. I run Linux. There are some free VMs now, but you can't benchmark in a VM, it would be unfair. Also, even on Windows, I am not sure if Chakra has a shell version (does it?) * Safari is OS X only (and again, I run Linux). JSC, its JS engine, has a shell version. This would be great, but the only way to build it on Linux is apparently to build the Qt-WebKit port of WebKit (whereas apparently on OS X it is very simple). I've tried a few times to follow guides on how to do that, and it always fails somewhere in their dependencies. Not sure if the guides are wrong or if something in my distro's Qt deps is not a proper match. A few projects do embed JSC, and are easy to build on Linux, but the snapshots are dated - to benchmark I really want the very latest code, or else it would be unfair to JSC. (Btw, if there is a simpler way to build JSC on Linux, I would really like to know!) I do sometimes benchmark those two, but it means finding a machine I can borrow for that purpose, which takes time, so it is rare. (And I don't benchmark Opera because they are moving to V8, which I already benchmark anyhow.)
- asveikau 13y ago
  > Also, even on Windows, I am not sure if Chakra has a shell version (does it?) I am not big on javascript but this question sparked my interest to google it. Apparently, and this is if I parse this correctly, if you apply the .reg file from this StackOverflow answer you can run chakra from cscript.exe which runs js from the command line: http://stackoverflow.com/questions/7167690/what-is-the-progid-or-clsid-for-ie9s-javascript-engine-code-named-chakra/7168837#7168837 http://stackoverflow.com/questions/7167690/what-is-the-progi... - however without this registry hack you'll get some other engine.

pathikj 13y ago

As a Tizen developer, this comes really to close to what I was looking for. Investors.. get your checks ready. :)

PommeDeTerre 13y ago

I'm somewhat disappointed with how this presentation portrays rather negative things as being positive in some way. It's not encouraging or enticing in any way for me to learn that I can compile my C and C++ to JavaScript, and it'll be "just 2X slower than native code" (but not until "later this year"). I don't consider that an accomplishment. Having to use at least twice the processing power to get the same result isn't something to laud, for example. It's wasteful, not beneficial. It surely shouldn't be something to be proud about. As an industry, we need to be moving forward. This means doing better than the best we already have. It does not mean only doing things half as well as we can already do, and pretending that we've somehow done something impressive.

exit 13y ago
performance isn't the only dimension along which things can move forward
- PommeDeTerre 13y ago
  Improvements in runtime performance often translate directly to significant benefits in other areas, too. That's why it's one of the most important things to improve upon. Faster program execution means better CPU utilization. More processing resources becomes available for other uses sooner, or fewer resources are needed to begin with. Faster program execution means better memory utilization. A program that finishes faster holds memory for a shorter amount of time, freeing it up for other uses sooner. Faster program execution means saving more energy, as a given amount of work can be completed using less processing effort. Faster program execution means a better user experience, which means more satisfied users. Faster program execution means the users can be more productive, as they're not waiting as long for processing to complete. Runtime performance may even be the most important factor to improve upon, given how it impacts so many other factors.
bradtgmurray 13y ago
Half the speed of native, but you're not comparing apples to apples. This slower code is also run in an environment where it's safe to download a random blob from the internet and just start running. This comes at some cost.

laurent123456 13y ago

This presentation seems to be missing the point. It's about "web apps" so presumably JS apps running in the browser, however as far as I know you cannot access the DOM from ASM.js code, so creating a JS app is not going to be easy. Then there's the "small problem" of having to develop this in C++, which means you don't have access to all the nice new frameworks that are being developed - AngularJS, emberJS, etc. and have to deal with the joy of dangling pointers, memory leaks, slow compilation time, etc. (even though you might not even need the speed benefit of C/ASM.js). That makes development time a lot longer for no obvious benefits. And of course, there's also the nightmare of debugging cryptic ASM.js code in the browser if something doesn't work. I can see the point of ASM.js for games or apps where very high performance is required but for web apps I'd rather stick to regular JS.

chii 13y ago
if you are writing yet another TODO/agile trello/twitter clone, the hard parts isn't in the programming, and ASM.js (and compiling in general) doesnt concern you at all. The beauty of this form of programming is in being able to port large, existing code bases to new platforms with "relative" ease. This doesn't only apply to games (which in large part is the main reason for such things), but to things like a torrent implementation in the browser for example. Or, peer to peer chat ala skype in the browser, all without having to use a centralized server. Applications such as those is difficult write from scratch, but if a porting mechanism exists, it could be a boon to the amount of things you can do online now.
- laurent123456 13y ago
  I agree with that, but the presentation makes it look like C++ + EMScripten is almost a drop-in replacement for writing large web applications. Even for very large web applications front-ends like Gmail, AMS.js is probably still not a good solution. It's for very specific use cases, where high performance is needed, and not as simple as "Big web app? Compile it".
  - neilxdsouza 13y ago

tantalor 13y ago

The bananaBench link 404s, http://kripken.github.io/mloc_emscripten_talk/banana/benchmark.html http://kripken.github.io/mloc_emscripten_talk/banana/benchma... Forgot to copy it to gh-pages?

tantalor 13y ago

See also http://langlangmatrix.com/ http://langlangmatrix.com/

nnq 13y ago

Why would you even think of compiling C or C++ to Javascript for any "big web app"? You may have a graphics engine that will be made like this, but definitely not the rest of your app... This is the realm of Dart and TypeScript and maybe others, but not of C++ -> Javascript compilers!

neilxdsouza 13y ago
My survey compiler compiles surveys to c++. Using emscripten I was able to compile and run the survey in a browser. You can include a web framework - I used Dojo and got it to work quite easily. I then used Dojo mobile - and was able to get that to work to (but may need some tweaking as Im neither a JavaScript nor Dojo Expert). I am able to easily access the DOM and I am able to pass data back to my c++ functions too (responses to the survey to be stored). However it's not ASM.js that is the novelty for me, but being able to target the browser with almost the same c++ runtime code.

ZenoArrow 13y ago

Was just wondering, what was used to put together this presentation? Any open-source tools or libraries?

samspenc 13y ago
Exactly what I was going to ask. Really impressive HTML5 slidedeck!
tjohns 13y ago
Looks like it was built using reveal.js: https://github.com/hakimel/reveal.js https://github.com/hakimel/reveal.js If you want a nice GUI tool, Slid.es (http://slid.es http://slid.es) will get you some thing similar. But it's not open source.
- ZenoArrow 13y ago
  Thank you tjohns!

SunboX 13y ago

Is there some way to compile "normal JavaScript" to "asm JavaScript"?

pepve 13y ago
http://stackoverflow.com/questions/15626611/can-regular-javascript-be-converted-to-asm-js-or-its-only-to-speed-up-statical http://stackoverflow.com/questions/15626611/can-regular-java...

Roboprog 13y ago

Well, I thought this was pretty cool. Apparently you can mix in regular, UI oriented, Javascript with specialized library routines "compiled" from other languages that use the fast asm.js subset. I would not start an entire project like this, but if I discovered I had a computationally bound chunk of code on the browser side, this looks like a nice tool to pull out and attack the problem -- recode the "hot spots" in (emulated) C. Is there a FreePascal front end? :-)

joshguthrie 13y ago

Am I the only one completely unfazed by this? This seemed like a cool thing, I looked into it a little bit more wondering "How are graphic API calls translated? What about filesystem calls in browser? How do I manipulate the DOM?" and delighted of a new world that would open to me. And I ended up on my answer: https://gist.github.com/jgranick/5430948 https://gist.github.com/jgranick/5430948 Sure, that is pretty tame CPP code, nothing too hard. And then I looked at the JS demonstration and Chrome decided to give 120MB of RAM to displaying a triangle. Okay, Chrome may be slow sometimes, things happen,... curl --silent http://www.joshuagranick.com/examples/simplegl/SimpleGL.js | wc -l 125018 Oh shit. Well, right. The whole "CPP2JS" boilerplate is there. I won't even entertain the thought of reading past the first screen of 125K lines of computer-generated source code so I'm gonna ask: what is the point to this? There is no native "manipulate the DOM" function in CPP that could be translated to the original JS one and it takes me 125 thousand lines to draw a triangle: what can we gain from this? Don't tell me "speed", my computer lost it on I/O alone.