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

Wgpu-rs on the web

gfx-rs.github.io

Post reply on HN
Print view View original

31–40 of 63 posts

Re: Wgpu-rs on the web

#31

Post by hobofan »

exomancer wrote: post #23
chrismorgan wrote: post #12

Earlier quoted context omitted.

What do you mean by “browser toolkit”? If you mean “thing that people make web apps with” (like React or like you might imagine Qt being, though it’s not for the web platform), there is not a chance that this will happen by 2025. Zero. For starters, Rust: Rust is just too complex to be the most popular language when something like JavaScript exists which is faster and easier to get started with, and generally good en…

Rust already has [React-like web framework]( https://github.com/yewstack/yew ) with a macro for [declarative components]( https://github.com/yewstack/yew/blob/ce020d6eb8409b2063cc150... ) that compiles to wasm and, last I checked, [runs circles around JS frameworks]( https://github.com/DenisKolodin/todomvc-perf-comparison ). I agree that it won't reach the popularity levels of JS due to the learning curve, but on tec…

Yew (and comparable Rust frameworks) do however have a pretty slow compile time and with that a horrible debug-cycle. It's so bad that I in general opt for React-in-Yew for prototyping and only reimplement components with more complex state in Rust.

Re: Wgpu-rs on the web

#32

Post by kvark »

twic wrote: post #6

I could really do with a diagram to explain how all the parts fit together. gfx-rs, Vulkan, wgpu-rs, wgpu-native, browser WebGPU, gfx-hal, Vulkan Portability bindings. Here's what i think: 1. Vulkan is an API for doing graphics which is modern and standard 2. Direct3D (part of DirectX, the names are sometimes used interchangeably), Metal, and OpenGL are APIs for doing graphics which are modern or standard 3. Vulkan,…

I drew this on the whiteboard within Mozilla a few times, and I agree it would be nice to make it more accessible and hosted at gfx-rs repository or the blog.

There is a few scattered sub-diagrams on the topic, buried in the various slide decks I made:

https://github.com/kvark/slides/blob/master/BuildingWebGPUwi... https://github.com/kvark/slides/blob/master/IntroductionToWe... https://github.com/kvark/slides/blob/master/VkPI-WebGPU.pdf

Re: Wgpu-rs on the web

#33

Post by gameswithgo »

krcz wrote: post #14
echelon wrote: post #4

This is why Rust is going to eventually eat Javascript's lunch on the browser. I'm willing to longbets that by 2025 we see a Rust framework as the top browser toolkit. I'd even be willing to bet that there are popular frameworks in use by major websites that discard the DOM altogether for something simpler and faster. There's a reason why this has to happen, too. My sincere hope is that Mozilla and the Rust/Browser l…

I don't think that's going to happen and I hope that's not going to happen. DOM provides good abstraction of UI elements, which helps with accessibility, scrolling behaviour with the same feel as OS, standard text utils like selection, copy-paste. Using many incompatible libraries for that would lead to neo-Flash nightmare. What I believe is going to happen is splitting more complex web applications into frontend par…

>DOM provides good abstraction of UI elements

Does it, or do we just have a whole generation of people used to that abstraction, who can't imagine anything better?

Re: Wgpu-rs on the web

#34

Post by MaxBarraclough »

gameswithgo wrote: post #33
krcz wrote: post #14

Earlier quoted context omitted.

I don't think that's going to happen and I hope that's not going to happen. DOM provides good abstraction of UI elements, which helps with accessibility, scrolling behaviour with the same feel as OS, standard text utils like selection, copy-paste. Using many incompatible libraries for that would lead to neo-Flash nightmare. What I believe is going to happen is splitting more complex web applications into frontend par…

>DOM provides good abstraction of UI elements Does it, or do we just have a whole generation of people used to that abstraction, who can't imagine anything better?

It fundamentally doesn't do what UIs need it to. That's why most web UI frameworks use a 'VDOM'. When a framework finds a clever way to avoid doing this (Svelte), we all applaud the accomplishment. I think that gives us our answer.

Re: Wgpu-rs on the web

#35

Post by satvikpendem »

olah_1 wrote: post #29
satvikpendem wrote: post #21

Earlier quoted context omitted.

I can't see a Rust framework becoming one of the top web frameworks simply by virtue that Rust is more complex to learn and implement than Javascript. However, I can see your second point coming true, a fully native framework that eschews the DOM by compiling directly onto a canvas, just as a game compiled with WASM would. The prime example is Flutter Web, which has an experimental WASM renderer that displays onto a…

> a fully native framework that eschews the DOM by compiling directly onto a canvas Wouldn't that essentially be the death of accessibility on the web, though?

I see this concern a lot with Flutter or similar WASM -> canvas frameworks, and I think it's unfounded. Just because it's a canvas doesn't mean there's no accessibility. Indeed, even desktop apps are canvas like in that one cannot view the source and they can render using similar frameworks like Skia, or even Skia itself, yet they still have accessibility.

Flutter's developers have specifically included accessibility settings that devs should use, such as Semantics widgets, just like aria labels for the web. Flutter also constructs a separate semantic DOM like tree that screen readers hook into. So there are both built in things and things that devs can use to make their projects more accessible.

This video shows more about it: https://www.youtube.com/watch?v=bWbBgbmAdQs

https://flutter.dev/docs/development/accessibility-and-local...

https://api.flutter.dev/flutter/widgets/Semantics-class.html

Re: Wgpu-rs on the web

#36

Post by royjacobs »

OwnsE wrote: post #2

This is really cool. I've been excitedly watching how wgpu is developing. I don't have much graphics experience outside of one ogl but it looks like it's turning into something seriously neat.

Definitely. The last time I did any truly serious graphics programming was in the early noughts and the fact that I can now toy around with a really modern graphics stack in a reasonably straightforward, cross-platform yet still performant way is really wonderful.

I've been enjoying my time with wgpu-rs so far and I intend to keep doing so.

Re: Wgpu-rs on the web

#37

Post by flohofwoe »

pjmlp wrote: post #24
flohofwoe wrote: post #18

Earlier quoted context omitted.

TBH, I doubt it, writing "high level" Rust requires a too big "runtime portion" (in the same sense of "runtime" as the stdlib in C++, which also tends to bloat up executables), while "embedded style" minimal Rust without such a "runtime part" is so low-level you could just as well write C code (which is also "memory safe" in that environment because of WASM). And even in the best case, a WASM blob still has a hard ti…

Not really, because WASM doesn't do bounds checking on linear memory access, while Rust, C++ (with STL data types) do it.

WASM provides enough memory safety so that memory corruption errors in the WASM heap can't be used to escape the sandbox (assuming there's no exploitable bug in the sandbox itself of course). It doesn't protect from memory corruption inside the WASM heap of course.

