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,

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.