5 ms·

Component dependency is pretty wild and could massively simplify some complex apps

Onavo 2y ago
You still need to cross the JS FFI boundary for wasm, I don't think WebAssembly has a specification for cross language FFI directly between WebAssembly languages.
- rgrmrts 2y ago
  Wasm components can talk to each other, you do not need the JS FFI boundary.
  - Onavo 2y ago
    Can you give an example? Say between a wasm component written in Rust and wasm component written in dart.
    - phickey 2y ago
      One of the biggest goals of the component model is that it doesn't matter what language your component is written in. Composition can happen anytime one component exports an interface and another component imports it. https://component-model.bytecodealliance.org/creating-and-consuming/composing.html https://component-model.bytecodealliance.org/creating-and-co...
      - nilslice 2y ago
        won’t happen. all will crumble with the startups pumping it.
        laerus 2y ago
        it's already happening
        nilslice 2y ago
        it’s not. it’s being presented as such. but it’s not.
    - no_circuit 2y ago
      WASM is basically similar to JVM bytecode. So the comparison would be like using compiled code from Java, Scala and/or Kotlin for example. The source language only determines how the code is expressed in WASM and whether or not it also needs to bundle / compile-in some runtime code baggage for it to work.
      - sjrd 2y ago
        I develop the Scala-to-Wasm compiler, and also maintain the JVM backend of Scala. I can tell you that Wasm is very different from JVM bytecode. The fundamental difference is that the JVM bytecode has an object model. When they talk to each other, Java, Scala and Kotlin do so at the abstraction level of the JVM object model. You can directly call methods between them because virtual dispatch of methods is a concept with semantics in the bytecode. There's no such thing in Wasm, even with the GC extension. You get structs and arrays, but nothing like methods. If you want virtual dispatch, you encode it yourself using your own design of virtual method tables. That means Java, Scala and Kotlin, despite all having their Wasm GC backend at this point, cannot call each other's methods in Wasm.
        rapnie 2y ago
        I am confused. You are referring to wasm modules here? And Component Model / WASI / WIT will give us polyglot interface-based programming then, right? Call each other's methods through the WIT interface between components.
        sjrd 2y ago
        Even the component model has nothing to say about the concept of methods. All you have are top-level functions with immutable arguments and immutable results. You can't hold on to an instance of an object created by the other language. You could hold an integer handle, but then you don't get garbage collection across the two languages. So no, we're still a long way from the abstractions of a JVM, even taking the component model into account. It's a good step in the direction of better interoperability between languages, though, don't get me wrong.
no_circuit 2y ago
Yes, its great to see progress in the tooling [1] so that the component building is easier. Although I do like to think of the component model as the "ABI linking model". You can only bind one implementation to an interface import. [1] https://developer.fermyon.com/spin/v3/writing-apps#declaring-component-dependencies https://developer.fermyon.com/spin/v3/writing-apps#declaring...

You still need to cross the JS FFI boundary for wasm, I don't think WebAssembly has a specification for cross language FFI directly between WebAssembly languages.

rgrmrts 2y ago
Wasm components can talk to each other, you do not need the JS FFI boundary.
- Onavo 2y ago
  Can you give an example? Say between a wasm component written in Rust and wasm component written in dart.
  - phickey 2y ago
    One of the biggest goals of the component model is that it doesn't matter what language your component is written in. Composition can happen anytime one component exports an interface and another component imports it. https://component-model.bytecodealliance.org/creating-and-consuming/composing.html https://component-model.bytecodealliance.org/creating-and-co...
    - nilslice 2y ago
      won’t happen. all will crumble with the startups pumping it.
      - laerus 2y ago
        it's already happening
        nilslice 2y ago
        it’s not. it’s being presented as such. but it’s not.
  - no_circuit 2y ago
    WASM is basically similar to JVM bytecode. So the comparison would be like using compiled code from Java, Scala and/or Kotlin for example. The source language only determines how the code is expressed in WASM and whether or not it also needs to bundle / compile-in some runtime code baggage for it to work.
    - sjrd 2y ago
      I develop the Scala-to-Wasm compiler, and also maintain the JVM backend of Scala. I can tell you that Wasm is very different from JVM bytecode. The fundamental difference is that the JVM bytecode has an object model. When they talk to each other, Java, Scala and Kotlin do so at the abstraction level of the JVM object model. You can directly call methods between them because virtual dispatch of methods is a concept with semantics in the bytecode. There's no such thing in Wasm, even with the GC extension. You get structs and arrays, but nothing like methods. If you want virtual dispatch, you encode it yourself using your own design of virtual method tables. That means Java, Scala and Kotlin, despite all having their Wasm GC backend at this point, cannot call each other's methods in Wasm.
      - rapnie 2y ago
        I am confused. You are referring to wasm modules here? And Component Model / WASI / WIT will give us polyglot interface-based programming then, right? Call each other's methods through the WIT interface between components.
        sjrd 2y ago
        Even the component model has nothing to say about the concept of methods. All you have are top-level functions with immutable arguments and immutable results. You can't hold on to an instance of an object created by the other language. You could hold an integer handle, but then you don't get garbage collection across the two languages. So no, we're still a long way from the abstractions of a JVM, even taking the component model into account. It's a good step in the direction of better interoperability between languages, though, don't get me wrong.

no_circuit 2y ago

Yes, its great to see progress in the tooling [1] so that the component building is easier. Although I do like to think of the component model as the "ABI linking model". You can only bind one implementation to an interface import. [1] https://developer.fermyon.com/spin/v3/writing-apps#declaring-component-dependencies https://developer.fermyon.com/spin/v3/writing-apps#declaring...