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…
Wgpu-rs on the web
21–30 of 63 posts
Re: Wgpu-rs on the web
#22Earlier quoted context omitted.
Yes, so does WebGL and with the same efficiency. Partial hash inversion is an embarrassingly parallel problem: computing a hash from a random number is independent from the other random numbers you want to compute hashes for, also it is a computation bound problem and not memory bound. It means you can build a fairly efficient partial inverse finder by running many fragment shaders ("pixels") in parallel and only dra…
Can you share an example or tutorial?
There are also some tutorials available that demonstrate how to use the browser API directly:
- Raw WebGPU https://alain.xyz/blog/raw-webgpu
- Get started with GPU Compute on the Web https://developers.google.com/web/updates/2019/08/get-starte...
Re: Wgpu-rs on the web
#23This 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…
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…
I agree that it won't reach the popularity levels of JS due to the learning curve, but on technical side of things future is _now_.
Re: Wgpu-rs on the web
#24This 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…
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…
Re: Wgpu-rs on the web
#25This 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…
Flash like tooling is what will eat JavaScript's lunch.
Unity, Unreal, Blazor, Animate CC, Qt, ...
Re: Wgpu-rs on the web
#26This 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 really hope the performant web slays the app store. That's the dumbest trap we ever fell for. I'd love to visit a website and be playing native Minecraft in seconds. Sans Google Play or the App Store, with no bullshit monopoly tax. I don't, unless certain criteria are met. There is a consumer-friendly side of apps that is often overlooked in these types of conversations: generally, I get to decide when to update…
Re: Wgpu-rs on the web
#27Earlier 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…
https://krausest.github.io/js-framework-benchmark/current.ht...
wasm-bindgen seems to do well, though its code is rather imperative.
Re: Wgpu-rs on the web
#28Earlier quoted context omitted.
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 doesnt run circles around anything: https://krausest.github.io/js-framework-benchmark/current.ht... wasm-bindgen seems to do well, though its code is rather imperative.
Re: Wgpu-rs on the web
#29This 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 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…
Wouldn't that essentially be the death of accessibility on the web, though?
Re: Wgpu-rs on the web
#30Earlier 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?
It does. And would condemn us to live again usability nightmare of the flash epoch.
People are confusing two things here: There is no need of replacing the DOM. There is a need to replace (modernize) the API controling the DOM.