I think that misses the point. Since WASM is a compile target you don't need JS to achieve interop between different languages if they are all compiled to WASM. The JS + WASM combo is to do things that WASM container cannot do on its own.

Also, JS is a more suitable target for most managed languages like clojure, typescript, elm, etc.

Well... two of 3 of the languages you provided as example were designed to be transpiled to javascript. I doubt JS is a more suitable target for other languages than an IR like wasm which is being designed to be a compiler target.

I would be interested in hearing a more detailed argument on why ClojureScript & Elm would be better if they targeted WebAssembly.

Even the WebAssembly authors seem to agree that it's not foremost a managed language compile target - The Overview text from http://webassembly.org/ says "Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications."

Elm was designed to be transpiled into javascript just like CoffeScript so let's put it aside for a moment. WASM is work in progress so I'm sure that if people care enough they can find solutions for such specific issues(i.e. seems that VM languages have their own set of issues). There is a GC proposal so managed languages will benefit a lot(i.e. smaller runtime).

JS is a high level language. I don't see many people compiling to managed languages outside of the browser. Wonder why is that? Few target JVM...but I don't see many(if any) compiling to Java, C#, Ruby or Lua or PHP. I've never seen anyone compiling JavaScript either unless they had to run it in a browser. This should tell you how good JS is when it has to compete on merit as compiler target.

Elm semantics is very far from JS - it's a kind of Haskell-lite. The tooling and diagnostics are very much custom and don't rely on JS developer tools or source maps. (Also, "transpile" is just another word for "compile")

Do you mean that Elm was not designed considering JS as its compilation target? Is Elm used anywhere else than the web browser? Why nobody compiles to JS outside the web browser if it's such a good compilation target?

>> Also, "transpile" is just another word for "compile"

Well, I prefer to use the "transpile" term when the target is a high level language.

JavaScript is a high level language. It seems some smart folks decided that a new "language/IR" is needed (wasm) so that people can use other languages on the web. Now let's make this new IR a first class citizen on the web.

I'm sure Elm design considered JS, but I'm also sure that if WebAssembly had been available when Elm was designed, it would still have targeted JS rather than WebAssembly. Same goes for ClojureScript.

WebAssembly is a refinement of asm.js, which started as a mechnism to enable C/C++ code to run in browsers. Other, managed languages aren't forced to go the asm.js route because their semantics aren't tightly married to a byte addressable, untyped program heap.

What exactly makes JavaScript a better target for languages such Elm (apart from GC and DOM access which are supposed to be implemented sooner or later) ? You realise that JavaScript itself is also compiled/transpiled by the browser engine(i.e. v8) before it executes, right?

Let me count the ways:

- code size - a runtime for a managed language is much bigger if you have to reimplement & ship the primitives you get from the JS platform.

- implementation complexity: a LLVM-webassembly-toolchain along with your own GC is much harder and more work than a JS backend, and would need to have a rather good payoff to be worth investing in.

- poor cross-browser development tooling support to have a good debugging experience

- GC implementation complexity and performance - firstly, there is no GC support currently and no timeline about when/if something materalizes. The current "future GC" support in webassembly[1] doesn't provide a GC implemnetation, just hooks to peacefully coexist with JS GC.

- JS interop

- browser support

Now, it may be that some of these get solved eventually - but they would all have to be solved, with high quality solutions, to beat JS as a managed language compile target.

[1] https://github.com/WebAssembly/reference-types/blob/master/p...

>> - implementation complexity: a LLVM-webassembly-toolchain along with your own GC is much harder and more work than a JS backend, and would need to have a rather good payoff to be worth investing in.

I strongly disagree. Wonder why no language(managed or unmanaged languages) designer uses this gem named JavaScript as compile target?(web stuff excluded)

