5 ms·

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.

• erikpukinskis 8y ago
  It’s not necessarily any faster. You can shoot yourself in the foot quite easily too, performance wise.
  • mankash666 8y ago
    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
    • uluyol 8y ago
      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.
      • johncolanduoni 8y ago
        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).
        • pjmlp 8y ago
          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 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.
• rubber_duck 8y ago
  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.
  • TekMol 8y ago
    Javascript already has multithreading via webworkers. That's not something WASM will introduce.
    • rubber_duck 8y ago
      SharedArrayBuffer is only available in chrome and FF and they disable it by default so no way to do standard multithreading via webworkers.
      • TekMol 8y ago
        It was disabled because of spectre. Multithreaded WASM isn't here either. I think WASM will face the same security considerations.
      • untog 8y ago
        Webworkers are multithreading. You just have to use slower, async communication methods. WASM will likely be the same way, given the security considerations.
        • pjmlp 8y ago
          WASM will have more low level support. https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md https://github.com/WebAssembly/threads/blob/master/proposals...
  • johncolanduoni 8y ago
    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.
• derefr 8y ago
  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.)
  • kreetx 8y ago
    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)
    • ovao 8y ago
      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).
  • Felz 8y ago
    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?
    • slimsag 8y ago
      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 https://github.com/yurydelendik/wasm-source-map-emscripten
  • eklitzke 8y ago