Hacker News Reader

These are real concerns. Asm.js is not a perfect solution. I am not Alon Zakai, but I'll try to answer to the best of my understanding.

1. Asm.js is not an alternative for a hypothetical high-performance, human-readable language in the browser. Ex: It's not competing with the idea of a C#-in-HTML JIT compiler. It is competing with Silverlight -where the browser is already downloading inscrutable binaries.

2. Emscripten has so far received the most man-years of effort, but the idea of other systems using asm.js as a compilation target is very attractive and it's not so difficult as to be a huge barrier for competition. For example https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/ (for a specific benchmark, after jit warmup). Personally, I'm excited about the idea of hooking the emscripten backend into http://terralang.org/ Terralang is a system for building custom, high-performance languages on top of LLVM.

3. Asm.js runs on any standards-compliant JS interpreter with no special support required. Even if the interpreter ignores the "use asm" directive, you can expect to see speed benefits simply from the fact that asm.js code is JS in a style that is easy to JIT very well. In order for phones, consoles, smart TVs ect... to fully benefit, it will of course require the platform holders to put in the effort to respond to "use asm". "Open Platform" doesn't mean "Works perfectly before the platform holder even implements it" ;) Also, Asm.js is not targeted to compete with native, installed executables. It is just trying to get the capabilities of HTML apps on all platforms to be closer to those of native executables.

1. The point I was making is that a lot of asm.js proponents argue that compared to PNaCl, asm.js isn't a binary blob, and is easier to examine and modify. While I agree this is true, I'm not sure how much it matters; it's still very hard to read and work with Emscripten-generated asm.js code. You can write it by hand for improved readability, but that's not a lot of fun either.

I disagree that asm.js isn't trying to implement '<script type="text/lua">', and is only interested in unseating Silverlight/Flash. Alon Zakai argues for asm.js becoming the bytecode format of the web, and advocates for compiling the runtimes of other languages to JS using Emscripten.

2. I read about PyPyJS a while ago, the way it works is by compiling the PyPy interpreter into JavaScript using Emscripten. I don't think you'll ever see TerraLang ported because it relies on LuaJIT. AFAIK, every large user of asm.js uses Emscripten, because asm.js is such a bear to work with manually. That's fine, but to me (again), lock-in is lock-in. I'd be really surprised to see a non-LLVM solution crop up.

3. I think "runs" implies some level of acceptable performance. Try running asm.js code in IE, for example. Even in browsers that have a lot of optimizations (asm.js-specific and not), performance varies between 1.5x-2x of Firefox', and 3x-4x of native code (http://arewefastyet.com/#machine=29&view=breakdown&suite=asm...). This is still impressive theoretically, but pragmatically that's a huge performance hit. It's also important to remember these are very current browsers on very current platforms, and you're assuming a lot of other things, a fat network pipe to download a huge JS blob among them.

For example, I could run a PlayStation emulator on my phone and barely get a proper framerate. If you put this same emulator in asm.js using Emscripten, it would run half as fast at best (in Firefox), and we haven't addressed all the other problems with HTML5: skipping audio, high latency on input (mouse, controllers), networking performance, etc.

Or for another example, let's say I can play Call of Duty 5000 on my new PC at 60 FPS. Handwaving a lot, let's also say I can play Monster Madness on the same PC at 30 FPS, because of the 50% drop due to asm.js. But let's also say I bought a laptop a couple years ago that runs CoD 5k at 30 FPS, but Monster Madness runs at an unplayable 15 FPS. You can argue, "just run the native version!". But at that point, why am I bothering with asm.js at all? To avoid installations? While that can be important, I'm not sure it's worth millions of man hours and dollars.

(I know Monster Madness is nowhere near as demanding as a hypothetical Call of Duty 5000 would be, but I hope you get the point I was trying to make)

