This is not the case at all - there are loads of use cases outside of games, and some of them have more straightforward dependencies (e.g. no graphics or networking). Take a look at Alon Zakai's github [1] where there are some examples of various libraries compiled to the web which include physics engines (ammo.js, box2d, cannon.js), database engines (SQLite), programming language VMs (lua, j2me), parsers (xml.js) and more (LLVM, clang, zlib, GMP, image/audio/video decoders...)

In some cases these are more-or-less drop-in replacements. For example I've pretty straightforwardly dropped in asm.js compilations of Box2D and zlib and gotten massive performance improvements over the handwritten versions with minor effort. In the Box2D case, it was so good we integrated the result in to a commercial product (Construct 2). I think it's also a compelling idea to be able to support new image and audio formats on the web at native-like speeds without requiring browser support, e.g. compiled WebP or Ogg Vorbis decoders.

I think the author has simply not done enough research around uses of compiling to the web to recognise its immense value.

[1] https://github.com/kripken?tab=repositories

Since these are garbage collected languages, wouldn't it make more sense compile to plain JavaScript, treating that as VM-bytecode, and avoid doing things that slows down JavaScript VMs?

Other semantic differences might also make this hard or impossible. Compare pyjamas to pypy.js, for example - the former compiles to JS, but has known differences from proper Python semantics (long bignums), while the latter is a straight port of a Python VM, so the semantics are identical.

When it's released it'll map to asm.js and have most of it's limitations. Many of the limitations he ran into (no raw socket access, system library access) were related to the API limitations imposed by the browser's security model.

Also WebAssembly is pretty far along as they have drafted a specification and have prototype implementations in all the major JS engines. They also have a LLVM/Clang backend.

Threading and being a binary format instead of a text one aren't differences as fundamental as the difference between the Web APIs and NaCl's Pepper. Many of the complaints, as you point out, are about the Web APIs, and unlike NaCl Web Assembly is fully committed to the Web APIs (as it should be).

I would say that the main difference between asm.js and wasm is, as you mentioned, that wasm is a binary format. That will allow far smaller downloads, and far faster startup times.

The second main difference is that wasm is a new formal standard, with all vendors involved, so we should see consistent performance across browsers. Unlike asm.js which was a pure JavaScript optimization, so different browsers optimized in different ways, leading to large variability (which decreased over time, but remained significant, e.g. on specific things like memory growth, which was abandoned due to that).

[1] http://kripken.github.io/emscripten-site/docs/porting/pthrea...

I believe you mean "she".

1. Emscripten/asm.js supports the defined behavior case of setjmp/longjmp. What is not supported is jumping up an already unwound stack, which is undefined behavior. This is somewhat commonly-seen undefined behavior, though.

2. I don't think it's fair to say that function pointers are "hairy at best, broken at worst." Again, this is a case where we do not support undefined behavior. But perhaps most importantly, most real-world code is properly portable and just works. When not, we have tools that help figure things out.

3. It's not true that everything must be compiled into one massive JS file, Emscripten/asm.js also supports dynamic linking, [1]. However, the default is a single file, because then it can be more fully optimized.

4. There is already threads support, [2]. It works, and progress in the standards bodies is going well. The main issue is waiting for browsers aside from Firefox nightly to support it, but that's coming too.

A final note, I don't think the reason most asm.js use cases have been games is because the technology is only suitable for games. First, there are a bunch of non-game use cases already (for example, I've seen sites use asm.js for encryption, education, emulation, codecs, non-game WebGL sites, etc., including on major sites like Wikipedia [3]). But perhaps more importantly, games are already on the web, so they have a clear business model and use case. And, they are on the web mostly in the form of plugins, and plugins are going away, so they have to move to JavaScript.

[1] https://github.com/kripken/emscripten/wiki/Linking

[2] http://kripken.github.io/emscripten-site/docs/porting/pthrea...

[3] https://brionv.com/log/2015/08/09/video-decoding-in-the-java...

Still webassembly will be very helpful for some applications or even only libraries which have very high performance requirements. And porting some existing desktop applications might be easier than completly rewriting them to JS. But I guess for most websites and webapplications [transpiled] JS will be the more productive choice.

