WebAssembly Browser Interface

[redradist]

Consider making WebAssembly as cross-platform low-level language (new LLVM language) without bound it to Browser directly

The same way as in spec https://github.com/WebAssembly/WASI, we can introduce the new spec WABI - WebAssembly Browser Interface

My suggestion is not adding DOM API to WebAssembly, but to add DOM API in WABI - WebAssembly Browser Interface

In this way we will have a cross-platform low-level language that can be bound to any sub-system (Browser Interface, System Interface, GPU Interface) !!

Related links:

nonweb https://github.com/WebAssembly/design/blob/master/NonWeb.md

[Pauan]

There isn't anything tying WebAssembly to the browser, it's already fully cross platform.

WebAssembly is already used in a lot of non-browser cases: as sandboxing in Firefox, in the blockchain (e.g. ewasm), in Lambda AWS, in Cloudflare, etc.

[redradist]

@Pauan

There isn't anything tying WebAssembly to the browser, it's already fully cross platform.

WebAssembly is already used in a lot of non-browser cases: as sandboxing in Firefox, in the blockchain (e.g. ewasm), in Lambda AWS, in Cloudflare, etc.

Why I either bother ? ... Because I see some usefull specification/propousals as DOM API, GPU API and for me it seems like this propousals go to WebAssembly specification

My concern are not that it is cross-platform now, but to leave it is a cross-patform low-level language by default by not tieing it to Browser directly, but instead all Browser specific API provide in separate specification

[Pauan]

@redradist All of the browser specific APIs are already in a separate specification. The browser specific APIs are specified by the W3C:

https://webassembly.github.io/spec/js-api/

The browser APIs are optional, which means that Wasm hosts do not need to implement them. Wasm will always remain cross-platform.

[Horcrux7]

All of the browser specific APIs are already in a separate specification. The browser specific APIs are specified by the W3C:

https://webassembly.github.io/spec/js-api/

@Pauan The request means an inverse API. API which can assess from inside of WASM to the DOM, GPU, etc. Currently you need to write custom JavaScripts code which will be imported. This code will be typical generated with the compiling of the WASM code. If you have multiple modules with a generated JavaScript then this must be loaded multiple times. If there is a standard API then every module can use this API which can reduce load and parse time.

[Pauan]

@Horcrux7 I don't see how that's relevant to this issue. This issue is about making browser-specific APIs optional so that way Wasm remains portable.

And that's already true today: any browser-specific API will be in a separate spec which is optional. I gave an example of one browser-specific API, but there are others:

https://github.com/WebAssembly/JS-BigInt-integration

https://github.com/WebAssembly/esm-integration

https://github.com/WebAssembly/interface-types

[Horcrux7]

My understanding is that the suggestion is an API like WASI for a WASM runtime that run inside a browser or any other WASM runtime with a GUI. And of course is such API optional because not every WASM runtime has a GUI.

What you thing is JavaScript <-> Wasm but the suggestion is Display <-> Wasm without an intermediate JavaScript. A possible use case is app with a GUI without a browser. With the WASI interface you can write command line programs but not programs with a GUI.

[redradist]

@Horcrux7

My understanding is that the suggestion is an API like WASI for a WASM runtime that run inside a browser or any other WASM runtime with a GUI. And of course is such API optional because not every WASM runtime has a GUI.

What you thing is JavaScript <-> Wasm but the suggestion is Display <-> Wasm without an intermediate JavaScript. A possible use case is app with a GUI without a browser. With the WASI interface you can write command line programs but not programs with a GUI.

You are almost right !! There are considering DOM API directly from Wasm to Browser without JavaScript glue code and my suggestion is for any such sub-API create the separate specification ...

Consider the following examples API-s that is accessed from Wasm: 1) Wasm <-> WebAssembly Browser API (directly to browser without JavaScript glue code) Should be a separate specification

2) Wasm <-> WebAssembly GPU API Should be a separate specification

3) Wasm <-> WebAssembly System API Have already a separate specification https://github.com/WebAssembly/WASI

3) WebAssembly Garbage Collector Should be a separate specification Not all systems can support it for performance reason (example is embedded systems with low memory constraint)

4) JavaScript <-> Wasm As well as API from High-level languages like JavaScript Have already a separate specification https://webassembly.github.io/spec/js-api/

The main point of all of this that WebAssembly as it is should be a core base for other building blocks, 'cause it is minimal language for executing some code !!

[Pauan]

@redradist There are considering DOM API directly from Wasm to Browser without JavaScript glue code and my suggestion is for any such sub-API create the separate specification ...

They already are a separate specification, and are optional. What you are asking for already exists.

As I have said multiple times, Wasm will remain low level. High level or browser-specific features will always be optional.

[sbc100]

If eliminating the JavaScript glue code that you currently need to write to web APIs is you goal then most of the interesting work in that area is currently happening in the interface types proposal: https://github.com/WebAssembly/interface-types/.

One of the goals of this proposal is one day to be able consume APIs (including Web APIs) more directly from a just a wasm module by specifying how the types in the wasm module correspond to types outside.

[redradist]

@sbc100

If eliminating the JavaScript glue code that you currently need to write to web APIs is you goal then most of the interesting work in that area is currently happening in the interface types proposal: https://github.com/WebAssembly/interface-types/.

One of the goals of this proposal is one day to be able consume APIs (including Web APIs) more directly from a just a wasm module by specifying how the types in the wasm module correspond to types outside.

Thanks, @sbc100 I know about interface-types ... But my suggestion was leave WebAssembly specification as Core Specification and all other specification should be based on it without extending original one

Like in Rust: 1) libcore (WebAssembly "Core") - for any embedded solution, 2) libstd (WebAssembly System Interface) - basic api ... all other libraries/specifications

[binji]

I think I see what you're getting at @redradist, but the browser already has a specified API, using WebIDL. WebAssembly doesn't need to create its own, it needs a way to integrate with WebIDL. The interface-types proposal is designed to do this, see the section here https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md#web-idl-integration.

[VikasPoddar]

I have a question, if we make the changes and integrate as @binji suggesting, can we make web API independent of JavaScript for WASM. I mean, I want to see WASM interacting web browsers without the intervention of JS.

[fgmccabe]

In the browser, all WebAPIs are currently designed around JS. However, when a wasm module is instantiated, and a webapi function is imported, there may not be any JS between the wasm module and the implementation of the API (depending on the specifics of the API of course).

Note that the 'interface types' work has largely moved to the component model effort, which is alive and under active development - within the WASI subgroup.