To summarize, asm.js enables zero-install, sandboxed, cross-platform applications at a huge technical price (even though you're technically installing the app every time you load it up, caching excepted of course). I'm not at all convinced we can't achieve the same goals in a much simpler way.

---

Finally, we haven't even begun to discuss the security implications of running untrusted software that can be modified in transit. I know it's kind of a rabbit hole (computers aren't born with all the software you need installed, it has to come from somewhere). But I do think when we're talking about communications applications, banking applications, the potential insecurity of zero-install apps is troubling.

> 1. I don't know how helpful open source is if that source is inscrutable. The JS generated by Emscripten isn't super useful.

People ship nonfree, minified JavaScript all the time, and "open source" doesn't mean "only distributed in the form preferred for modification". I don't see how this is unique to asm.js, or even that important: you can just put a link back to the "real" (e.g. C++) source in a comment on the page you serve.

I agree. I've seen asm.js proponents argue that, compared with PNaCl for example, asm.js isn't a binary blob. Maybe not technically, but I think it's hard enough to work with Emscripten-generated asm.js that it may as well be, and it's hard enough to write a large application in asm.js that you probably want to use C/C++ and transpile it to JS with Emscripten. That's the only point I was trying to make.

I do think you've hit on something though:

> People ship nonfree, minified JavaScript all the time

I know, and I think it's dangerous for software freedom if the apps we start depending on are all closed-source web services, where we're at the mercy of the owners. Vendor lock-in is vendor lock-in, no matter the distribution channel, and zero-install isn't worth it.

I am getting the sense that you think asm.js has some troubling interaction with software freedom and I just don't agree with that at all. Whether or not the code you receive is free software is orthogonal to whether or not it's been run through a compiler.

Emacs is free software and people typically download a binary to use it. Is that dangerous somehow? The source code is in a well known location.

I agree that it is troubling that nonfree JavaScript is shipped all the time, but again, that happens every day without asm.js being involved, and asm.js does not help or hinder this.

I get what you're saying. My counter-argument is that because asm.js is being pushed as a distribution platform for "desktop" apps, and web services are so rarely open source, software freedom stands to take a hit.

The main reason free software saw such adoption was that it was very high quality software available for free. Most people aren't even aware of the philosophy and history behind it, nor would they base their decision on what software to use on that philosophy and history.

Web services aren't covered by free software licenses, but they generally have no cost, are sandboxed, and you don't have to install them (even though you're actually "installing" them a lot, just in the background). For almost all users, that's a huge win, but for free software, that's a huge loss.

asm.js enabled many more classes of software to run in this environment, and I think that's a big looming negative for software freedom. I love Mozilla and I think what they do is amazing on almost every level. But the web is more than just a browser and JavaScript. There's 65k ports and dozens (hundreds?) of protocols. There's no need for the battle for the open web to take place only in the browser space.

> Since this is basically Windows, Mac OS X, and Linux, your native applications are going to work just fine on those platforms.

But, you need people to download and install your app in that case. The reason major game companies are investing in asm.js ports, even though their engines work great natively, is because the web is a very good distribution platform. That's really all there is to it - no one controls the web, there's no charge to ship a game there.

Very true and so very close to what I think is Microsoft's true motivation: Office. Viewed through the prism that Office is Microsoft's cash cow and the criticism that the Office version available online in browser is limited, like Google Docs is limited (there's at least one feature that doesn't work given a large enough set of features from Word...), asm.js makes perfect sense.

Perhaps Microsoft will tier their products in a different way. A Office 360 subscription (or whatever it is branded) will get you access to Office, running in a browser, under asm.js. Perhaps they'll do something different. Sooner or layer, however, the Microsoft embrace of this technology will be monetized.

There are side-effects. Microsoft can sell tools that now run a tranpiler to put executables on the web. They might or might not use LLVM to that end.

This development means that asm.js has become a defacto standard. It is too soon to tell if this will be more widely adopted, as defacto standards fail al the time. I think, however, that this one will stand. Quite likely we all are now going to be freed and constrained by small design decisions made long before this adoption came to pass.

The web is a great distribution platform for one subset of applications (news, email, social, etc.) and a bad distribution platform for basically all others. Pixlr is a great example; GIMP will do everything Pixlr does, faster, and without a network connection (yeah load time is bad, but that's a GIMP-specific problem). GIMP doesn't have to pay any money, other than hosting (which an asm.js application also would have to pay) to distribute their app. I can use GIMP without downloading it every time. I can also continue to use GIMP if/when its developers decide to give up. When Pixlr's developers give up, it's gone for good.

I also think pouring millions of man hours into a transpiler and JavaScript engine optimizations is probably the least efficient and most convoluted way to take advantage of the web as a distribution platform. I think the way this should all be framed is, "it would be better if browsers supported a lower-level bytecode, or more languages, or both, but that's politically impossible to achieve, so we have asm.js". That's the only thing that makes sense to me here.

1. Open Source is about licensing of the original source-code, not about compiled binaries - the JS generated by Emscriten isn't any more useful than the JS generated by Uglifier or Google Closure. And for debugging, that's why we have Source Maps.

2. ASM.js is for low level code, the kind of code that doesn't do garbage collection. As far as high-level languages go, Javascript has pretty good performance, is very flexible and can be used as a target by compilers without necessarily needing ASM.js. Examples of languages that are very different from Javascript, but with compilers targeting Javascript and doing it quite well - http://www.scala-js.org/ ; https://github.com/clojure/clojurescript

I personally do not get why developers would want PNaCl, as PNaCl will never be a standard, for the same reason SQLite never made it as a standard storage in HTML5 either. If you want anything other than what the browser standards are capable of, then you're free to go native - because here we can have a discussion about why the browser as a platform has gotten so ubiquitous in the first place ;-)

3. You're mistaken - Asm.js compiled code can run even in browsers that do not have special support for Asm.js. Yes, that code will be slower, less efficient, but it still runs. Also, what limitations does Asm.js has that prevent it from being implemented on all platforms?

Actually, on your point #3, it will most likely run faster than regular JS on those non-asm.js optimizing browsers, as most browsers have JS engines that perform some kind of optimization, optimizations that serendipitously work quite well on asm.js code.

Slower than an asm.js-optimizing browser, faster than idiomatic JS.

1. I agree, but one of the arguments for "use JavaScript and not ActiveX/Flash/Java" is that those are binary blobs. I think Emscripten-generated asm.js is bad enough that it doesn't gain you a lot compared to a blob.

2. Well if they don't target asm.js, I'm not sure how relevant they are to our discussion. They're going to get faster as JavaScript engines become more optimized. I tried the Scala.js benchmark, and at 1000x1000 and 1 pixel, it took over 10 seconds to render the scene. I don't know what that means, but it felt slow. I can't find comparisons of Scala/Clojure in JavaScript to Scale/Clojure on the JVM, if you know of some, can you point me there?

PNaCl won't be a standard because of politics. Technologically, it's superior.

3. It "might" run. If you depend on WebGL you can kiss IE support goodbye, for example. Also "run" ought to come with some sort of baseline performance. Let's say you can run Windows XP via Emscripten. Don't you agree that the attendant speed decrease means that, while it may "run", it's not very useful if you can't really use it?