Asm.js could be considered close to the metal if you were running on a Pentium 166. I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc.
With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment.
These problems all come back to the fundamental issue. There's no escape from javascript. Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility". Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web. Thus, we stagnate, and everyone suffers for it.
I've never used web workers, but as a developer who has written a lot of multi-threaded code in C++, I'm kind of glad that as a user I don't have to suffer poorly written non-thread-safe JavaScript. I've seen some terrible multi-threaded code by developers who just didn't get it. I suppose that's why web workers are designed the way they are: to make it easier for developers who maybe don't quite get the intricacies of multi-threading.
> I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc.
It has all of these things. It has SIMD now, 64-bit support is improving, IEEE-754 is supported (though some of the checks aren't available yet, I'll give you that). Give it time.
> With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment.
Yes, but this stuff isn't applicable to asm.js. It shares a heap between threads, it's just like your old native code, and everything is triggering race conditions^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B hunky dory.
> These problems all come back to the fundamental issue. There's no escape from javascript.
What's wrong with that? If you don't like JS, you can compile to it. It's an excellent compile target.
> Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility".
It's not just a compatibility hack, though managing to work on everything with no updates is a killer and awesome feature. It also avoids unnecessarily reinventing the wheel. It reuses as much of JS as possible. That's good.
> Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web.
...well, yes, they're fracturing it. And usually needlessly. There'd be no benefit to a new language on the web. There's nothing a new language can offer which JS doesn't have.
> Thus, we stagnate, and everyone suffers for it.
What stagnation? Everything is moving rapidly. Things are improving all the time.
Simd.js is only supported on one and a half browsers, is only supported on a single platform, and only supports two data types. I'd hardly call that supported, more like being hacked together. Its current implementation requires you to waste quite a few clock cycles and bytes of memory if you want to do things like graphics operations. 64 bit support is at the, "hey, you can store numbers. Have fun creating all the operations for them" stage." Furthermore, it deviates from the IEEE-754 standard in things like number handling -- Math.max(5,NaN) should return 5, not NaN. This means that libraries written in other languages and transpiled using emscripten and the like will not behave as they should.
I'd say that the weaknesses of web workers is absolutely relevant. Though you see it as protecting the coder from themselves, there are design patterns out there, like publish/subscribe, that are useful in letting threads communicate, but not generating race conditions. DOM access and the like can be done sanely, but Javascript doesn't even give you that option.
Given the reasons described, it's a rather poor compile target. It's a plodding beast of a language that mishandles numbers, requires circuitous coding to handle basic concurrency, and otherwise behaves in ways other languages don't. Transpiling just barely hides its flaws.
I will restate that it is a hack, and a rather ugly one. Its attempts to maintain compatibility leave us with a virtual machine that is increasingly obsolescent. An "assembly language" designed in 2013 shouldn't be lacking support for 64 bit integers (or 8-bit or 16), should have good support for vectorization, and should provide some sort of register and/or stack model so that you can better clue in the vm as to what items are going to be frequently used in functions. The missing features could be handled much like JSON was early in its life, by including a library as a fallback. It would probably end up looking ugly as hell, but at the same time, it would work, and give a lot more long-term benefits.
Regarding alternative languages, Javascript isn't always the best language to describe a problem in. Sometimes your program's better written in C, or Lisp, or Fortran even. Why should you force your problem to fit the language?
Regarding stagnation, you can move quickly, yet not really go anywhere useful. COBOL had 7 major versions and several minor in 14 years. Does it mean that it's a useful language today? The stagnation comes in terms of how people think of problems, and how they try to wedge those problems to fit into Javascript. The web would be a much better place if we allowed more experimentation into languages and behavior.
With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment.
These problems all come back to the fundamental issue. There's no escape from javascript. Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility". Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web. Thus, we stagnate, and everyone suffers for it.