Re: Wgpu-rs on the web

#38

Post by flohofwoe »

chrismorgan wrote: post #20
flohofwoe wrote: post #18

Earlier quoted context omitted.

TBH, I doubt it, writing "high level" Rust requires a too big "runtime portion" (in the same sense of "runtime" as the stdlib in C++, which also tends to bloat up executables), while "embedded style" minimal Rust without such a "runtime part" is so low-level you could just as well write C code (which is also "memory safe" in that environment because of WASM). And even in the best case, a WASM blob still has a hard ti…

Are you in the habit of using Rust + WASM? From how you’re wording this, I suspect not. Rust really doesn’t require a large runtime (until you do something that requires Unicode tables, then you pay a certain tax), and the difference between high-level and embedded styles is normally small to nothing—the whole concept of zero-cost abstractions is normally talking about performance, but correlates extremely strongly w…

I have admittedly not much experience with Rust+WASM (I dabbled in Rust though), but enough with C and C++ on top of WASM, and the situtation is really quite similar to C++ (IMHO of course).

Theoretically, C++ also has no "runtime overhead", but start using high-level stdlib features, and suddenly there is a non-negligible overhead. It's possible to cut that down, but that requires a lot of "insider knowledge" of the compiler toolchain and the specific stdlib implementation. In the end it's always about deciding what C++ features to not use to cut the size down, and at the end of that process is a language that's essentially C (no generic containers, no automatically managed memory etc).

And even when using C it is non-trivial to cut down the overhead from the C runtime library functions so that it becomes "competitive" with minified Javascript doing the same thing.

Don't get me wrong, Rust's toolchain integration with WASM is excellent. But I wouldn't call Rust compiled to WASM a contender for killing Javascript.

Re: Wgpu-rs on the web

#39

Post by raphlinus »

This is very cool stuff. I'm waiting a bit for it to become more mature, then I'd like to use it as the basis for druid, a native Rust UI toolkit. As noted in another comment, iced is already doing that.

One of the reasons I'm excited is that I believe I can get very high performance, and high quality 2D rendering using an evolution of the techniques explored in the piet-metal prototype. This work extensively uses GPU compute capabilities, which are not available in older versions of OpenGL or in WebGL.

Re: Wgpu-rs on the web

#40

Post by olah_1 »

satvikpendem wrote: post #35
olah_1 wrote: post #29

Earlier quoted context omitted.

> a fully native framework that eschews the DOM by compiling directly onto a canvas Wouldn't that essentially be the death of accessibility on the web, though?

I see this concern a lot with Flutter or similar WASM -> canvas frameworks, and I think it's unfounded. Just because it's a canvas doesn't mean there's no accessibility. Indeed, even desktop apps are canvas like in that one cannot view the source and they can render using similar frameworks like Skia, or even Skia itself, yet they still have accessibility. Flutter's developers have specifically included accessibility…

My comment was less about possibility and more about willingness.

But it looks like many are taking accessibility as a first-class concern, which is great to see.

Post reply on HN