It seems your whole argument revolves around the fact that JS has better support than WASM in browser. We already know this. WASM is a work in progress. It's not ready yet for prime time. This year we will get some managed languages compiled to WASM. Next year we might get GC. I believe in some distant future javascript will be compiled to wasm either by the client or by the browser itself(for backward compatibility). JavaScript is JIT-ed in the browser anyway.

you only need js to bootstrap wasm onto a canvas. then write the rest of your "site" in QT or GTK ;)

Is this possible already? I'd love to build web CRUDs using tcl/ttk for the GUI part

you could use emscripten to compile to wasm as a target https://kripken.github.io/emscripten-site/docs/compiling/Web...

>> I think that misses the point. Since WASM is a compile target you don't need JS to achieve interop between different languages if they are all compiled to WASM

Really? Can you please point me to some documentation about this? I can't mange to find out how to use a wasm compiled library (compiled from C) in C#/mono project (which also compiles to wasm )

If you manipulate the two code bases to be in the same module https://developer.mozilla.org/en-US/docs/WebAssembly/Underst.... Otherwise, export and import which is also covered on that page

> I would rather like to see better interop between different languages using wasm

Yes, and garbage collection that crosses language boundaries.

Is anyone even working on this? I don't remember seeing foreign function bindings in wasm other than for JavaScript.

If there are no competitors, JavaScript wins by default, just like C ffi did on server and desktop.

There’s a bunch of uses of wasm outside the browser. I’m personally not a huge fan of crypto currencies, but Etherium is looking to use it as a language for smart contracts, for example. Just like any small language, you can embed the interpreter into whatever and use it for scripting; the spec is written so that this is pretty easy.

That said, none of this means “replacing” JavaScript, no matter what the parent says. It’s a non-goal.

>> That said, none of this means “replacing” JavaScript, no matter what the parent says. It’s a non-goal.

I believe a better term would be "skipping" javascript than "replacing" javascript. There won't be many rewrites but I'm sure that many people would skip JS on new projects if they would have that option. Why would a Python, Go, Ruby developer choose JavaScript over Python given that their language of choice would compile to WASM(along with DOM/webAPI access)? The ecosystem may be a reason but that's only a matter of time(i.e. 1 -2 years).

One good reason is binary size; JS is going to have the advantage here since it’s runtime is already installed.

Another good reason is that, regardless of what you read on Reddit and Hacker News, a lot of people actually really like JavaScript.

>> One good reason is binary size; JS is going to have the advantage here since its runtime is already installed.

Yeah, that's true now though I don't think there is something that stops browsers to host a runtime(i.e. a pre-loaded std wasm library + wasm-gc) to help the languages compiled to wasm to reduce their compilation size. The question is really whether the browsers want to make WASM a first class citizen or not.

>> Another good reason is that, regardless of what you read on Reddit and Hacker News, a lot of people actually really like JavaScript.

I believe WASM could serve the other lot of people who are not that much into JavaScript. Using the same language on server and browser also reduces friction(i.e. see NodeJS). Personally I believe JS has a such rank based on reach not on merit.

There’s some complexity, but yeah they could do that. I really doubt it will happen; if we couldn’t get browsers to include jQuery, why would they do this? It’s even harder than that would be.

> reach not on merit

Node’s popularity and success is counter to this notion, IMHO. Seriously, lots of people love JavaScript.

I doubt many would pick JavaScript if given the option on the browser side.

Regarding node it has two things going for it, the frontend devs that only know JavaScript and try to do server side as well.

The fact that thanks to its world class JITs (V8 and ChakraCore) it easily beats Python and Ruby interpreters in performance, which are the most common deployed variant.

Let me see. A lazy developer that only knows Ruby compiles the entire Ruby interpreter into WASM just to run Ruby. Then the user clicks a button that does an API fetch and the whole browser freezes while it waits for the response. . . . Yeah not happening. WASM was built and meant for high performance low level languages, there is no way in Ruby and Python will make the cut.

That lazy developer will download a Ruby WASM based VM that someone else compiled for them.

