Deno 1.39: The Return of WebGPU • Hacker News Board

Re: Deno 1.39: The Return of WebGPU

#41

Post by TachyonicBytes » Thu, Dec 14, 2023, 5:41 PM UTC

kwhinnery wrote: post #33

flohofwoe wrote: post #4

Now all that's left to do is to integrate a minimal native system glue library into Deno (create a window with a WebGPU canvas, receive input events, audio buffer streaming) and it would be a nice little platform to build and distribute small games and graphics demos written in WebAssembly and/or Typescript :)

I think the ecosystem is inching in this direction. There are already some interesting PoCs out there using Tauri (Rust based) and the deno_core Rust crate.

Do you have links to some of the more non-trivial ones?

Offtopic: Does anybody know if the WebAssembly runtime inside deno (which is actually the runtime inside v8) is exposed by any of the deno crates? A cursory search seems to indicate that it isn't. You can access it from `deno_core` through javascript, of course.

Re: Deno 1.39: The Return of WebGPU

#42

Post by Jasper_ » Thu, Dec 14, 2023, 5:44 PM UTC

NTARelix wrote: post #31

I've been wondering for a long time when we might expect to see a stable WebGPU API in all major browsers (mostly concerned with my daily browser, Firefox), so I've been looking for an official message on the topic. Deno claims the spec is ready > The [WebGPU] spec has been finalized but the official WebGPU spec [1] still describes it as a draft. Have I misinterpreted something here or is there some missing context a…

In the W3C process, in order for a TR to upgrade from a Draft to a finished specification, it needs two shipping implementations. Firefox and Safari are both working on theirs. We hope the only changes involved in this process will be minor and/or editorial. Once a second implementation ships, it will move out of draft.

Re: Deno 1.39: The Return of WebGPU

#43

Post by [deleted] » Thu, Dec 14, 2023, 5:47 PM UTC

TachyonicBytes wrote: post #41

kwhinnery wrote: post #33

Earlier quoted context omitted.

I think the ecosystem is inching in this direction. There are already some interesting PoCs out there using Tauri (Rust based) and the deno_core Rust crate.

Do you have links to some of the more non-trivial ones? Offtopic: Does anybody know if the WebAssembly runtime inside deno (which is actually the runtime inside v8) is exposed by any of the deno crates? A cursory search seems to indicate that it isn't. You can access it from `deno_core` through javascript, of course.

[deleted]

Re: Deno 1.39: The Return of WebGPU

#44

Post by paxys » Thu, Dec 14, 2023, 5:50 PM UTC

flohofwoe wrote: post #35

paxys wrote: post #23

Earlier quoted context omitted.

And call it "Electron"?

It would be a much smaller and more efficient product than Electron because it wouldn't include a bundled web browser.

How would it be any different from Electron if it bundled a JS/Webassembly engine (V8, which it already does) and a HTML canvas renderer (which would most likely be Blink)?

Re: Deno 1.39: The Return of WebGPU

#45

Post by fulafel » Thu, Dec 14, 2023, 5:53 PM UTC

NTARelix wrote: post #31

I've been wondering for a long time when we might expect to see a stable WebGPU API in all major browsers (mostly concerned with my daily browser, Firefox), so I've been looking for an official message on the topic. Deno claims the spec is ready > The [WebGPU] spec has been finalized but the official WebGPU spec [1] still describes it as a draft. Have I misinterpreted something here or is there some missing context a…

There seem to be no current 1.0 discussions yet on the GitHub prpject, seems possible it's a mistake at the Deno end.

Re: Deno 1.39: The Return of WebGPU

#46

Post by flohofwoe » Thu, Dec 14, 2023, 5:55 PM UTC

paxys wrote: post #44

flohofwoe wrote: post #35

Earlier quoted context omitted.

It would be a much smaller and more efficient product than Electron because it wouldn't include a bundled web browser.

How would it be any different from Electron if it bundled a JS/Webassembly engine (V8, which it already does) and a HTML canvas renderer (which would most likely be Blink)?

It would not bundle a HTML canvas renderer, only WebGPU rendering to a native window's client area.

HTML+CSS would be left out entirely.

Re: Deno 1.39: The Return of WebGPU

#47

Post by paxys » Thu, Dec 14, 2023, 6:10 PM UTC

flohofwoe wrote: post #46

paxys wrote: post #44

Earlier quoted context omitted.

How would it be any different from Electron if it bundled a JS/Webassembly engine (V8, which it already does) and a HTML canvas renderer (which would most likely be Blink)?

It would not bundle a HTML canvas renderer, only WebGPU rendering to a native window's client area. HTML+CSS would be left out entirely.

Unless the Deno folks want to write that renderer from scratch, the only usable implementation right now is...part of Chromium.

Re: Deno 1.39: The Return of WebGPU

#48

Post by test098 » Thu, Dec 14, 2023, 6:28 PM UTC

v3ss0n wrote: post #7

kiwicopple wrote: post #2

This is exciting > The WebGPU API gives developers a low level, high performance, cross architecture way to program GPU hardware from JavaScript. It is the effective successor to WebGL on the Web. The spec has been finalized and Chrome has already shipped the API. Support is underway in Firefox and Safari. Interestingly, the Deno team previously attempted[0] this and rolled it back due to instability. Once this is st…

JavaScript is useless for data exploration, that's why very little data scientist uses JavaScript and all kinds of none white spaces languages. Curly braces doesn't work well in iterative explorative programming

i've built an entire career building apps and tools in JS for data scientists to explore complex data. tons of companies pay lots and lots of money for this - i'm currently at a FAANG doing exactly this with data scientists.

Re: Deno 1.39: The Return of WebGPU

#49

Post by notnullorvoid » Thu, Dec 14, 2023, 6:29 PM UTC

paxys wrote: post #47

flohofwoe wrote: post #46

Earlier quoted context omitted.

It would not bundle a HTML canvas renderer, only WebGPU rendering to a native window's client area. HTML+CSS would be left out entirely.

Unless the Deno folks want to write that renderer from scratch, the only usable implementation right now is...part of Chromium.

No it's not. WGPU (a WebGPU renderer built with rust) which is what Deno is using under the hood in this change, works perfectly well and is used by many other projects. Even if that were not the case Chrome's WebGPU implementation is also available separately and it's called dawn.

Re: Deno 1.39: The Return of WebGPU

#50

Post by notnullorvoid » Thu, Dec 14, 2023, 6:46 PM UTC

kiwicopple wrote: post #2

This is exciting > The WebGPU API gives developers a low level, high performance, cross architecture way to program GPU hardware from JavaScript. It is the effective successor to WebGL on the Web. The spec has been finalized and Chrome has already shipped the API. Support is underway in Firefox and Safari. Interestingly, the Deno team previously attempted[0] this and rolled it back due to instability. Once this is st…

Small correction: It wasn't rolled back due to instability, it was because it increased deno startup time even for programs that weren't making use of WebGPU apis. That is no longer the case this time around.

As someone who detests python, I really hope we can get some good TS WebGPU libs going. In fact any ML lib using WebGPU under the hood would be quite portable to other languages and platforms.