
Big web app? Compile it - rogerfernandezg
http://kripken.github.io/mloc_emscripten_talk/
======
PommeDeTerre
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.

~~~
vidarh
Half as slow as native _IS_ a large step forward. It isn't twice the
processing power to get the same result, it is twice the processing power to
be able to deploy the same app across vastly more platforms than you would be
likely to target without it, and using languages that means you can easily
target your main platforms with native builds should you choose to.

That's what you are missing. Nobody has the resources to build native versions
for every available platform, and it means a lot of useful tools and fun stuff
is entirely unavailable to large groups of users.

The accomplishment is that we're now close to having a platform that makes
most code usable in a much more portable environment. And it's twice as slow
_now_ ; performance will continue to improve.

By your argument, are you writing everything in assembler? Because modern
compilers still leave a lot to be desired and are nowhere near achieving
maximal performance.

For starters, they create a ton of stack frames that are unnecessary if you
hand-tune an assembly program.

Yet most of us don't program assembly anymore for a reason: It is rarely worth
the time.

~~~
Tloewald
Yes but javascript is a higher level language than C++, so it's more like
advocating programming in 680x0 assembler and compiling it to C because the
tools for 680x0 development are awesome and it runs almost half as fast as
handwritten C.

------
laurent123456
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
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
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
It might be on a case to case basis, but for me C++ and Emscripten was an
almost drop in replacement. My survey compiler uses ncurses, wxWidget/gtk and
web toolkit for native screen display.

I read the emscripten documentation that you could call pure javascript and
pass data back from javascript too. I wondered if you could use Dojo as a
widget library replacement for native toolkits like wxWidgets etc. I tried it
out and was able to get things working in 2-3 days. And I'm not good at
Javascript and have not really tried Dojo before either. I was able to get
Sencha to work, but not Sencha Touch. Dojo mobile is working fine as well (but
I have to tweak it).

The novelty is not asm.js but using the browser as a Windowing System and a
JavaScript library as your UI library. The survey compiler is open source and
if you are interested in getting started I and point you to the relevant
sources.

What Emscripten enables me is open up the tablet space for surveys with hardly
any effort using toolkits like Phonegap.

------
philipbjorge
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

      > 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/)

~~~
philipbjorge
I have used them and didn't know this was how they were implemented. Very
cool.

Thanks for dropping the knowledge.

------
joshguthrie
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.

------
garysweaver
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
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=asm...](http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-
ubench)

------
natch
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.

~~~
azakai
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
> 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-progi...](http://stackoverflow.com/questions/7167690/what-is-the-progid-
or-clsid-for-ie9s-javascript-engine-code-named-chakra/7168837#7168837) \-
however without this registry hack you'll get some other engine.

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

~~~
tjohns
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
Thank you tjohns!

------
nnq
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
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.

------
Roboprog
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? :-)

------
jared314
"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.

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

~~~
pepve
[http://stackoverflow.com/questions/15626611/can-regular-
java...](http://stackoverflow.com/questions/15626611/can-regular-javascript-
be-converted-to-asm-js-or-its-only-to-speed-up-statical)

------
tantalor
The bananaBench link 404s,

[http://kripken.github.io/mloc_emscripten_talk/banana/benchma...](http://kripken.github.io/mloc_emscripten_talk/banana/benchmark.html)

Forgot to copy it to gh-pages?

------
tantalor
See also [http://langlangmatrix.com/](http://langlangmatrix.com/)

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

