It's interesting how the paradigm on "designing a language" has changed. I was very young in the pre-web native-only days, but it seemed like then you would have people writing their own languages and compilers that were pretty independent of each other and could be radically different (Haskell, Erlang, Prolog, etc).
Now that the web is becoming the dominant environment, EVERYTHING is HTML/CSS/JS (on the client side). That little package truly feels like the Assembly of the web (which is bad because that stack is too structured and high-level to be a good compilation target). And so now everyone just writes a layer of sugar on top of HTML/CSS/JS. These little toys that "compile" one high-level syntax to a slightly different one.
On one hand it makes sense, because what else can you do? Any radical non-JS front-end tech you might come up with simply won't be adopted. There's a chicken-and-egg problem, where nobody can adopt it until the browsers implement it, and the browsers won't do that until enough people are using it. Google, one of the few entities that has the power to get around that, has received mostly negativity and disinterest for their efforts (Dart). Is that just because it's Google? It even compiles to JS, because you just can't do anything that isn't JS. Seems like a real problem, and this is coming from a huge fan of JS.
Adding a Dart VM to the browser doesn't really help anyone. Some people, like myself, were excited as we might have been able to get a more traditional bytecode VM in the browser. However, Dart actually just adds a Dart VM, which is really not that different from a JS VM as a compile target, and so doesn't help the situation.
That being said, we now have asm.js, which isn't that bad of a compile target.
I agree, putting one more layer on top of JS does not allow to do substantially different things. But I would argue that this is the only option. Google is pushing its PNaCl [1] clients where you can run C++ code in your browser independent of the platform. Isn't this partially solution to the chicken-and-egg problem? It may get adapted because there is a strong player behind it. It also allows substantially different things to be on the web. For instance you can run some heavy computer vision app analyzing webcam stream directly on client side. Apart from notable JS exceptions [2].
I think there are lots of interesting new things happening in the world of programming languages, and its not all related to the web platform by a long shot. The thing that I find most encouraging is that LLVM and things like pypy make it much easier to create a language that stands a chance of performing half decently even without years of writing your own optimization code. I actually think the world of programming languages is currently more diverse than it was 10 years ago, although perhaps less diverse than 20 years ago.
The "JavaScript as the assembly language of the web" mentality seems to be taken most seriously by those JavaScript programmers who have absolutely no experience whatsoever with any sort of real assembly language. Many of them don't even have experience with something like C.
It's one of those things that sounds good on the surface, but upon further inspection by those who know assembly language it's quite clear that it just isn't true. Yet this doesn't matter when in a crowd that consists of people who, as a whole, don't know assembly language. The claim can be parroted repeatedly, without anyone really questioning it properly.
(I'm not directing this at resu_nimda, by the way. I see his comment more as a reference to the idea, rather than necessarily in support of it.)
The point of "JavaScript as the assembly language of the web" isn't that Javascript is exactly like Assembly was/is.
The point is that Javascript is as low-level as web-programming gets, and you can craft Javascript manually or let a compiler create it for you (with CoffeeScript, etc.).
Of course, the analogy isn't perfect, but that doesn't mean it doesn't fit.
But it's so far from low level, that's the problem. Assembly language represents the raw fundaments of computing, as we have envisioned them. It maps directly to the actual capabilities of the hardware.
If compiling to Assembly is like working with basic molecules, compiling to JavaScript is like working with lincoln logs. And you can build some impressive things with lincoln logs (just like you can build a computer in Minecraft), but you'll always be restricted to things that look like lincoln logs.
I think you're focusing on a different point then the argument. Javascript is often compared to the assembly language of the web because its a) low level web programming and b) its universal; both much like assembly in their own way.
How low level do you need in web programming? Probably not that low, why? Because with web programming it has the potential of being much easier to do something malicious if you have access to the raw hardware like you do in assembly. The whole point of Javascript was to make more interactive sites, and when it comes down to it, Javascript does an awfully good job at being that low level language to do so; It has come to represent the raw fundamentals of web programming as we have envisioned them. So just because its a fully formed language that is much higher level than anything assembly comes close to, doesn't mean that it still isn't 'low level' with in its use case.
Javascript also has the advantage of being universal, much like assembly. Assembly is universal in the sense that different flavors of instruction sets come on different microcontrollers but no matter what, nearly all uc's come with a reference guide which lists out the hex values for each instruction the CPU supports which can be used to build an assembler. These instruction sets all contain a core set of fundamentals such as basic math through the ALU, and storing/reading values and moving the PC and SC around. Which at the end of the day means that all uc's have support for an assembly language in some fashion that shares a common base. The same can be said with Javascript. Every browser comes with its own flavor of the language which supports the common base and then adds some fluff on top, but no matter what, nearly every browser comes with it.
At the end of the day though, trying to compare these is nearly a null-point to me, because they were designed in completely different ages of computing, and are designed for different tasks and are not (not easily at least, although a uc with support for a Javascript vm is possible, and replacing Javascript with assembly is fully possibly, both are rather difficult tasks and as such this argument is, for practical reasons, null also) interchangeable.
Implementing one high-level language (CoffeeScript, TypeScript, etc.) via translation to another high-level language (JavaScript) does not make the target language an "assembly language" in any sense.
It's called the "assembly language of the web" because it's the web's lowest common denominator that languages compile to, just like assembly language is the LCD of native platforms. More accurately, you'd say it's the "machine code of the web".
Sorry, you completely missed the point of the analogy. The point of the analogy is that within the realm of the browser Javascript provides the most natural substrate for compiler code generation, much like assembly is the most natural target for code generation in many other environments. It's a pragmatic point not a theoretical one. It has almost nothing to do with the specifics of either Javascript or assembly language as mediums for writing programs. You're overanalyzing it to the point where I have to think you are trolling.
(Disclaimer: I've worked on compilers that target both assembly language and compilers that target Javascript)
Let's build a HTML5-VM that run assembly instructions; and have a C compiler/assembler that compiles into it. I can put then HTML5-C and HTML5-asm into my LinkedIn and other social media profiles to really rub it into these youn'g faces.
I'm not sure about negativity and disinterest being "most" of the reaction to Dart. From people who actually take the time to learn a bit about the language, the reaction is mostly positive in my experience. Dart is growing, but unfortunately at this time that growth seems to be linear rather than exponential. It will likely take a major (non-Google) app being built in Dart, inclusion in Chrome, or inclusion in Android for it to really take off.
Now that the web is becoming the dominant environment, EVERYTHING is HTML/CSS/JS (on the client side). That little package truly feels like the Assembly of the web (which is bad because that stack is too structured and high-level to be a good compilation target). And so now everyone just writes a layer of sugar on top of HTML/CSS/JS. These little toys that "compile" one high-level syntax to a slightly different one.
On one hand it makes sense, because what else can you do? Any radical non-JS front-end tech you might come up with simply won't be adopted. There's a chicken-and-egg problem, where nobody can adopt it until the browsers implement it, and the browsers won't do that until enough people are using it. Google, one of the few entities that has the power to get around that, has received mostly negativity and disinterest for their efforts (Dart). Is that just because it's Google? It even compiles to JS, because you just can't do anything that isn't JS. Seems like a real problem, and this is coming from a huge fan of JS.