I found the "there is no main loop" comment not that fair, as I think javascript is one of the few languages which has a mainloop (aka eventloop) already built in. It's not a spinning loop like what you would build in a C++, but continously enqueing the main loop iterateration handler in setImmediate or similar should give the same result.

Instead, this is actually one of the best articles I've read about WebAssembly. The author approaches it from a C/C++ background and investigates what it means to write applications from that mindset, revealing the huge limitations of asm.js. Then the author turns to WebAssembly and gives a sobering look of how immature that project still is.

Please be more welcoming. We don't have enough programmers, no one is taking anyone's jobs away.

What they are all looking for are savant developers who can code a new linux in a day, who will do that for a pittance, who are willing to work 100 hours per week, who want to work at some bullshit web startup which hopes to be just disruptive enough that they get bought out. Any lesser people are outright ignored.

This requires stuffing hordes of people though education/training in the hope that just a few gems will be created.

I found the performance of asm.js in current JS engines the least limiting factor, instead it's the higher level APIs like WebGL, WebAudio that become the limiting factor.

Also, existing (game development) middleware hardly focused on reducing code bloat so far, which then results in huge Javascript blobs (but also huge native executables).

I've started a little while ago writing a low-level C++ engine from scratch with all of this taken into account (here: http://floooh.github.io/oryol/) where the size of the Javascript blob is (roughly) in the same ballpark as a three.js demo (minified and compressed three.js is around 100kByte, Oryol 3D samples start around 90 kByte.

So basically: asm.js and WebAssembly yay, HTML5 APIs nay :)

A lot of the criticisms come from fundamental limitations that are here to stay. Browser security, JS spec and so on.

The best approach for JS multithreading problem is to create a PureJS spec that has no side effects. This code will be easier to be multi threaded.

Is this true?

Webworkers is a multithread concept and as far as I know all variables are scoped but maybe not like they are in C.

As far as web workers, they are very restricted/isolated compared to regular shared memory threads In other languages.

2. I have bad news for you. Open any web-site (e.g. "google.com") and try to view its source. Is minified JS really that readable?

[1]: https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...

That was not my experience when I ported a large C app over to asm/emscripten. The mapping from C was very transparent. I had no problem using the dev inspector to debug the code.

[1]: https://github.com/WebAssembly/design/pull/457

Also, I hate the "transpiling" verb and your usage of it is incorrect. We started using "to transpile" as a way to inform people that some compilers, such as CoffeeScript, have a Javascript output that's still readable and that doesn't lose abstraction in the process, the "transpiler" being defined as a "source to source compiler". People preferred this term to convey the information that some languages like CoffeeScript are just mere syntactic sugar over Javascript.

On one hand that's superfluous when the very definition of a "compiler" is that of a program that transforms source code from one programming language to another. And on the other hand, people are using it incorrectly. The minified output of something like Google's Closure compiler, coupled with the higher-level abstractions in languages like ClojureScript or Scala.js, etc, leads to a Javascript output that is no longer readable and that does lose abstraction in the process.

Isn't that possible with many languages since the compiled code snippets are obvious.

I've always thought transpiling was defined as compiling from one language to another language that is at the same abstraction level. Usually compiling goes from a high abstract level to lower.

Personally I think that's a silly redefinition of compilation. We should just use "to compile" / "compiler" and be done with it.

Look at WebGL. There's a site which lists the best WebGL sites.[1] Most of them are demos. Some which aren't:

- http://breakthrough.nationalgeographic.com -- a menu system which puts you inside a sphere. Somebody really liked Lawnmower Man.

- http://histography.io -- a timeline of history. Only works on Chrome or Safari.

- https://www.rudys.paris/ -- a shoe store. Doesn't seem to have any 3D; they just seem to be using WebGL for zooming. Takes forever to load, and they broke the Back button.

- http://www.thehappyforecast.com/ -- an interactive "happiness map" of London. But it's just an overly fancy 3D menu.

