4 ms·

Great work, WASM is the future! But on the other hand I'm not really happy with the fact that I'm waiting for GC and DOM access since 2019 or something like th

Great work, WASM is the future! But on the other hand I'm not really happy with the fact that I'm waiting for GC and DOM access since 2019 or something like that and it doesn't seem like we're getting close

k__ 4y ago
They just want to protect the frontend from the C#/Java crowd.
- tester756 4y ago
  No chance, we're already compiling those to our wasm-based frontend apps
  - throwaway290 4y ago
    You can run Java in the browser now but at least you can't touch DOM...
skohan 4y ago
What compromises does WASM have relative to plain old native code?
- mikesir87 4y ago
  There are a few things we're excited about, many of which we fully recognize are used in marketing/buzzword bingo. But, they really are around portability (compile to a Wasm module and run on any architecture), isolated sandboxing (leveraging much of the research and investment used to protect web browsers), and super fast startups (obviously depends on the app too). There are a few limitations right now, some of which lack of built-in garbage collection and multi-threading. You also have to use a language that can completely compile to Wasm, making it hard (sometimes impossible) to leverage already built libraries/binaries. But... the tech is growing rapidly and we're excited for it! Happy to dive in or answer more questions if you'd like!
  - skohan 4y ago
    Yeah it's a super interesting topic, thanks for sharing! A couple questions: 1. What use cases are you targeting, or which ones do you think have the most benefits from wasm? 2. What tools/stack are you currently using, or which ones do you think are the most promising?
- paulgb 4y ago
  One thing I've seen come up a lot is that people got used to treating containers as a portable unit of code, and then Apple Silicon threw a wrench in that assumption. A WASM module is the same regardless of whether you're running it on arm, amd, or anything. (Alas, the cost of this portability is that it's 32-bit)
- saidinesh5 4y ago
  Wasm = just a bunch of bytecode executing in a VM / a sandbox. Even with JIT, it will still be slower than the native code. And since it is a sandbox.. either you, or your friendly wasm interpreter (via. wasi etc...) needs to provide the system access APIs for various things like storage/filesystem access, hardware acceleration via. GPU, TPU etc.. And some of the standard APIs we take for granted.
  - skohan 4y ago
    Is WASM typically interpreted? I would have assumed one of the advantages of an assembly language is it would be easy to JIT compile down to machine code.
    - saidinesh5 4y ago
      That depends on the runtime. Some runtimes like wasmtime support both JIT and AOT compilation. And for places where you can't use JIT compilation (like iOS... - which is where most of the users/developers of our app were) there are interpreters like wasm3.
      - skohan 4y ago
        Is wasm3 built in to iOS, or is that something you have to bundle with your app?
        saidinesh5 4y ago
        Wasm3 is just an interpreter you can/have to bundle with your app. There was supposed to be a way to use the webassembly interpreter from JSCore but i am afraid my iOS knowledge doesn't go that far.
deleted 4y ago
[deleted]
azakai 4y ago
There has been a large amount of progress on wasm GC actually! If you haven't been attending the group meetings though then you might have missed it. In particular: * The GC MVP spec is mostly done at this point. * There are working toolchains for multiple languages: Java, Dart, Kotlin, and others have begun work as well. * We will have a Phase 3 vote this week.

k__ 4y ago

They just want to protect the frontend from the C#/Java crowd.

tester756 4y ago
No chance, we're already compiling those to our wasm-based frontend apps
- throwaway290 4y ago
  You can run Java in the browser now but at least you can't touch DOM...

skohan 4y ago

What compromises does WASM have relative to plain old native code?

mikesir87 4y ago
There are a few things we're excited about, many of which we fully recognize are used in marketing/buzzword bingo. But, they really are around portability (compile to a Wasm module and run on any architecture), isolated sandboxing (leveraging much of the research and investment used to protect web browsers), and super fast startups (obviously depends on the app too). There are a few limitations right now, some of which lack of built-in garbage collection and multi-threading. You also have to use a language that can completely compile to Wasm, making it hard (sometimes impossible) to leverage already built libraries/binaries. But... the tech is growing rapidly and we're excited for it! Happy to dive in or answer more questions if you'd like!
- skohan 4y ago
  Yeah it's a super interesting topic, thanks for sharing! A couple questions: 1. What use cases are you targeting, or which ones do you think have the most benefits from wasm? 2. What tools/stack are you currently using, or which ones do you think are the most promising?
paulgb 4y ago
One thing I've seen come up a lot is that people got used to treating containers as a portable unit of code, and then Apple Silicon threw a wrench in that assumption. A WASM module is the same regardless of whether you're running it on arm, amd, or anything. (Alas, the cost of this portability is that it's 32-bit)
saidinesh5 4y ago
Wasm = just a bunch of bytecode executing in a VM / a sandbox. Even with JIT, it will still be slower than the native code. And since it is a sandbox.. either you, or your friendly wasm interpreter (via. wasi etc...) needs to provide the system access APIs for various things like storage/filesystem access, hardware acceleration via. GPU, TPU etc.. And some of the standard APIs we take for granted.
- skohan 4y ago
  Is WASM typically interpreted? I would have assumed one of the advantages of an assembly language is it would be easy to JIT compile down to machine code.
  - saidinesh5 4y ago
    That depends on the runtime. Some runtimes like wasmtime support both JIT and AOT compilation. And for places where you can't use JIT compilation (like iOS... - which is where most of the users/developers of our app were) there are interpreters like wasm3.
    - skohan 4y ago
      Is wasm3 built in to iOS, or is that something you have to bundle with your app?
      - saidinesh5 4y ago
        Wasm3 is just an interpreter you can/have to bundle with your app. There was supposed to be a way to use the webassembly interpreter from JSCore but i am afraid my iOS knowledge doesn't go that far.

deleted 4y ago

[deleted]

azakai 4y ago

There has been a large amount of progress on wasm GC actually! If you haven't been attending the group meetings though then you might have missed it. In particular: * The GC MVP spec is mostly done at this point. * There are working toolchains for multiple languages: Java, Dart, Kotlin, and others have begun work as well. * We will have a Phase 3 vote this week.