5 ms·

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 bott

by 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.
- ng12 6y ago
  That is exactly what I'm talking about. Everything you referenced is an architecture problem, not a JavaScript problem. You can write slow apps in JavaScript+React, you can write slow apps in Rust. Unless milliseconds matter (doubtful in browser-land) you won't get the kind of performance you want for free just by switching languages.
  - brundolf 6y ago
    Milliseconds absolutely matter. Every React render cycle (the entire relevant subtree from top to bottom because again, it's all synchronous) that takes more than 16 milliseconds presents to the user as a dropped frame. In fact that 16ms also has to include any DOM updates and the resulting browser reflow, which you have much less control over and are usually more expensive than your JS, so really the window is smaller than that. Also, many of the optimizations I listed above can make code less readable in small ways. Many of them are things you should not do eagerly (premature optimization is the root of all evil), and should only go back and do once you've identified a specific problem. If an across-the-board speed increase prevents them from ever becoming problems, that's a win. If you're thinking I'm a JS-hater, you're wrong. I think JS is a good language and I love using it where it's appropriate. But there are some usecases that benefit from a faster technology, and it's absolutely bonkers to try and argue that that technology shouldn't exist because "you can still make something slow with it if you really try".
    - K0nserv 6y ago
      16ms with 60fps targets, but there are higher frequency displays hitting the markets so that target might shift to 8ms or lower in the future.
    - rpedela 6y ago
      60 fps is rarely needed in web apps.
      - bschwindHN 6y ago
K0nserv 6y ago
Yew already seems to out perform most other frontend frameworks and view libraries[0]. More importantly it does this while still paying the serialising cost when moving from WASM to JS and back. This cost is set to go away when WASM to JS interop improves and will make Yew even faster. 0: https://github.com/DenisKolodin/todomvc-perf-comparison https://github.com/DenisKolodin/todomvc-perf-comparison

by ng12 6y ago

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.

ng12 6y ago
That is exactly what I'm talking about. Everything you referenced is an architecture problem, not a JavaScript problem. You can write slow apps in JavaScript+React, you can write slow apps in Rust. Unless milliseconds matter (doubtful in browser-land) you won't get the kind of performance you want for free just by switching languages.
- brundolf 6y ago
  Milliseconds absolutely matter. Every React render cycle (the entire relevant subtree from top to bottom because again, it's all synchronous) that takes more than 16 milliseconds presents to the user as a dropped frame. In fact that 16ms also has to include any DOM updates and the resulting browser reflow, which you have much less control over and are usually more expensive than your JS, so really the window is smaller than that. Also, many of the optimizations I listed above can make code less readable in small ways. Many of them are things you should not do eagerly (premature optimization is the root of all evil), and should only go back and do once you've identified a specific problem. If an across-the-board speed increase prevents them from ever becoming problems, that's a win. If you're thinking I'm a JS-hater, you're wrong. I think JS is a good language and I love using it where it's appropriate. But there are some usecases that benefit from a faster technology, and it's absolutely bonkers to try and argue that that technology shouldn't exist because "you can still make something slow with it if you really try".
  - K0nserv 6y ago
    16ms with 60fps targets, but there are higher frequency displays hitting the markets so that target might shift to 8ms or lower in the future.
  - rpedela 6y ago
    60 fps is rarely needed in web apps.
    - bschwindHN 6y ago

K0nserv 6y ago

Yew already seems to out perform most other frontend frameworks and view libraries[0]. More importantly it does this while still paying the serialising cost when moving from WASM to JS and back. This cost is set to go away when WASM to JS interop improves and will make Yew even faster. 0: https://github.com/DenisKolodin/todomvc-perf-comparison https://github.com/DenisKolodin/todomvc-perf-comparison