Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.39: The Return of WebGPU

deno.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Deno 1.39: The Return of WebGPU

#51

Post by throwawaymaths »

data-ottawa wrote: post #21
throwawaymaths wrote: post #16

Earlier quoted context omitted.

> We believe JavaScript, instead of Python, could act as an ideal language for expressing mathematical ideas if the proper infrastructure existed Outside of "everyone uses js", why do we believe this? What makes JS "ideal". I would think for machine learning one would want: - generally default to non-mutating, functional representation of ideas, with convenient escape hatches - treats the GPU as a concurrent (or bett…

JS lives where you visualize and explore data, so making it better at processing data would be a big win for workflows. When you use a jupyter notebook the kernel wastes a lot of resources on visualization and the support for interactive visualization isn't ideal (copy all your data to json, pass that to a JS library which has to do the work). Take a look at ObservableHQ for an idea of what an interface might look li…

There is a TON of sunlight between "better than python" and "ideal"

Re: Deno 1.39: The Return of WebGPU

#52

Post by notnullorvoid »

markdog12 wrote: post #6

> WebGPU is still considered unstable in Deno. To access it in Deno use the --unstable-webgpu flag

That's a formality. Once major browsers ship WebGPU without flags, the spec itself can actually be codified as a standard rather than draft. And I'm sure Deno will follow suit in the version after that event.

Based on current progress in browsers, I'd guess at least 2 will have it enabled without flags by end of Q1 2024. Chrome sort of already does, but for select platforms only.

I highly doubt the API will change from now till then.

Re: Deno 1.39: The Return of WebGPU

#53

Post by flohofwoe »

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.

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/

Re: Deno 1.39: The Return of WebGPU

#54

Post by mike_ivanov »

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

Did you forget about R?

Re: Deno 1.39: The Return of WebGPU

#55

Post by aseipp »

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.

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.

Re: Deno 1.39: The Return of WebGPU

#56

Post by aseipp »

CyberDildonics wrote: post #17
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 :)

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

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.

Re: Deno 1.39: The Return of WebGPU

#57

Post by RadiozRadioz »

kwhinnery wrote: post #32
throwawaymaths wrote: post #16

Earlier quoted context omitted.

> We believe JavaScript, instead of Python, could act as an ideal language for expressing mathematical ideas if the proper infrastructure existed Outside of "everyone uses js", why do we believe this? What makes JS "ideal". I would think for machine learning one would want: - generally default to non-mutating, functional representation of ideas, with convenient escape hatches - treats the GPU as a concurrent (or bett…

The usage of the word "ideal" in the 2021 post was probably not ideal :) The accessibility and diverse ecosystem of JavaScript, owing to its status as the lingua franca of software development, would probably be the basis for it being "ideal". I think it would be hard to make an objective claim that one programming language is strictly better than another as a programming language for mathematical ideas.

> lingua franca of software development

s/software/web/

Re: Deno 1.39: The Return of WebGPU

#58

Post by brundolf »

I'm still so bullish on Deno. They iterate quickly, but they also have a clear vision and direction. I've almost completely stopped using Node on personal projects; Deno is the new world I want for non-browser JavaScript.

Recent example: I've got a Deno server running a production service. I needed to make some bulk changes in the DB, and I was able to import DB types and utils directly from the main server project and quickly write a TypeScript script that used them to make the changes I needed, with the new script being the entrypoint, no config changes made, and the rest of the project being ignored. This would be practically impossible in a Node.js project that used any TypeScript, ES modules, etc.

Re: Deno 1.39: The Return of WebGPU

#59

Post by nsonha »

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

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

Re: Deno 1.39: The Return of WebGPU

#60

Post by timschmidt »

pjmlp wrote: post #25
flohofwoe wrote: post #20

Earlier quoted context omitted.

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 o…

That is what middleware is for. So lets call it a game engine using JavaScript, instead of the usual ones.

It's more a cross platform UI tooklkit built around web standards.
Post reply on HN