6 ms·

> you can actually take advantage of its low-level nature in the browser for performance critical tasks within your app. Yeah, but the problem is that 99.9% of

• cogman10 6y ago
  > the 0.1% is stuff like video encoding & decoding In which case, rust still isn't a good fit for a front end library (Unless you are patching in support for a new codec into old browser). Frankly, the browser will have a faster version of the codec that can also take advantage of other hardware that you wouldn't want to expose to WASM.
• brundolf 6y ago
  > 99.9% of front-end work is only performance-critical for DOM rendering There are two meanings of "DOM rendering" in the context of UI-as-a-function-of-state libraries: 1) generating the virtual DOM from data, and 2) modifying the real DOM to match it. Arguably there's even a 3) browser reflow as a result of those DOM changes. You're right that 2 and 3 can't really be helped by WASM. But 1 can, and while it's not usually the bottleneck, it certainly can be. At my last company it was not terribly uncommon that fixing UI jank came down to eliminating unnecessary React render function calls because the sum total of them all - running the actual JavaScript logic - was taking too long. Assuming yew computes the virtual DOM in WASM (I don't see how it could be otherwise), the performance increase could definitely be beneficial for certain highly-complex apps.
  • ng12 6y ago
    Switching from JS to Rust will not give you a noticeable improvement in runtime speed, especially since V8 is absurdly well-tuned. If your JS logic was the bottleneck it's a good sign that the code was poorly architected and Rust cannot help you with that.
    • CryZe 6y ago
      Rust compiled to WASM is still vastly faster than JS (often even by about 10 times or more). But yeah you probably should be fixing your JS at that point if it matters that much.
    • brundolf 6y ago
      Unless your claim is that WASM isn't actually faster than JavaScript - which I haven't personally verified but seems like a pretty shaky argument - you're not really making any sense. When you've got 10,000+ component instances on a page, tiny bits of render logic add up. You can identify whether actual JS logic is your bottleneck (and to an extent, which JS is your bottleneck) through profiling. The most common fix is to avoid calling render functions at all where possible. These are cases where the output of the render function will be identical to the previous output - which means React won't make any DOM changes - but where the render function will itself get called anyway. You can prevent this through better dirty-checks on props and state (shouldComponentUpdate, in React's case). Though if you're not careful, even those comparisons can become a limiting factor (not often, but sometimes). Immutable data structures like those in Immutable.js and pub/sub component updates like what MobX does can help ensure comparisons don't get expensive. Another trick is to do expensive operations like mapping over a large array ahead of time, instead of doing it on every render. Maybe you even need to perform your array transformation in-place with a for loop, to avoid allocating-and-copying. This is especially true if you do multiple array operations in a row like filtering, slicing, reducing. Memoization of data that gets re-used across renders is a generally helpful pattern. Another huge factor in this case is concurrency: JavaScript runs on the same browser thread as reflow and all the rest, meaning that all of this JS logic blocks even non-JS interactions like scrolling and manifests very directly as UI jank. React rendering cannot happen in a worker thread because React requires direct access to the DOM API (element instances, etc), and worker threads cannot share memory directly with the main thread; it's message-passing only (the upcoming React Concurrency project will help alleviate this problem, but doesn't directly solve it). Rust, on the other hand, can share memory between threads, meaning that in theory (assuming Yew takes advantage of this) renders can happen in parallel. Even if they don't, WASM already lives in a separate thread from the main DOM, which does mean it will probably incur some constant message-passing overhead, but it should never block reflow. And that would go a very long way towards preventing user-facing jank. The average web app doesn't run into these problems, and usually they can be optimized around, but when you do run up against these limits any across-the-board speed improvement that raises the performance ceiling can reduce the amount of micro-optimization that's necessary, reducing the cost in developer time and likely improving readability.
  • rimliu 6y ago
    Avoiding 1 is actually one of the selling points for Svelte.
    • brundolf 6y ago
      According to my (possibly flawed) understanding it doesn't eliminate it exactly, but does cut down on it a lot by doing as much work at compile-time as possible
  • pjmlp 6y ago
    > the 0.1% is stuff like video encoding & decoding I would use WebGL and WebGPU for that, and AssemblyScript for WebAssembly, so nothing that Rust would make a major difference.
• droobles 6y ago
  You should check out Glimmer and what they're doing with their byte-code components – I think the Glimmer vm in Rust would boost DOM rendering performance vs virtual dom implementations.
• K0nserv 6y ago
  Have you used the modern web? We might not be building apps with "performance criticial tasks", but the modern web would benefit immensely from anything that improves baseline performance.
  • muglug 6y ago
    Yes, I use it all the time, but most websites are really simple things – for every figma.com there are a thousand e-commerce sites that do very mundane things.
• tanilama 6y ago
  Precisely Talking about perf without understanding the problem domain is a common mistake Rust folks tend to make. I don't think there is enough push for people to switch to a new language just for performance sake in front-end land. JS ain't that bad, and performance is certainly achievable by careful and incremental optimization.