- http://www.webglgames.com/ -- Deadtrigger 2 (zombies), They Will Eat You (more zombies), X-Wing (the 80s called, they want their arcade game back.)

You could do most of this stuff in Flash, and it would load much faster. Browsers now have more technology than use cases.

[1] http://cssnectar.com/css-gallery/nominees/site-features/webg...

All else being equal, would you rather have a .swf binary blob that depends on Adobe, or a WebAssembly binary blob that follows a well defined internet spec and independent implementation by multiple authors?

[1] http://lightspark.github.io/ [2] https://en.wikipedia.org/wiki/Gnash

Here's Unity's recent benchmark of WebGL and asm.js to see how performance has improved and will improve further in future: http://blogs.unity3d.com/2015/12/15/updated-webgl-benchmark-...

I'd be interested to see some more recent Flash versus asm.js benchmarks if anyone knows of any.

So they ignore all the things the user waits for, and focus on the frame rate that can be achieved once it's loaded. Bearing in mind that the most likely use of this feature is in ads, not twitch games, that's the wrong metric.

http://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-fe...

https://archive.org/details/softwarelibrary_msdos_games

https://archive.org/details/sega_sms_library

https://archive.org/details/internetarcade

Or video and audio codecs as used by Wikipedia to support those browsers which don't support those codecs natively:

https://github.com/brion/ogv.js/

https://brionv.com/log/2015/08/09/video-decoding-in-the-java...

Also try Bejeweled. A simple game but well executed:

http://bejeweled.popcap.com/html5/0.9.12.9490/html5/Bejewele...

In future we will have than binary asm blobs that run web apps faster and outperform any normal JavaScript. Then we will have to compile JavaScript to WebAssembly to get the extra performance boost, right? Stupid! It seems this technology is very bad for the whole web eco system.

How about investing more time in advancing HTML5? Little has been done since 2012.

So there's been a bunch of work on Custom Elements, Shadow DOM, ES6 modules, HTML Imports, ES6 proxies, Custom style & layout & paint (this part is still pretty early), etc

https://github.com/WebAssembly/design/issues/219

Mozilla OdinMonkey is used for asm.js, it's a seperate engine in Firefox (https://en.wikipedia.org/wiki/SpiderMonkey ). The general purpose JS engine is SpiderMonkey (TraceMonkey, JägerMonkey). So, Firefox already excutes asm.js faster than general purpose JavaScript due to an different faster implementation. And you can easily imagine that other vendors will follow them with WebAssembly.

Then the only way to get that extra speedup bonus is to compile Javascript to WebAssembly.

Well, let's hope Google realises that crawling web apps based on WebAssembly will consume a lot of CPU cycles and will decrease their rank or not index them at all. This will put an damper so that WebAssembly is only used for SaaS web apps compiled from native C++ and not for the vast amount of general purpose websites as a CEO technique to speed up the page load - which would be a real trojan horse, and dangerous for the web. Maybe I should add "patent pending", so that Microsoft, Adobe et all won't cripple the web.

Google will never do this. There's no indication whatsoever that Google (or for that matter any other browser vendor) is opposed to delivering apps over the Web in compiled format. Remember Google Web Toolkit? Closure Compiler?

If you want to argue against wasm on the grounds that it makes reverse engineering harder, then you should also be opposed to JavaScript transpilers and source minifiers. That's an intellectually coherent position to take. However, no browser vendor to date has taken this position, and to suggest otherwise is just narrative constructing.

"jfbastien commented on Jun 24, 2015 JS → wasm will only really make sense once wasm supports GC, and most likely JIT compilation too, which is still quite a while away. This would basically be equivalent to implementing the JS engine in wasm! I mentioned this recently and @BrendanEich accused me of having been taken over by horse_js.

To be clear, wasm's goal isn't to replace JavaScript, it's to supplement it. It's therefore not really a goal at the moment to support JS → wasm, but the features we want to implement will make it possible. I'm not sure it'll be that useful from a developer's perspective, though. You may get some size reduction, but that's about it. From a browser's perspective it may be interesting to have the JS engine implemented in wasm from a pure security perspective."

