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

21–30 of 63 posts

Re: Deno 1.39: The Return of WebGPU

#21

Post by data-ottawa »

throwawaymaths wrote: post #16
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…

> 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 like, then imagine numpy semantics and webGPU on top.

As a bonus: run on server or in browser locally would reduce cloud bills because you don't need a whole server to do an exploratory analysis.

Re: Deno 1.39: The Return of WebGPU

#22

Post by cnity »

jampekka wrote: post #18
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…

I'd love to use JS instead of Python for math/numerical stuff for many reasons, but without operator overloading it's just hell.

Interestingly I dislike Python for the exact same reason. Every time I look at a PR, I second guess every single operator and index. Does this attribute access carry a heavy penalty or side effects? Etc. I find it adds a large mental overhead to any given piece of code.

Re: Deno 1.39: The Return of WebGPU

#23

Post by paxys »

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

And call it "Electron"?

Re: Deno 1.39: The Return of WebGPU

#24

Post by lytedev »

MuffinFlavored wrote: post #15
andsoitis wrote: post #8

Earlier quoted context omitted.

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

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?

Re: Deno 1.39: The Return of WebGPU

#25

Post by pjmlp »

flohofwoe wrote: post #20
CyberDildonics wrote: post #17

Earlier quoted context omitted.

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

That is what middleware is for.

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

Re: Deno 1.39: The Return of WebGPU

#26

Post by jampekka »

cnity wrote: post #22
jampekka wrote: post #18

Earlier quoted context omitted.

I'd love to use JS instead of Python for math/numerical stuff for many reasons, but without operator overloading it's just hell.

Interestingly I dislike Python for the exact same reason. Every time I look at a PR, I second guess every single operator and index. Does this attribute access carry a heavy penalty or side effects? Etc. I find it adds a large mental overhead to any given piece of code.

Side effects on operator overload or attribute read are just really bad practice and is very rarely done. Do you second guess every identifier in C because it could be a preprocessor macro?

Yeah, stupid overloading like C++ IO is a mess, but I haven't encountered much such abuse in Python.

Re: Deno 1.39: The Return of WebGPU

#27

Post by willio58 »

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 don’t think even the creator of Python would agree with this..

Re: Deno 1.39: The Return of WebGPU

#28

Post by cnity »

jampekka wrote: post #26
cnity wrote: post #22

Earlier quoted context omitted.

Interestingly I dislike Python for the exact same reason. Every time I look at a PR, I second guess every single operator and index. Does this attribute access carry a heavy penalty or side effects? Etc. I find it adds a large mental overhead to any given piece of code.

Side effects on operator overload or attribute read are just really bad practice and is very rarely done. Do you second guess every identifier in C because it could be a preprocessor macro? Yeah, stupid overloading like C++ IO is a mess, but I haven't encountered much such abuse in Python.

Fair points. I do find the scope of C macros to be far narrower than overloading, but you are right.

Re: Deno 1.39: The Return of WebGPU

#29

Post by MuffinFlavored »

lytedev wrote: post #24
MuffinFlavored wrote: post #15

Earlier quoted context omitted.

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

Re: Deno 1.39: The Return of WebGPU

#30

Post by mehagar »

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…

See also Web Neural Network API: https://www.w3.org/TR/webnn/
Post reply on HN