Hacker News Reader

Comment by flohofwoe | Hacker News Reader

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

View on HN

> 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

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-140065...

That's fantastic!

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.?

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?

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

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.

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

excellent idea!

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

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

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

That is what middleware is for.

So lets call it a game engine using JavaScript, instead of the usual ones.

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.

It's more a cross platform UI tooklkit built around web standards.

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.

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

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.

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

Firefox's implementation (Rust): https://github.com/gfx-rs/wgpu/

This whole thread is confusing. The blog in the OP, the comments section of which are you posting in right now, is literally about adding WebGPU support to a headless JavaScript interpreter Deno, that includes no HTML/CSS/DOM/Windowing engine. WebGPU is a standardized API built on platform specific graphics APIs, it is not a "renderer". The WebGPU support is based on wgpu, which isn't used in Chromium; it's actually the basis of Firefox's WebGPU implementation (and widely used by most Rust WebGPU projects, such as Bevy.) The person you are replying to simply wants native windowing APIs added to Deno as well, which has been done about 1,000,000 times in various other languages.

I'm very confused because every comment you have posted in this reply chain makes no sense in the context of the actual blog.

That’s still only part of what you need. You could pretend the native window client area was a <canvas> and give the code a GPUCanvasContext that renders to it, but you still need to do something about handling user input, what happens when the window size changes, &c. &c. And if you’re working with such minimal primitives, you won’t be able to make something that looks or feels even vaguely native.

The browser gives you a lot of valuable functionality.

This is all trivial (in fact much, much easier) to do with a handful of tiny custom APIs instead of what HTML5 provides (there are plenty of native window system glue library examples which have much saner APIs for window and input handling: GLFW, a subset of SDL, winit...).

Rendering an UI that even remotely looks "native" is harder with HTML+CSS than a handful of straightforward rendering primitives which can be implemented on top of WebGPU.

High quality text rendering is a bit non-trivial of course, but that's also only an issue if you want to do a native-looking UI (but mostly irrelevant for games).

the rest of the desktop software as we know as the browser (the UI, a config system, security features, history, profile, devtools...)

Reply on news.ycombinator.com