The web already is 'generic purpose'. Outputting JS or WA does not make any difference in that regard. It just makes things a bit faster.

Sure, the web is sometimes used that way currently, but few projects are using full-on Foo-to-JS compilers like GWT or ClojureScript that make the original source entirely illegible when viewed through the browser console.

Instead, projects are mostly using "light" transpilers built to have clean mappings to JS semantics, like TypeScript, where the original source can be recovered and traced by the browser as long as the transpiler generates a source-map.

WASM really won't work with the "source map" paradigm, and so a move to a web where most development uses languages that compile to WASM, is a move to a more opaque, less learnable web. (And also one that browser extensions have far less of an ability to intercede in.)

This just means you won't debug things using a browser console, but using a debugger designed for the host language instead. And that would be a blessing: I'm far more proficient in GDB than I am in the Chrome/Firefox developer tools.

Why won't WASM really work with the "source map paradigm"? Is there something fundamentally different about bytecode that means it cannot be traced back to its original source, given tooling support?

WASM will have source map support, if it does not already. There is already support on Firefox nightly it seems: https://github.com/yurydelendik/wasm-source-map-emscripten

But there's an upside, no? There is no way to reference an undefined variable in go? So if the compiler is correct, so will be the result, and errors would be found compile time.

(written by a non-go-expert)

While you cannot reference an undefined variable in Go, you can still dereference nil pointers and invoke other operations that result in a panic (some of the standard library functions can panic).

It’s not necessarily any faster. You can shoot yourself in the foot quite easily too, performance wise.

It's more predictable, when generated from a strongly typed language.

Most of the times, due to the strong typing, it is faster. However, there's a cost involved in compiling, invoking and passing data in and out of a wasm module. If the overhead cost is greater than the raw performance gain, there's no discernable difference

Don't forget about crossing language boundaries. Using JNI can be slower than pure Java code, and I think the same is true for wasm-js interop [1]. When wasm gets "native" access to the DOM and other browser features this may change, but until then, DOM manipulation is probably going to be faster in js.

[1] someone should benchmark this.

JNI transitions (at least on OpenJDK and Android) are much more expensive that WebAssembly<->JavaScript transitions. For the latter the same JIT is being used on both sides and there is no need for a GC transition. JNI is also far from as fast as it could be; .NET’s PInvoke is much more efficient (and easier to use).

Mark Reinhold already stated on a few talks, including at JavaONE that Sun designed it that way on purpose as they wanted to keep everyone true to WORA without carrying native code around.

Which is also a reason why a replacement is being done as part of Project Panama, initially advocated by Charles Nutter due to the JRuby project issues.

http://openjdk.java.net/jeps/191

In alternative, if you have the source code available there is a way not to any transitions.

Java now has GraalVM and .NET had C++/CLI (nee Managed C++) since the beginning.

In this version of web assembly only !

Web Assembly is gimped because it needs to be compatible with existing JS runtimes - when they add threading support you will no longer be able to run a WASM shim in JS but at the same time WASM will become a lot more general purpose.

Existing JS runtimes actually use shared-memory concurrency a ton, even ignoring the (currently disabled) SharedArrayBuffer. Code generation and garbage collection have at least some concurrent stages on all the major JS engines. JavaScriptCore even exposes this in its API.

Javascript already has multithreading via webworkers. That's not something WASM will introduce.

SharedArrayBuffer is only available in chrome and FF and they disable it by default so no way to do standard multithreading via webworkers.

It was disabled because of spectre.

Multithreaded WASM isn't here either.

I think WASM will face the same security considerations.

Webworkers are multithreading. You just have to use slower, async communication methods. WASM will likely be the same way, given the security considerations.

WASM will have more low level support.

https://github.com/WebAssembly/threads/blob/master/proposals...

By itself, adding the Go SDK to the mix is unlikely to simplify the toolchain. To do that, you need to remove more complexity than you add.

There might be a chance to simplify if you're already using Go on the server and you remove a lot of other stuff.

But if catching up means taking on baggage and complexity, is that still a win. Technology is a means, not an ends. Of course non-native should evolve, but taking a copy-cat approach seems like a not so good plan.

Luckily the "plugins" will be bundled with the apps. The trade-off is ever-increasing download sizes.

In the age of using JavaScript to render text.