At the very least JavaScript will always be around as a "glue" language to use wasm binaries.

I think of the relationship between JavaScript and WebAssembly as the relationship between Python and C. JavaScript will call out to a wasm binary for some "heavy lifting" and JavaScript will be used to "glue" the data to the DOM. Also like the Python-C relationship, the wasm can be a compile target for non-javascript libraries.

But I honestly don't see writing non-javascript web applications being mainstream any more than it is now at any point in the near-ish future. It's possible (both now and in the future), but it's always going to be a leaky abstraction, or your language will end up being similar enough to javascript that targeting wasm is largely pointless (think TypeScript or Flow).

The performance of touching the DOM and browser APIs will be the factor that decides that, imo. I think you may be underestimating how many people are partially or heavily disgruntled at javascript, and would happily replace it if given the chance.

If speed is not an issue, and it's purely by choice of the user, i think there will be a lot of interesting changes to the web in the coming years.

Hell, for many applications i'd even be willing to accept a speed loss to use "my preferred language". And, in the event that certain tasks are indeed too slow, perhaps i'll be able to pass data back and forth between my WASM and JS to let JS deal with the performance critical DOM.

Regardless, i'm quite excited, and hope to see something fruitful from it.

It's not actually the nightmare many make it out to be with ES6. I actually enjoy writing it quite a bit (I have mainly a functional background)

On the web it's.. well, just JS. Some languages that transpile to JS.. but ultimately they're all pretty much just JS.

I think the community of people who want tyoe safe languages is large, and this will the a target for them.

I just hope for Dom bindings through the WASM ABI.

Writing glue code sucks.

Define an ABI for interacting with the DOM. And allow WASM compilers to target it.

Javascript is an interesting language (particularly after it's recent revival), but IMO it's recent jumpstart would never have happened if it weren't for one killer feature: access to the HTML DOM. People would (and have) forgiven many other things, just for the utility of that as the presentation layer.

I certainly would have picked up whatever language the browsers were pushing, where DOM access was a requirement.

Conversely, I remember trying to get java applets to interact with HTML -- you have to message things through a tiny hole to/from javascript; which was (one of the many) things which made everyone hate java applets.

(This is not a criticism of wasm, by the way. It's merely motivating potential future GC extensions to the spec.)

As an aside, JS is standardised by Ecma, as ECMAScript: the W3C doesn't have anything to do with it.

That’d be finally a solution.

Or require source maps by law.

EDIT: Why the downvotes? The only way to preserve the right to modify and decompile in the long term is by creating technical or legal measures enforcing it. JS was one technical measure, so now we need alternatives.

> That’d be finally a solution.

No, it wouldn't. You'd end up with sites shipping "source maps" that map every function to a randomly generated identifier.

What's a "valid" source map anyways?

Furthermore, debugging with sourcemaps is suboptimal. WebAssembly wants to support much better debug information than this.

It’s also intended to allow them to modify it for their own purposes, and provide the modifications to others who have a license to the original product.

Especially on the web this was finally possible, and now you’re suggesting to take this away again?

At most they legally protect someone who decides to run a disassembler or decompiler on a binary from prosecution or lawsuits (but only in as much as you don't use the result to violate copyright or other restrictions).

See Article 6 on http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:...

And "copying the decompiled source of the part of MS Word that reads .doc files" counts as covered, so, it's quite a lot.

Especially with websites, where you might want to interact with, or write addons interacting with, WASM threatens those rights.

No need for the DOM anymore... (not saying it's a better approach, but it is technically possible).

There's the next full stack paradigm right there. I give it two years, and it will be called rustic-asm framework...

It's still very early, and there's other avenues as well: an LLVM backend, for example.

More excitingly, I presume it will one day be possible to compile a mobile app into wasm and execute it in a browser, achieving instant parity between mobile web and apps.

Indeed, taking those away would be breaking the web rather than improving it...