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

61–63 of 63 posts

Re: Deno 1.39: The Return of WebGPU

#61

Post by chrismorgan »

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.

That’s still only part of what you need. You could pretend the native window client area was a 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.

Re: Deno 1.39: The Return of WebGPU

#62

Post by flohofwoe »

chrismorgan wrote: post #61
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.

That’s still only part of what you need. You could pretend the native window client area was a 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 lo…

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

Re: Deno 1.39: The Return of WebGPU

#63

Post by v3ss0n »

mike_ivanov wrote: post #54
v3ss0n wrote: post #7

Earlier quoted context omitted.

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?

yet it doesn't even have a comparable market share ( even tho whole ecosystem is dedicated for datascience)
Post reply on HN