Gpuweb: Consider exposing WebGPU as an ES6 module?

[litherum]

ES6 modules have some pretty clear benefits:

https://medium.freecodecamp.org/javascript-modules-a-beginner-s-guide-783f7d7a5fcc
https://developers.google.com/web/fundamentals/primers/modules
https://eloquentjavascript.net/10_modules.html#h_hF2FmOVxw7

We should consider putting WebGPU in an ES6 module.

[kainino0x]

Fine with me, but are built-in modules (platform modules) specced and implemented yet? I thought they were not.

[grovesNL]

Could you clarify what it would mean to expose WebGPU as a module? Would WebGPU be available on the environment regardless?

Is there an example of a web API exposed like this that we could use as a reference?

[frzi]

The Javascript Standard Library proposal is still in stage 1. Although Chrome may be getting its first built-in module soon(-ish?). It could still take years for it to ship as stable in browsers.

That said, WebGPU seems like a great candidate to ship as a built-in module.

@grovesNL

Could you clarify what it would mean to expose WebGPU as a module? Would WebGPU be available on the environment regardless?

Is there an example of a web API exposed like this that we could use as a reference?

The new KV Storage will be the first built-in module available.

If WebGPU were to end up as a built-in module, developers would interact with the API as follows:

import { requestAdapter, GPUBuffer } from 'std:gpu'

const adapter = requestAdapter({})

if (buffer instanceof GPUBuffer) {
  // ...
}
// etc...

For one, this would prevent the window scope from being 'polluted' (pardon the harsh term) with GPU* objects. But this also comes with a few other benefits as explained in the Google dev post.

[kainino0x]

If the release schedules line up I'm all for it.

On Sat, Mar 16, 2019, 9:41 AM Freek Zijlmans [e-mail]
wrote:

The Javascript Standard Library
https://github.com/tc39/proposal-javascript-standard-library proposal
is still in stage 1. Although Chrome may be getting its first built-in
module soon(-ish?)
https://developers.google.com/web/updates/2019/03/kv-storage. It could
still take years for it to ship as stable in browsers.

That said, WebGPU seems like a great candidate to ship as a built-in
module.

@grovesNL https://github.com/grovesNL

Could you clarify what it would mean to expose WebGPU as a module? Would
WebGPU be available on the environment regardless?

Is there an example of a web API exposed like this that we could use as a
reference?

The new KV Storage https://github.com/WICG/kv-storage will be the first
built-in module available.

If WebGPU were to end up as a built-in module, developers would interact
with the API as followed:

import { requestAdapter, GPUBuffer } from 'std:gpu'
const adapter = requestAdapter({})
if (buffer instanceof GPUBuffer) {
// ...
}// etc...

For one, this would prevent the window scope from being 'polluted'
(pardon the harsh term) with GPU* objects. But this also comes with a few
other benefits as explained in the Google dev post.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/gpuweb/gpuweb/issues/243#issuecomment-473563463, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAlAk44-9q8e3ityDk5SVHvUuwMqKooyks5vXR6rgaJpZM4b3i2X
.

[litherum]

Today we resolved to table this idea until the concept of native JS modules is more developed.

[kainino0x]

FYI, looks like KV Storage exists now:

https://developers.google.com/web/updates/2019/03/kv-storage

In Chrome 74+, behind chrome://flags/#enable-experimental-web-platform-features .