[1] We all write terrible code in professional setting. It is unavoidable. And scripting makes writing terrible code faster and easier than ever before.

This is because there is a WebRTC data channel you can use that uses SCTP. Emscripten emulates UDP on top of SCTP (which should be just a few bytes overhead per packet). Emscripten also includes the excellent enet networking library which let's you multiplex multiple reliable and unreliable channels on the same connection.

It's kind of a crazy multi-level hack (enet->UDP->SCTP->UDP->C++->JavaScript) but it works well.

I don't see how JavaScript was designed to "keep up with the competition". Java came first, as part of Sun's HotJava browser, and later as a native plugin for Netscape using (I think) their proprietary NPAPI (though it might have simply been welded into the client, to support the next part). Then JavaScript was built by Netscape, with direct access to Java via LiveConnect. Finally, Microsoft, to support all the new features being dumped into the web by Netscape, added VBA to Internet Explorer as "VBScript" with a separate JavaScript-compatible-ish syntax called JScript. (Later, under pressure from Microsoft, Netscape worked with them to file an international standard.) JavaScript was not a way to catch up: it was a game changing move, and one of the great innovations of Netscape (as opposed to most of the stuff they either implemented or refused to implement, which led to their delaying CSS and forcing HTML presentation markup on the world).

...and yes, asm.js certainly has its fair share of limitations, and problems. but...

    I’m more interested at this point to see what other approaches to create 
    the new web-based apps of the (near) future have been dreamed up by people 
    so far. Something which does not involve abusing a flawed scripting language’s 
    runtime to do unspeakable things.

What people?

Who's actually working on any other solution to this problem?

I get that Web Assembly isn't going to solve your need compile a C++ application to run in a browser without modifying it; but... I'm pretty sure that's not the goal.

The goal is to have some way of making extremely high performance parts of a web application, without resorting to an unsafe propriety vendor plugin or breaking backwards compatibility; and (possibly) allowing a new category of 'compile to js' languages to exist that can target web assembly rather than javascript, which (may, arguably) be easier to implement, technically.

What's the alternative? Web components? That's been a great success. The polyfill only occasionally destroys firefox and its technically not possible for it to implement some of the features, so lots of people (ie. no one) is using it.

Dart? I'm not even going to talk about that.

Another browser plugin? Native apps and no more web apps at all?

Come on, it's easy to complain, but unless you've got a tangible alternative, cut them a bit of slack.

The web assembly stuff is coming along pretty darn fast, and lots of players are involved. It'll be a big deal before you know it; I think it's pretty fair to be excited about it.

People have often called for a ByteCode vm. This has been rejected over and over again. Bendan Eich in particular has repeatedly argued against bytecode in ways I found to be quite disingenuous. He has variously used Java to imply one bytecode being unsuitable means all bytecodes are unsuitable, or suggested if you want bytecode to make a bytecode VM in JavaScript (even using DCPU16 as an example), or that it is too late for a new standard, or that. No bytecode would be accepted by all browser makers (which I took to mean 'not on my watch'). I have yet to find the arguments against a bytecode VM to be convincing.

I think it would be well worth making a few different candidate bytecode VMs to give the platform a chance in the field. Such VMs are not hard. In the case of the DCPU16 (A imaginary CPU created for a project Notch was working on) it took less than 48 hours for emulators to appear and just under a week for the first compiler. A VM that occupies a similar space to Javascript has its own particular needs.

In a different direction Maxime Chevalier-Boisvert argues for a Control Flow Graph representation http://pointersgonewild.com/2015/08/02/javascript-is-the-c-o... Which if the Webassembly approach is to be taken this does seem more sensible than a AST.

The cooperative multitasking aspect of JavaScript has been a bugbear for all too long. I have argued for a preemption mechanism of some sort that would fix the dependency on a main loop event pump. I have half a specification written as a proposal, but I suspect people will fight the idea tooth-and-nail.

Ideally a solution should encompass concurrency as much as preemption. I kind of like the idea of A bytecode VM with an arbitrary number of virtual CPUS. A fork instruction to launch a new CPU. The VM host is free to run them on however many actual cpus as it sees fit.