search

bytecodealliance / wasmtime

A fast and secure runtime for WebAssembly
https://wasmtime.dev/
Apache License 2.0
15.36k stars 1.3k forks source link

Thoughts on Winter (extra-browser web API standardization) #6656

Closed trusktr closed 1 year ago

trusktr commented 1 year ago

I wasn't sure where to post this, as I didn't see some sort of public forum for Bytecode Alliance, so posting here for now.

This project is interesting:

https://wintercg.org/

However it is currently focused only on bringing web APIs to JavaScript engines outside of browsers, and WebAssembly is not part of the picture yet.

I wonder if there's some sort of potential to get WebAssembly into the picture, so that APIs like the File System API can be standardized in a way such that it is usable in both JS engines and Wasm engines.

This would be an alternative to WASI. It would be different, and perhaps not useful for compiling existing and legacy C/C++ apps to WebAssembly, but useful in defining a new generation of applications built on common standards that don't leave the "web" in WebAssembly out of the picture for the new breed of apps that can build on these specs.

philpax commented 1 year ago

Hi! No opinion on the issue itself, but regarding the public forum for the Bytecode Alliance - check out their Zulip: https://bytecodealliance.zulipchat.com

You might be able to get more feedback there :)

linclark commented 1 year ago

@trusktr I think there can sometimes a tendency to see conflict where there isn't one.

We do currently have people active in both the component model work and the Winter CG. The Winter CG is not an alternative to WASI (and WASI is not monolithic; there are multiple different APIs that are being standardized by WASI). I can't speak for the Bytecode Alliance as a whole, but at Fastly we plan to support APIs from both. The one way in which WASI is special is that it forms a target on top of which other APIs can be virtualized, because it includes representations of platform primitives. This means you can have WinterCG-on-top-of-WASI (if that's what you want).

From the Wasmtime perspective, whether an API is Winter CG or WASI doesn't matter. Embedders can choose to provide whatever APIs they want. They can also choose not to include whichever APIs they don't want... it's completely up to what you want to do!

The underlying machinery for exposing the APIs is the same: the Winter CG APIs would be represented using .wit file and various collections of APIs could be brought together in wit worlds. And it would also be possible to define a world that exposes both Winter CG APIs and WASI APIs.

It's this underlying machinery for exposing these APIs that Wasmtime itself is concerned with. Given that the underlying machinery is the same no matter what, any further conversation about the pros and cons of different proposed APIs should probably move somewhere else.

jameysharp commented 1 year ago

Thanks for that thoughtful explanation, @linclark! I'm going to go ahead and close this particular issue as out of scope for Wasmtime.

trusktr commented 1 year ago

I suppose a more important question is, would it be good too officially support the spec, regardless of how it is implemented? (if it is on top of WASI, but people are directly using Winter, it can still be considered an alternative).

Leaving it to library land won't be ideal, won't really make it a standard (I think it could be a good standard!) but would be a way to test it out.