Also the revival of Java, .NET, Flash, ActiveX is already brewing, this is not only about Python and Ruby.

Just doing games in Unity, compile to WASM and deploy, just like plain old Flash.

And while at it, use the 2D GUI to build a complete web site, just like plain old Flash.

The difference is now we can all be happy, because it is a Web standard.

You're just repeating the same thing as the parent. I don't think that's true. People legitimately love JavaScript.

>Using the same language on server and browser also reduces friction(i.e. see NodeJS). Personally I believe JS has a such rank based on reach not on merit.

And yet somehow thanks to NodeJS, javascript development seems to have gotten exponentially more complex.

Python and Ruby will never compile to WASM since they would need to have the entire interpreter compiled with it and it would be extremely slow and bloated experience. Not to mention those languages do not have very good support for async operations and the lack of closures make it a terrible idea for the web.

Yes, that was my thought too and I was disappointed to see them defending JS at the top of the article. Getting away from dynamic language mush is one of the biggest attractions I have to WASM.

You already got that from asm.js though.

why to use a half baked solution than something designed from the ground up for the job?

I don't read binaries so I don't particularly care how hackish the solution is as long as it works. There are benefits to wasm of course, but running C code in the browser isn't one of them.

Let's be real, the goal of WebAssembly is to replace JavaScript, but providing alternatives to it. The whole "WASM doesn't replace JS!" thing is pretty much just to placate the "But what's wrong with Javascript?!" crowd.

I disagree from a technical perspective. WASM is a box much like an iframe or a Java applet or Flash media. Therefore the things contained within that box are isolated from the things outside that box. JavaScript, on the other hand, operates outside that box and, with appropriate bindings, can interface with APIs inside that box.

The WASM will replace JavaScript argument exists not for any valid technology reasoning, because people desperately need it to (only for personal reasons) and don't understand how web technologies work on the front end.

The goal of WASM was never to replace JavaScript, but to replace Flash (before Adobe announced the death of Flash) in a language agnostic way.

I believe you are wrong. WASM has a text version and nothing stops you from using the DOM or the web APIs (given that wasm gets an API). What exactly is the black box? You can use OpenGL in javascript too if that's what you mean by "black box". You can't do anything new in wasm than in JS except you get better performance and more options (language wise).

Now imagine web sites written 100% in WASM, just like they were 100% in Flash.

What did you won with Flash being replaced?

Currently WASM can't access the DOM. But WASM-native DOM APIs are planned and then you will be able to completely ditch Javascript if you want.

Issues have been opened for native DOM bindings in WASM, but I am not sure if that work ever started. As others have mentioned there is the hosting bindings API that is well underway, which provides web APIs to the WASM container so that code compiled to WASM can interact with the JavaScript outside it. This doesn't sound like what you are hoping for though.

At this time, and for the foreseeable future, there are no plans with active code in development to implement WASM as a JavaScript replacement, at least to my knowledge.

Code compiled to WASM can already access Javascript outside it. Obviously. Otherwise how could it do anything at all??

> Issues have been opened for native DOM bindings in WASM, but I am not sure if that work ever started.

I didn't say work had started on it. I just said that it is planned. See here for proof: http://webassembly.org/docs/high-level-goals/

> access browser functionality through the same Web APIs that are accessible to JavaScript

> Otherwise how could it do anything at all??

By passing data.

Can you speculate on what these APIs will look like? JS is well suited for dealing with cross-browser incompatibilities because of its reflection support. That is much harder to build in a low-level target like WASM. COM is an example of what we might get, and that is not a pleasant prospect.

plenty of typed languages have reflection. i don’t see how this changes anything?

WASM is not a typed language. It is a language-agnostic compilation target.

So what would a DOM API exposed to WASM look like? COM is the only example that comes to mind.

> WASM is not a typed language. It is a language-agnostic compilation target.

These two things aren't contradictory. wasm is typed.