Why won't WASM kill JavaScript?

Question: Why won't webassembly be, in the mid-term a debacle for JavaScript if, in general, this is so reviled? Brendan Eich said he was certain that wouldn't be a problem but I never understood why. I don't understand why, e.g., Clojurescript would still be developed when webassembly exists. – @spectrumgomas

A few questions in one

There are various questions here, with different degrees for speculation.

First, there's a relatively neutral question which could go something like: “Given WASM existence, [why] is JavaScript still needed?”. Then there are two more questions: “Why did Brendan Eich say what he said?” and “What effect will WASM have on general web development (JavaScript and others)?”.

[Why] is JavaScript still needed?

From a purely technical standpoint, it can be concluded that, yes, the design of WASM has made -intentionally?- JavaScript still necessary for some things. There are some plans to solve some of this, but they are long-term plans and may change a lot.

More precisely, JavaScript is still needed because, by design, WASM can't directly access Web APIs, but only communicate with JS code and ask it to do so. This is surely not a big limitation, since it's just “glue code” and it would be easy to have a generic abstraction layer implemented in JavaScript and then forget about it (in fact, Emscripten already includes such a layer for a number of Web APIs). In any case, the truth is that, by design, WASM is more oriented towards letting JavaScript keep control: High-performance modules compiled to WASM, that are used from a higher-level application logic built in JavaScript.

(As of today, and even though “there are plans” too, WASM does not provide Garbage Collection. This is a relevant technical limitation.)

Then there are other, non-technical arguments. There's cost. The question is not only if it's necessary but also to evaluate to what extent it still makes more sense to do some parts in JavaScript. Thinking about this, I would say that, in fact, there are parts of an application that short-, mid-, and maybe even long-, term, is still cheaper to build in JavaScript. To ponder this, we need to take into account both the development cost and the value of the obtained code.

It is my experience (Danger! Opinion ahead!), the cost of JavaScript code tends to be somewhat cheaper (lower salaries) but also the value of front-end code is notably lower, being much more exposed to change.

Why did Brendan Eich say that?

I'll be brief here: I don't know; I can't know :) I can, at most, imagine he would have some arguments similar to those I exposed above, maybe, but my impression is a bit different:

  • I believe that there existed “advertising” motives, to give them some name. There was a certain social necessity to present WASM as non-disruptive, something that wouldn't break the web and wouldn't be a big shock to web developers and, maybe more importantly, to the developers of the web platform (browsers, engines, standards, etc). Not presenting it in this way, may have hindered its acceptance from these groups.
  • I also believe that Eich has the idea that “JavaScript is now immortal” (or almost that). That is, it's not that they didn't want to kill it, but that they believed they couldn't kill it even if they wanted. This is debatable, but it's probably fair to admit that, at least, killing JavaScript is quite hard.

What effect will WASM have on general web development (JavaScript and **others**)?

This is, obviously, purely speculative. And more importantly, who am I to think I can make such predictions about the future? ;)

But I can say that I understand at least part of these concerns. In cases such as the one mentioned -why keep CLJS when you could transpile Clojure to WASM?-, I think there may indeed be changes coming. But they will take long.

I also think that it is not that important in most cases, and that any significant change can only happen if it involves something that first has a large usage. Imagine TypeScript usage grows a lot and then they decide (and are somehow able) to make TypeScript compile directly to WASM. Such a thing would probably have more notable consequences.

As of today, though, I think the majority of languages that already regularly compile to JavaScript, will continue to do so. Mainly because that's the ecosystem they live in and it's easier to keep taking advantage of it, rather than having to develop a bunch of infrastructure from scratch. It's a different thing that in certain, specific areas -e.g. videogames- it may be worth it. But this is moe related to a different type of languages and situations, and it specifically fights in the arena of plug-ins or closed environments such as ActiveX, Flash, Java applets, Silverlight, PNaCl, Unity or other custom plug-ins (as an example, the first Quake Live).

In any case, I prefer not speculating too much with this stuff.