3 ms·

Does it really make sense to run so much inside a web browser? Are we perhaps over-utilizing web browsers?

adam_arthur 3y ago
WASM is not strictly for the web, its a generic low-level language target/series of specs. The article itself is talking about server runtimes/workloads, nothing to do with browsers. If generic specs can be built around WASM in such a way that you can run code securely without booting an entire OS, WASM will replace traditional containers. Smaller runtime footprint. A consequence of having a generic compile target/spec is that your applications will also be able to run in the browser with minimal effort
- jjtheblunt 3y ago
  > WASM is not strictly for the web, its a generic low-level language target/series of specs. What about it is preferable to MLIR or even LLVM? https://mlir.llvm.org/ https://mlir.llvm.org/
  - adam_arthur 3y ago
    WASM is designed with security in mind, and specifically to provide primitives for use in a secure runtime. LLVM doesn't provide that to my knowledge... instead just cross-compiling code specific to each target. Correct me if mistaken. I imagine there are meaningful build time drawbacks to compiling an executable for each environment as well. While WASM will never outperform native code, it can get very close. Minor loss in performance is a small price to pay for portability/security.
stanleydrew 3y ago
At the risk of taking the bait, I'll point out that WASM doesn't just run in web browsers.
- SirMaster 3y ago
  I didn't realize that it was used outside of web browsers too.
- Alupis 3y ago
  For those of us who have paid no attention to WASM - what is the difference between WASM and old tech like Java Applets? They seem to have similar goals - write once and run it on all the things... Applets had issues, but the pitch seems similar, no? If that is the case, why was a new standard necessary vs. bytecode from JVM or CLR, for instance?
  - preseinger 3y ago
    they're indeed very similar the main difference distills down to execution/implementation java applets were slow, wasm is fast that distinction makes a categorical difference
    - Alupis 3y ago
      It seems there would still be some sort of interpreter for WASM - meaning any performance gains could have been made using existing bytecode interpreters. I'm probably wrong on that assumption, but am unclear why. I guess I'm wondering what makes WASM so much better than investing engineering energies into existing things.
      - preseinger 3y ago
        wasm compiles to "native" code, for whatever "native" means in your execution environment if you're deploying wasm to the browser, then native means your JS engine if you're deploying wasm to the server, then native means actual machine code the competitive advantage versus java is (at a very high level) the language design -- java is much higher-level than wasm, which limits its potential
  - Deukhoofd 3y ago
    It's an open standardized bytecode that's specifically designed to be easy to implement, which means there are already a lot of different runtimes that implement it, so you're not required to have for example JRE or a .NET runtime installed. Because of this simplicity it is also an easy target to compile to, which means that many languages can already be compiled to it.

WASM is not strictly for the web, its a generic low-level language target/series of specs. The article itself is talking about server runtimes/workloads, nothing to do with browsers. If generic specs can be built around WASM in such a way that you can run code securely without booting an entire OS, WASM will replace traditional containers. Smaller runtime footprint. A consequence of having a generic compile target/spec is that your applications will also be able to run in the browser with minimal effort

jjtheblunt 3y ago
> WASM is not strictly for the web, its a generic low-level language target/series of specs. What about it is preferable to MLIR or even LLVM? https://mlir.llvm.org/ https://mlir.llvm.org/
- adam_arthur 3y ago
  WASM is designed with security in mind, and specifically to provide primitives for use in a secure runtime. LLVM doesn't provide that to my knowledge... instead just cross-compiling code specific to each target. Correct me if mistaken. I imagine there are meaningful build time drawbacks to compiling an executable for each environment as well. While WASM will never outperform native code, it can get very close. Minor loss in performance is a small price to pay for portability/security.

stanleydrew 3y ago

At the risk of taking the bait, I'll point out that WASM doesn't just run in web browsers.

SirMaster 3y ago
I didn't realize that it was used outside of web browsers too.
Alupis 3y ago
For those of us who have paid no attention to WASM - what is the difference between WASM and old tech like Java Applets? They seem to have similar goals - write once and run it on all the things... Applets had issues, but the pitch seems similar, no? If that is the case, why was a new standard necessary vs. bytecode from JVM or CLR, for instance?
- preseinger 3y ago
  they're indeed very similar the main difference distills down to execution/implementation java applets were slow, wasm is fast that distinction makes a categorical difference
  - Alupis 3y ago
    It seems there would still be some sort of interpreter for WASM - meaning any performance gains could have been made using existing bytecode interpreters. I'm probably wrong on that assumption, but am unclear why. I guess I'm wondering what makes WASM so much better than investing engineering energies into existing things.
    - preseinger 3y ago
      wasm compiles to "native" code, for whatever "native" means in your execution environment if you're deploying wasm to the browser, then native means your JS engine if you're deploying wasm to the server, then native means actual machine code the competitive advantage versus java is (at a very high level) the language design -- java is much higher-level than wasm, which limits its potential
- Deukhoofd 3y ago
  It's an open standardized bytecode that's specifically designed to be easy to implement, which means there are already a lot of different runtimes that implement it, so you're not required to have for example JRE or a .NET runtime installed. Because of this simplicity it is also an easy target to compile to, which means that many languages can already be compiled to it.