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

51–60 of 63 posts

Re: Wgpu-rs on the web

#51

Post by jfkebwjsbx »

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…

Not a chance. There are two main issues: technical and financial.

Technically, Rust is way too complex and therefore expensive to hire for. Same reason why other languages like C++ that compile to Wasm won't succeed either.

Financially, Google and Apple won't allow their digital stores lose market.

But even if those reasons weren’t a thing, Wasm is not as fast as native code and it would be a huge waste of bandwidth downloading every time game resources (measured in gigabytes these days!), even if you cache and allow huge offline storage.

In the end, you end up with a pseudo operating system, but just worse.

Re: Wgpu-rs on the web

#52

Post by pcwalton »

pjmlp wrote: post #25
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…

Not really, Rust ergonomics aren't yet there for writing GUI code. Flash like tooling is what will eat JavaScript's lunch. Unity, Unreal, Blazor, Animate CC, Qt, ...

Animate CC is Flash. There is no chance Flash is going to "eat JavaScript's lunch" in 2020.

Re: Wgpu-rs on the web

#53

Post by chrismorgan »

brabel wrote: post #46
chrismorgan wrote: post #20

Earlier quoted context omitted.

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…

> because WASM does have a tendency to make big code blobs easier to produce, especially if you’re using generics liberally. WASM was designed to be compiled to very small binaries. The big code blobs you see are produced by the Rust compiler and are not a characteristic of WASM... just check the output of the Rust compiler for a hello world project in WAT format and you'll see it consists almost entirely of the memo…

I’m not talking about the constant overheads, but how WASM grows as you scale your code base. My experience is that in practice it tends to be grow a little faster than equivalent JavaScript, say 1.2–2× the size depending on what you’re doing. But I should definitely have clarified that I was speaking specifically in the context of Rust—my generics remark certainly only makes sense in that context.

It’s not fundamentally terribly much larger, and can definitely be smaller (again, depending on what you’re doing), but using it as a compilation target makes it much easier to produce binaries larger than you anticipated. In JavaScript you distribute what you wrote, so you know if you loaded a lot more code. Well, in theory. Code bundlers and liberal importing of third-party libraries kinda put paid to that.

Re: Wgpu-rs on the web

#54

Post by saagarjha »

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…

Do people writing frontend apps really care that much about performance that they'd be willing to switch to Rust? Honest question.

Re: Wgpu-rs on the web

#55

Post by saagarjha »

smichel17 wrote: post #19
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 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…

Of course, native apps give a lot of control to your platform vendor or application distribution service.

Re: Wgpu-rs on the web

#56

Post by pjmlp »

pcwalton wrote: post #52
pjmlp wrote: post #25

Earlier quoted context omitted.

Not really, Rust ergonomics aren't yet there for writing GUI code. Flash like tooling is what will eat JavaScript's lunch. Unity, Unreal, Blazor, Animate CC, Qt, ...

Animate CC is Flash. There is no chance Flash is going to "eat JavaScript's lunch" in 2020.

It all depends in how committed you are into making browsers general purpose VMs via WebAssembly.

Re: Wgpu-rs on the web

#57

Post by ng12 »

saagarjha wrote: post #54
exomancer wrote: post #23

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

Do people writing frontend apps really care that much about performance that they'd be willing to switch to Rust? Honest question.

Not likely. The only thing that really matters to me is developer ergonomics. I've never seen a project struggle because it couldn't render a table with a 1,000 rows fast enough. I have seen many projects struggle because they hired a bunch of junior engineers who had difficulty writing clean, maintainable JavaScript.

Rust and WASM will definitely take on for doing things like WebGL. I can't imagine Rust becoming the de-facto solution for building UIs.

Re: Wgpu-rs on the web

#58

Post by pjmlp »

jfkebwjsbx wrote: post #51
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…

Not a chance. There are two main issues: technical and financial. Technically, Rust is way too complex and therefore expensive to hire for. Same reason why other languages like C++ that compile to Wasm won't succeed either. Financially, Google and Apple won't allow their digital stores lose market. But even if those reasons weren’t a thing, Wasm is not as fast as native code and it would be a huge waste of bandwidth…

Google is the big pusher for PWAs and WebAssembly, though.

Re: Wgpu-rs on the web

#59

Post by [deleted] »

satvikpendem wrote: post #21
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 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…

[deleted]

Re: Wgpu-rs on the web

#60

Post by postalrat »

pjmlp wrote: post #45
flohofwoe wrote: post #37

Earlier quoted context omitted.

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.

A fun exercise would be compiling the Heartbleed version of OpenSSL into WASM. Exploits can escape the sandbox, via functions exported from WASM that change their behaviour due to internal memory corruption, or callbacks that get called with unexpected parameters from the WASM code due to the internal memory corruption that changed the execution logic. For example, a security system that would grant higher credential…

I'm no expert but I believe in wasm memory and code are separate.
Post reply on HN