4 ms·

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 buff

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 :)

rough-sea 3y ago
excellent idea! and use `deno compile` to ship it as a self contained binary
andsoitis 3y ago
> integrate a minimal native system glue library into Deno have you tried denog (fork of deno which uses winit for Windowing and also has WebGPU support)? https://github.com/denogdev/denog https://github.com/denogdev/denog As for deno proper, according to this thread, it looks like one of the Deno maintainers has been working on Windowing support, also using winit (same as denog linked above) - https://github.com/gfx-rs/wgpu/pull/3265#issuecomment-1400650492 https://github.com/gfx-rs/wgpu/pull/3265#issuecomment-140065...
- flohofwoe 3y ago
  That's fantastic!
- MuffinFlavored 3y ago
  I'm curious why they needed to fork Deno to achieve this. There wasn't a way to achieve this as like a library/3rd party package/wrapper or something? The fork is already ~1700 commits out of date with the original. How often would they sync, etc.?
  - lytedev 3y ago
    Maybe it was a bit simpler to pull in the Rust crates and add bindings. I've read that modifying and extending Deno is relatively easy to do in this way?
    - MuffinFlavored 3y ago
      Upfront simpler short term solution, 100%. Impressive too I might add. I love stuff like this. Turning "scripting language JavaScript/TypeScript" into cross-platform usable GUI that can do like <canvas> and 3D rendering if I understand correctly? So cool. I just "worry" (in an unsolicited advice fashion might I add) is there a better alternative to maintain this longterm
olestr 3y ago
The initial WebGPU Standard Library is such a promising step in this direction!
CyberDildonics 3y ago
Why wouldn't you just make a game that runs in a browser at that point?
- flohofwoe 3y ago
  Same reason why Electron exists, but in a much smaller bundle (since most of the actual browser engine wouldn't be included). This would also be an opportunity to build better cross-platform APIs than what's available in browsers (e.g. WebAudio, fullscreen, pointer lock, text input (input in general), networking, ... are all a royal PITA on the web - basically any web API that isn't WebGL or WebGPU is mostly broken or half-assed).
  - pjmlp 3y ago
    That is what middleware is for. So lets call it a game engine using JavaScript, instead of the usual ones.
    - deleted 3y ago
      [deleted]
    - flohofwoe 3y ago
      If you want to call something simple like winit, GLFW or SDL a 'middleware' then yes. It definitely would not be a game engine in the popular sense like UE or Unity, those are way to bloated for most use cases such a minimal cross-platform wrapper would be good for. It would be something you could build a game engine on top though.
    - timschmidt 3y ago
      It's more a cross platform UI tooklkit built around web standards.
- aseipp 3y ago
  It would just be a nice way to turn your standalone WASM game into an .exe (or whatever equivalent) without needing too much extra stuff, like if you wanted to distribute a version on Steam, or offer multiple downloads like itch.io does. It's nothing groundbreaking. It would just be a nice and convenient, is all.
paxys 3y ago
And call it "Electron"?
- flohofwoe 3y ago
  It would be a much smaller and more efficient product than Electron because it wouldn't include a bundled web browser.
  - paxys 3y ago
    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)?
    - flohofwoe 3y ago
      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.
      - paxys 3y ago
        Unless the Deno folks want to write that renderer from scratch, the only usable implementation right now is...part of Chromium.
        notnullorvoid 3y ago
        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.
        flohofwoe 3y ago
        The browser WebGPU implementations are available as native standalone libraries and are fairly easy (YMMV, especially for Dawn) to integrate into regular native applications: Chrome's implementation (C++): https://dawn.googlesource.com/dawn https://dawn.googlesource.com/dawn Firefox's implementation (Rust): https://github.com/gfx-rs/wgpu/ https://github.com/gfx-rs/wgpu/
kwhinnery 3y ago
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.
- TachyonicBytes 3y ago
  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 3y ago
    [deleted]

rough-sea 3y ago

excellent idea! and use `deno compile` to ship it as a self contained binary

andsoitis 3y ago

> integrate a minimal native system glue library into Deno have you tried denog (fork of deno which uses winit for Windowing and also has WebGPU support)? https://github.com/denogdev/denog https://github.com/denogdev/denog As for deno proper, according to this thread, it looks like one of the Deno maintainers has been working on Windowing support, also using winit (same as denog linked above) - https://github.com/gfx-rs/wgpu/pull/3265#issuecomment-1400650492 https://github.com/gfx-rs/wgpu/pull/3265#issuecomment-140065...

flohofwoe 3y ago
That's fantastic!
MuffinFlavored 3y ago
I'm curious why they needed to fork Deno to achieve this. There wasn't a way to achieve this as like a library/3rd party package/wrapper or something? The fork is already ~1700 commits out of date with the original. How often would they sync, etc.?
- lytedev 3y ago
  Maybe it was a bit simpler to pull in the Rust crates and add bindings. I've read that modifying and extending Deno is relatively easy to do in this way?
  - MuffinFlavored 3y ago
    Upfront simpler short term solution, 100%. Impressive too I might add. I love stuff like this. Turning "scripting language JavaScript/TypeScript" into cross-platform usable GUI that can do like <canvas> and 3D rendering if I understand correctly? So cool. I just "worry" (in an unsolicited advice fashion might I add) is there a better alternative to maintain this longterm

olestr 3y ago

The initial WebGPU Standard Library is such a promising step in this direction!

CyberDildonics 3y ago

Why wouldn't you just make a game that runs in a browser at that point?

flohofwoe 3y ago
Same reason why Electron exists, but in a much smaller bundle (since most of the actual browser engine wouldn't be included). This would also be an opportunity to build better cross-platform APIs than what's available in browsers (e.g. WebAudio, fullscreen, pointer lock, text input (input in general), networking, ... are all a royal PITA on the web - basically any web API that isn't WebGL or WebGPU is mostly broken or half-assed).
- pjmlp 3y ago
  That is what middleware is for. So lets call it a game engine using JavaScript, instead of the usual ones.
  - deleted 3y ago
    [deleted]
  - flohofwoe 3y ago
    If you want to call something simple like winit, GLFW or SDL a 'middleware' then yes. It definitely would not be a game engine in the popular sense like UE or Unity, those are way to bloated for most use cases such a minimal cross-platform wrapper would be good for. It would be something you could build a game engine on top though.
  - timschmidt 3y ago
    It's more a cross platform UI tooklkit built around web standards.
aseipp 3y ago
It would just be a nice way to turn your standalone WASM game into an .exe (or whatever equivalent) without needing too much extra stuff, like if you wanted to distribute a version on Steam, or offer multiple downloads like itch.io does. It's nothing groundbreaking. It would just be a nice and convenient, is all.

paxys 3y ago

And call it "Electron"?

flohofwoe 3y ago
It would be a much smaller and more efficient product than Electron because it wouldn't include a bundled web browser.
- paxys 3y ago
  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)?
  - flohofwoe 3y ago
    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.
    - paxys 3y ago
      Unless the Deno folks want to write that renderer from scratch, the only usable implementation right now is...part of Chromium.
      - notnullorvoid 3y ago
        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.
      - flohofwoe 3y ago
        The browser WebGPU implementations are available as native standalone libraries and are fairly easy (YMMV, especially for Dawn) to integrate into regular native applications: Chrome's implementation (C++): https://dawn.googlesource.com/dawn https://dawn.googlesource.com/dawn Firefox's implementation (Rust): https://github.com/gfx-rs/wgpu/ https://github.com/gfx-rs/wgpu/

kwhinnery 3y ago

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.

TachyonicBytes 3y ago
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 3y ago
  [deleted]