The WebGPU spec is a new W3C specification to expose a machine’s GPU to JS. It is currently in active development and, as such, its WebIDL changes quite often.
Since the spec changes quite often, the N-API bindings need to be re-written quite often as well. It would therefore be beneficial to have a WebIDL compiler that generates the N-API calls necessary for creating the JS interface defined by the WebIDL. In the case of WebGPU-NAPI, for example, this would allow the manually-written code to become drastically smaller, implementing only WebGPU-specific logic and not standard Web API behaviors.
N-API has proven useful outside the Node.js ecosystem as well. For example, WebGPU-NAPI is not Node.js/V8 dependent. While a N-API add-on (binary runtime library) can be very easily loaded as a module into a Node.js/V8 environment, N-API also and most importantly allows direct integration into any native C++ application. This allows direct integration with any version of any JS engine API that provides N-API (currently V8, ChakraCore, IoT.js, and JavascriptCore, with SpiderMonkey as an additional target). This provides N-API’s much desired ABI stability guarantee to encapsulate native backend JS engine API changes. Thus, projects using webidl-napi would be able to target not only Node.js, but the aforementioned N-API implementations as well.
Also note that WebIDL-NAPI should similarly not introduce Node.js dependencies in the add-on. While WebIDL-NAPI add-ons can be built and loaded with Node.js, the resulting runtime library should still be independent of Node.js.
Such a WebIDL compiler has potential benefits outside of WebGPU-NAPI as well. It may provide a mechanism for creating add-ons from a more JS-centric perspective and, as it would do for WebGPU-NAPI, it would reduce the maintenance load for add-on maintainers by removing the burden of having to write what amounts to boilerplate logic, allowing them to concentrate on the value their add-on provides.
Since the proposed tool is strongly linked to both N-API and Web standards, we would like to propose the creation of a repository named webidl-napi under the nodejs organization, with the initial group of collaborators listed below.
Structure
The repository would host a JS-only npm package that would produce the command line tool webidl-napi, a compiler in that it accepted a WebIDL file as input and produced a C++ source file as output. The tool could be used as part of a build system.
The compiler would make the bindings available via a lowest-common-denominator entry point and leave the responsibility of integrating the bindings into the add-on’s environment to the rest of its code base.
Roadmap
Initially there would be heavy development in order to cover the WebGPU WebIDL. Assuming that the WebGPU WebIDL does not make use of the entire WebIDL spec, the missing coverage would be added later as needed.
Purpose
The WebGPU spec is a new W3C specification to expose a machine’s GPU to JS. It is currently in active development and, as such, its WebIDL changes quite often.
WebGPU-NAPI
is a project that provides N-API bindings for native implementations of WebGPU adhering to https://github.com/webgpu-native/webgpu-headers, such as Google’s Dawn or wgpu-native. Inwebgpu-napi
, the JS interface described by the WebGPU WebIDL is manually implemented using N-API.Since the spec changes quite often, the N-API bindings need to be re-written quite often as well. It would therefore be beneficial to have a WebIDL compiler that generates the N-API calls necessary for creating the JS interface defined by the WebIDL. In the case of
WebGPU-NAPI
, for example, this would allow the manually-written code to become drastically smaller, implementing only WebGPU-specific logic and not standard Web API behaviors.N-API has proven useful outside the Node.js ecosystem as well. For example,
WebGPU-NAPI
is not Node.js/V8 dependent. While a N-API add-on (binary runtime library) can be very easily loaded as a module into a Node.js/V8 environment, N-API also and most importantly allows direct integration into any native C++ application. This allows direct integration with any version of any JS engine API that provides N-API (currently V8, ChakraCore, IoT.js, and JavascriptCore, with SpiderMonkey as an additional target). This provides N-API’s much desired ABI stability guarantee to encapsulate native backend JS engine API changes. Thus, projects usingwebidl-napi
would be able to target not only Node.js, but the aforementioned N-API implementations as well.Also note that WebIDL-NAPI should similarly not introduce Node.js dependencies in the add-on. While WebIDL-NAPI add-ons can be built and loaded with Node.js, the resulting runtime library should still be independent of Node.js.
Such a WebIDL compiler has potential benefits outside of
WebGPU-NAPI
as well. It may provide a mechanism for creating add-ons from a more JS-centric perspective and, as it would do forWebGPU-NAPI
, it would reduce the maintenance load for add-on maintainers by removing the burden of having to write what amounts to boilerplate logic, allowing them to concentrate on the value their add-on provides.Since the proposed tool is strongly linked to both N-API and Web standards, we would like to propose the creation of a repository named
webidl-napi
under thenodejs
organization, with the initial group of collaborators listed below.Structure
The repository would host a JS-only npm package that would produce the command line tool
webidl-napi
, a compiler in that it accepted a WebIDL file as input and produced a C++ source file as output. The tool could be used as part of a build system.The compiler would make the bindings available via a lowest-common-denominator entry point and leave the responsibility of integrating the bindings into the add-on’s environment to the rest of its code base.
Roadmap
Initially there would be heavy development in order to cover the WebGPU WebIDL. Assuming that the WebGPU WebIDL does not make use of the entire WebIDL spec, the missing coverage would be added later as needed.
Initial Collaborators
@gabrielschulhof (Intel) @kainino0x (Google) @cerisano (Kings Distributed Systems) @austineng (Google)