5 ms·

They wants to run JS faster, on platforms where they can run Swift/native with zero overhead. As of why? Go figure.

lxgr 5y ago
If you're talking about iOS, if you can run WASM, you can run JITted JavaScript. I highly doubt that it's possible to beat the performance of JavaScriptCode (in JIT mode) with any WASM-based implementation.
- wffurr 5y ago
  Depends on whether your JS is limited by interpreter / JIT startup time or throughput. If it's the former, then the wasm module with wizer might be significantly faster.
gostsamo 5y ago
Serverless is mentioned a few times in the text of the article. More generally, WASM is promoted as universal bytecode virtual machine, so they want to make it "run everything everywhere".
- oscargrouch 5y ago
  I think WASM will have a great future in the cloud, giving cloud providers can offer their services in any programming language their users want, running in a secure sandbox. But i'm not so sure about personal devices. It would be very hard to beat Javascript code on the Web in general. So i dont know about the general purpose target future in that case, i think it will flop, except as a fancy accelerator or to virtualize things that was once outside the web.
  - ygjb 5y ago
    While there will always be the case that highly optimized javascript code will be more performant, the flexibility and performance of WASM on the web and in browsers means that a significant number of high impact products and services have already made the jump to using WASM in part or in full. https://madewithwebassembly.com/all-projects https://madewithwebassembly.com/all-projects
- johnnycerberus 5y ago
  Isn't this what the JVM already does?
  - lxgr 5y ago
    As far as I understand, Hotspot is such an excellent VM arhat some languages have been adapted for it as a compilation/execution target; it‘s not particularly well suited for running other languages. Especially dynamic languages have been struggling with inefficiencies imposed by some of the Java-orientied paradigms. WASM does not provide a garbage collector, as another example; this probably makes non-garbage-collected languages behave more predictably.
    - kaba0 5y ago
      > Especially dynamic languages have been struggling with inefficiencies imposed by some of the Java-orientied paradigms. I don’t think it is anywhere close to the truth. They are very well suited, as the JIT compiler can specialize dynamic types (and optionally deoptimize them when the type changes). There are also clojure, jruby, a python implementation, and java can also be written with significant use of reflection. And then there is GraalVM built on top of the JVM that has truffleruby, the fastest Ruby implementation, graaljs which has very comparable performance to v8 with comparatively much less man hours , etc, all very dynamic languages.
      - lxgr 5y ago
        Was that true even before `invokedynamic`, which as far as I know was specifically added to make these non-Java languages easier to port and more performant? All of the examples you‘ve mentioned don‘t seem like trivial ports at least from an outsider‘s point of view. The JVM itself has definitely adapted to these use cases, but it wasn‘t designed with them in mind.
        kaba0 5y ago
        You are right about the reason invokedynamic was added, but as far as I know the JVM always supported dynamic class loading (and thus class creation as well), so while not necessarily in a too performant manner, it could always be used as a runtime for even very dynamic languages. (And I think I left out Groovy which is a quite old dynamic language on the JVM).
- slver 5y ago
  I can't wait for this fad to be over.
- pjmlp 5y ago
  Yeah, by those that forgot to read their history books.
  - imtringued 5y ago
    You get to run your own flavor of Java on the JVM, some people want more than that.
    - pjmlp 5y ago
      Another example of my comment. JVM wasn't the first nor the only bytecode format around. The early ones go back to 1961, and there are plenty of multiple language ones.
filleduchaos 5y ago
The gamedev industry will no doubt be shocked to learn that they could have just been running native with zero overhead instead of implementing and embedding various forms of scripting.

lxgr 5y ago

If you're talking about iOS, if you can run WASM, you can run JITted JavaScript. I highly doubt that it's possible to beat the performance of JavaScriptCode (in JIT mode) with any WASM-based implementation.

wffurr 5y ago
Depends on whether your JS is limited by interpreter / JIT startup time or throughput. If it's the former, then the wasm module with wizer might be significantly faster.

gostsamo 5y ago

Serverless is mentioned a few times in the text of the article. More generally, WASM is promoted as universal bytecode virtual machine, so they want to make it "run everything everywhere".

oscargrouch 5y ago
I think WASM will have a great future in the cloud, giving cloud providers can offer their services in any programming language their users want, running in a secure sandbox. But i'm not so sure about personal devices. It would be very hard to beat Javascript code on the Web in general. So i dont know about the general purpose target future in that case, i think it will flop, except as a fancy accelerator or to virtualize things that was once outside the web.
- ygjb 5y ago
  While there will always be the case that highly optimized javascript code will be more performant, the flexibility and performance of WASM on the web and in browsers means that a significant number of high impact products and services have already made the jump to using WASM in part or in full. https://madewithwebassembly.com/all-projects https://madewithwebassembly.com/all-projects
johnnycerberus 5y ago
Isn't this what the JVM already does?
- lxgr 5y ago
  As far as I understand, Hotspot is such an excellent VM arhat some languages have been adapted for it as a compilation/execution target; it‘s not particularly well suited for running other languages. Especially dynamic languages have been struggling with inefficiencies imposed by some of the Java-orientied paradigms. WASM does not provide a garbage collector, as another example; this probably makes non-garbage-collected languages behave more predictably.
  - kaba0 5y ago
    > Especially dynamic languages have been struggling with inefficiencies imposed by some of the Java-orientied paradigms. I don’t think it is anywhere close to the truth. They are very well suited, as the JIT compiler can specialize dynamic types (and optionally deoptimize them when the type changes). There are also clojure, jruby, a python implementation, and java can also be written with significant use of reflection. And then there is GraalVM built on top of the JVM that has truffleruby, the fastest Ruby implementation, graaljs which has very comparable performance to v8 with comparatively much less man hours , etc, all very dynamic languages.
    - lxgr 5y ago
      Was that true even before `invokedynamic`, which as far as I know was specifically added to make these non-Java languages easier to port and more performant? All of the examples you‘ve mentioned don‘t seem like trivial ports at least from an outsider‘s point of view. The JVM itself has definitely adapted to these use cases, but it wasn‘t designed with them in mind.
      - kaba0 5y ago
        You are right about the reason invokedynamic was added, but as far as I know the JVM always supported dynamic class loading (and thus class creation as well), so while not necessarily in a too performant manner, it could always be used as a runtime for even very dynamic languages. (And I think I left out Groovy which is a quite old dynamic language on the JVM).
slver 5y ago
I can't wait for this fad to be over.
pjmlp 5y ago
Yeah, by those that forgot to read their history books.
- imtringued 5y ago
  You get to run your own flavor of Java on the JVM, some people want more than that.
  - pjmlp 5y ago
    Another example of my comment. JVM wasn't the first nor the only bytecode format around. The early ones go back to 1961, and there are plenty of multiple language ones.

filleduchaos 5y ago

The gamedev industry will no doubt be shocked to learn that they could have just been running native with zero overhead instead of implementing and embedding various forms of scripting.