4 ms·

Making WebAssembly a first-class language on the Web

54 points by mikece 7mo ago

mendyberger 7mo ago
Is `component {}` valid wit syntax? I've never seen that before
- bvisness 7mo ago
  It's proposed here: https://github.com/WebAssembly/component-model/issues/598 https://github.com/WebAssembly/component-model/issues/598 Basically, it's sugar for `package` and `world` in the case where you aren't actually defining a world for others to use, and just for your own use. In such a case, the package and world names are irrelevant anyway.
thesmart 7mo ago
WebAssembly is amazing, but I don't think making it a DOM controller is where the action is. What specific scenarios do you aspire to unlock and why would those scenarios lead to broader adoption?
- yoshuaw 7mo ago
  I think it's less about unlocking new scenarios per se, and more about making existing scenarios better. If given the choice I'll generally prefer to write my code in Rust. But with native Wasm Component-based DOM bindings that same code will now run twice as fast.
  - yoshuaw 7mo ago
    The other side of the story here is also worth considering: native support in browsers provides a stable compile target for language toolchains. It'd be really nice if targeting the web from e.g. Kotlin, Swift, or Rust becomes just a matter of passing the right flag to the compiler.
- bvisness 7mo ago
  > I don't think making it a DOM controller is where the action is Why not? I feel like people have gotten so used to the limitations of WebAssembly today that they've internalized JS as the only answer. But I don't really like JS, and would love to build web apps in other languages, and I totally would if it wasn't a huge pain (and slower too!)
- mendyberger 7mo ago
  > What specific scenarios do you aspire to unlock Modern languages come with lots of interesting features like better dev ex, null safety, etc. Js is a fine language, but there are other languages that bring unique advantages, the web shouldn't block developers from using better tools. The web is best off when developers have freedom.
- justinclift 7mo ago
  Being able to program modern websites without having to learn javascript/typescript in any way? :)
- swiftcoder 7mo ago
  Web development in languages other than Javascript, mostly. Today this would benefit languages like Rust that already have adhoc JS-based glue layers to enable their WASM output to call Web APIs, but you can imagine a future where languages like TypeScript compile directly to WASM instead of transpiling to JS...
nilslice 7mo ago
providing <script type="module" src="component.wasm"></script> and the import loader to just put .wasm in an import and get to call functions are the actual useful things in this post component model is trash
dfabulich 7mo ago
Today, the entire Web API is defined in WebIDL, a specification-only interface-definition language that inherently assumes you have access to JavaScript strings, objects, exceptions, promises, etc. None of those are available in WASM. WebAssembly Components aren't nearly enough to accomplish what this article offers to accomplish. Even once components are a thing, you'd then have to restandardize the entire Web API in their new IDL, WIT. The WebIDL specifications have taken decades to standardize. It requires Apple, Mozilla, Google, and Microsoft to agree on everything. Getting all of them to agree to restandardize on a new IDL is not going to happen this decade.
- mendyberger 7mo ago
  There can be an automated way of translating WebIDL to wit. I've actually tried to do that the past and got pretty far. https://github.com/wasi-gfx/webidl2wit https://github.com/wasi-gfx/webidl2wit And here's the generated wit https://github.com/mendyberger/brow https://github.com/mendyberger/brow
  - mendyberger 7mo ago
    Sorry, here's the working link https://github.com/mendyberger/browser.wit https://github.com/mendyberger/browser.wit
- eqrio 7mo ago
  The article was too long already to get into this, but it's a good question. Getting browser vendors to standardize a new IDL is a non-starter. My personal preference is to derive WIT/component interfaces from WebIDL, and I've done enough research to believe it's feasible. I'll talk about that more in the future. There are some other options too if that is a dead end.

54 points by mikece 7mo ago

mendyberger 7mo ago

Is `component {}` valid wit syntax? I've never seen that before

bvisness 7mo ago
It's proposed here: https://github.com/WebAssembly/component-model/issues/598 https://github.com/WebAssembly/component-model/issues/598 Basically, it's sugar for `package` and `world` in the case where you aren't actually defining a world for others to use, and just for your own use. In such a case, the package and world names are irrelevant anyway.

thesmart 7mo ago

WebAssembly is amazing, but I don't think making it a DOM controller is where the action is. What specific scenarios do you aspire to unlock and why would those scenarios lead to broader adoption?

yoshuaw 7mo ago
I think it's less about unlocking new scenarios per se, and more about making existing scenarios better. If given the choice I'll generally prefer to write my code in Rust. But with native Wasm Component-based DOM bindings that same code will now run twice as fast.
- yoshuaw 7mo ago
  The other side of the story here is also worth considering: native support in browsers provides a stable compile target for language toolchains. It'd be really nice if targeting the web from e.g. Kotlin, Swift, or Rust becomes just a matter of passing the right flag to the compiler.
bvisness 7mo ago
> I don't think making it a DOM controller is where the action is Why not? I feel like people have gotten so used to the limitations of WebAssembly today that they've internalized JS as the only answer. But I don't really like JS, and would love to build web apps in other languages, and I totally would if it wasn't a huge pain (and slower too!)
mendyberger 7mo ago
> What specific scenarios do you aspire to unlock Modern languages come with lots of interesting features like better dev ex, null safety, etc. Js is a fine language, but there are other languages that bring unique advantages, the web shouldn't block developers from using better tools. The web is best off when developers have freedom.
justinclift 7mo ago
Being able to program modern websites without having to learn javascript/typescript in any way? :)
swiftcoder 7mo ago
Web development in languages other than Javascript, mostly. Today this would benefit languages like Rust that already have adhoc JS-based glue layers to enable their WASM output to call Web APIs, but you can imagine a future where languages like TypeScript compile directly to WASM instead of transpiling to JS...

nilslice 7mo ago

providing <script type="module" src="component.wasm"></script> and the import loader to just put .wasm in an import and get to call functions are the actual useful things in this post component model is trash

dfabulich 7mo ago

Today, the entire Web API is defined in WebIDL, a specification-only interface-definition language that inherently assumes you have access to JavaScript strings, objects, exceptions, promises, etc. None of those are available in WASM. WebAssembly Components aren't nearly enough to accomplish what this article offers to accomplish. Even once components are a thing, you'd then have to restandardize the entire Web API in their new IDL, WIT. The WebIDL specifications have taken decades to standardize. It requires Apple, Mozilla, Google, and Microsoft to agree on everything. Getting all of them to agree to restandardize on a new IDL is not going to happen this decade.

mendyberger 7mo ago
There can be an automated way of translating WebIDL to wit. I've actually tried to do that the past and got pretty far. https://github.com/wasi-gfx/webidl2wit https://github.com/wasi-gfx/webidl2wit And here's the generated wit https://github.com/mendyberger/brow https://github.com/mendyberger/brow
- mendyberger 7mo ago
  Sorry, here's the working link https://github.com/mendyberger/browser.wit https://github.com/mendyberger/browser.wit
eqrio 7mo ago
The article was too long already to get into this, but it's a good question. Getting browser vendors to standardize a new IDL is a non-starter. My personal preference is to derive WIT/component interfaces from WebIDL, and I've done enough research to believe it's feasible. I'll talk about that more in the future. There are some other options too if that is a dead end.