To be fair, if you have a good read of https://github.com/WebAssembly/binaryen, you'll find the OP is pretty much on the ball; there's no easy way to compile to web assembly from (language here), and even if you do, there isn't really any easy way to run the result other than compiling it back to asm.js
...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.
Like what?
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.
I have certainly given this a great deal of thought. What is needed? How could we get from here to there?
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.
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.
...and yes, asm.js certainly has its fair share of limitations, and problems. but...
Like what?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.