Big web app? Compile it | Hacker News Reader

Big web app? Compile it

kripken.github.io

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.

performance isn't the only dimension along which things can move forward

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.

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.

Also, I think the argument that "slow" isnt moving us forward is just not thinking the issue entirely through. Most people writing code today would not be if not for slower (and more human understandable) languages.

Why dont we just remove all keys from a developer's device besides 0s and 1s so they can program in the fastest computer language!

but if it comes at a 10x productivity boost it's worth it.

So where exactly does the "10x productivity boost" come from in this case?

It's the same C and/or C++ code being compiled in both cases. It doesn't become any easier to write said code, just because it's compiled down to a mangled form of JavaScript rather than a native binary.

he might e thinking of writing another language, which he's comfortable with, vs javascript - for portability

I'm not sure if this is what rtpg was referring to, but... In this case, the 10x productivity would come from suddenly being able to use C/C++/other code that can be compiled to asm.js, which was previously not useful for client-side web apps unless you rewrote it by hand into JavaScript.

You're optimizing for the wrong resource.

Computers serve humans, not the other way around. That means that unless you're optimizing for something that benefits people, you're probably making things worse.

So yeah, if a program is just the same but is twice as slow in a way that harms user experience, then sure, that's bad. But if a program uses twice the CPU but is easier to develop and deploy, that's a win.

For example, if somebody uses the technology to make MAME and its library available in every browser in the world, then that's great, because somebody just enabled a hell of a lot of fun.

Sure, they could try to get everybody in the world to download and install a native copy and save a bunch of CPU time that wasn't going to get used anyhow. But that'd be a big waste of human life, a much more precious resource than CPU time.

twice the cpu kills the battery on mobile/tablet => it is harming user experience.

Instead of trying to be native in a browser just be native on the plateform you bring the product. The web is not good for everything.

Neither is native.

And frankly, if your app is actually worth something, you should have a web version. Not everyone can afford a shiny new iPhone. And that does a thing far worse than harm the UX. It prevents those that would benefit most from using the app.

You make it seem like the battery life is the only thing that matters.

Depends on how much CPU you're using. Any app that is using a lot of CPU on a phone will kill the battery regardless.

So I agree that if you're doing something where using 2x CPU will make a significant difference and you've already optimized things heavily, then sure, go native. But I'm sure that most apps on my phone are already using 2x the CPU they could be, and I just don't care.

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.

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.

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.

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.

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

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.

Of course, yes, I didn't mean that compiling C++ is good for web apps in general. Just for a small subset like certain games and so forth.

Btw, you can access the DOM from compiled C++ (and asm.js), for example

http://kripken.github.io/mloc_emscripten_talk/qcon.html#/33

but again, I would not recommend that for general apps. It's useful when you do need to quickly do something in the DOM though, and you are actually writing something that benefits from compiling C++.

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 [1] http://www.dartlang.org

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

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

Thanks for dropping the knowledge.

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

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.

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.

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

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.

Webkit is a layout engine, not a JavaScript implementation. Also, Chrome uses WebKit.

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

> 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... - however without this registry hack you'll get some other engine.

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

Exactly what I was going to ask. Really impressive HTML5 slidedeck!

Looks like it was built using reveal.js: https://github.com/hakimel/reveal.js

If you want a nice GUI tool, Slid.es (http://slid.es) will get you some thing similar. But it's not open source.

Thank you tjohns!

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!

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.

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

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

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

http://stackoverflow.com/questions/15626611/can-regular-java...

The bananaBench link 404s,

http://kripken.github.io/mloc_emscripten_talk/banana/benchma...

Forgot to copy it to gh-pages?