A few advantages:

- Rust compiles to WASM, not JS, so you can actually take advantage of its low-level nature in the browser for performance critical tasks within your app.

- The Rust code you're writing is still statically compiled, so you still get to take advantage of Rust's typechecking and IDE features.

- Some people just like writing Rust code more than Javascript. Part of the reason Javascript took off so quickly on the server was because there's a huge productivity boost from using one language everywhere. Similarly, if you love Rust but think that Javascript paradigms around prototypes, closures, or `this` are weird, you get to ignore that and take advantage of one of the best app distribution platforms in the world without learning a new language.

I pretty solidly hold to the position that increasing language diversity on the web is a good thing. Particularly with Rust, since they've put in the work to have proper, accessible support that's still separating app logic from DOM layout and CSS styling. I'm really happy with how their community has approached building out Rust as a first-class language on the web rather than just as native language that happens to have a web compile target.

> 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 front-end work is only performance-critical for DOM rendering (the 0.1% is stuff like video encoding & decoding) and WASM can't help with that.

> 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.

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.

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

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.

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.

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.

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".

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.

60 fps is rarely needed in web apps.

<60fps results in a noticeably worse user experience, especially when scrolling. "Need" is relative, but I was really just trying to make the point that milliseconds matter: even if we cut that in half to 30fps, that's still 32ms maximum per render cycle.

What scenario can you think of where you have state updates while the user is scrolling?

Here are a couple cases we ran into:

1) We had a querying interface that would allow the user to construct a query and then it would return potentially thousands of results, asynchronously, over a websocket. We only displayed the first 300 on screen at a time, but sometimes the updates would come in so rapidly during that first 300 that one render wouldn't be finished before more results were available and the next render triggered. Things would get really backed-up and the UI would hang for multiple seconds at a time. So we decided to throttle the rendering - get the results as fast as possible, but only render once every 500ms or something. But during this time the user still might want to scroll around and look at other parts of the page, so we didn't want it to pause for 100ms every 500ms. It was a constant battle to keep things responsive while all this was going on.

2) We had another screen that would load another massive list (thousands and thousands) of entities as soon as you visited. These also came in gradually over time to spare the user from waiting for the last result before they could see the first. Similar deal: we throttled, but we needed to keep things responsive even during that throttling because the user would be scrolling up and down the results as they were coming in.

Both of these sound like side-effects of trying to render massive amounts of UI artifacts that the user doesn't actually need or want to see. Whether you use JS+React or Rust+Yew you're going to get yourself into trouble with firehose-style data handling.

Our users specifically demanded to see this much data. They actually complained that we couldn't show more. Once again you're making bold claims about a subset of use-cases that you clearly have no context for commentating on.

I never claimed that switching languages would have magically solved all our problems, but in our case it could've been a significant boon to performance which could've been one factor of many that contributed to a solution, and I just can't figure out why you have such a problem with that idea.

I'm an old 3d graphics programmer. One of performance rules is only render what will be displayed in that frame because rendering is expensive. That is why there are various culling algorithms, some are quite complicated. The reward for implementing all these advanced culling algorithms is very fast frame renders that give you more time to draw special effects, draw more characters, etc in a single frame.

I am a data engineer now and sometimes have to build web interfaces for scrolling large data tables. Just like in the 3d graphics world, the trick to responsiveness is culling. Only download and display the amount of data that the user will see at a given time, plus some overhead so the user never sees gaps when scrolling.

While Rust may have solved the problem in #1, it is unlikely to solve the problem in #2 because you are also fighting the network where Rust is useless. Need culling.

Unfortunately because web content is automatically positioned/sized in a way that's (mostly) opaque to JavaScript code, this is a pretty hair problem (compared to graphics where you have all the numbers on-hand). So most of the time you'd either have to a) try and replicate the math the layout engine ends up doing which makes things more brittle, or b) directly measure the computed dimensions/positions/visibility/scroll position of different elements, which tends to be a pretty large performance liability and in many cases would eliminate any gains you might receive.

There are some edge cases where these techniques can work - like if you have a really simple layout, and you can give a fixed-height to every item (table row or otherwise), and you assume the user is never going to resize their browser window - but it isn't nearly as obvious of a win as it is for 3D rendering and we just never decided it was worthwhile to try going down that rabbit-hole.

> Unfortunately because web content is automatically positioned/sized in a way that's (mostly) opaque to JavaScript code, this is a pretty hair problem (compared to graphics where you have all the numbers on-hand).

Exactly the same for 3d graphics. The auto-positioning is different but conceptual similar.

Yes B is my recommended approach. Since we are talking about performance, we should really be putting limits on what fast and slow mean. That is because it doesn't really matter if something is fast or slow, what matters is the performance difference between different approaches.

For B on average, performance will in the microsecond range, DOM rendering will be in the millisecond range, and the network is >100ms to seconds range. It is unlikely that B will be equal or slower to brute force rendering everything. Those X microseconds spent figuring out the culling window saves Y milliseconds rendering and saves Z milliseconds to seconds querying the network.

It's not that I have a problem with the idea, it's that I've spent most of the last decade building data visualization apps on the web and have never truly hit a wall with respect to JavaScript's performance characteristics. I think of it like this: no user is visually processing data faster than React can render it. If you render 300 elements and then want to render more updates before those first 300 had finished, did you need to render those first 300 at all? A human can't visually process hundreds of elements that quickly. The problem is that you're attempting to render a bunch of data that's not actually what your user is trying to see, not that React can't render it fast enough.

Most "performance" problems on the web are solved by simple techniques like virtualization, pagination, pushing expensive calculations to the server, avoiding round-trip requests, or basic UI/UX improvements. The only time I would care about JavaScript's actual runtime performance if I were doing something crazy like 3d rendering in the browser and that's a completely different set of problems than React or Yew are set up to handle.

The constraints on data visualization are not the same as the constraints on an IDE, which is closer to what we were building. Also, our users could definitely "process" the data faster than it could be rendered, because what they were doing most of the time was skimming through it for points of interest. They were not sitting and deeply considering each data point one at a time; they could glance at a page and know in a moment whether what they were looking for was there, or whether they needed to scroll further, or whether they needed to tweak the query and re-run it or click a link to a different screen. It was muscle-memory for them, and the tiniest hitch was frustrating to the user experience.

60 fps should be the bare minimum given the kind of hardware we run these days.

No it should based on the need of the use case, as always. Very few websites, even highly dynamic ones that require React, need to be rendered at 60 fps.

> 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.

Avoiding 1 is actually one of the selling points for Svelte.

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

> 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.

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.

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.

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.

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.

I would rather have a fast way to debug than speed execution when dealing with single page apps. Execution speed isn't a concern, it's payload size and TTR speed that we care about when working with a SPA, and this wasm code is over 200,000 lines.

What a nightmare to debug!

Exactly! Practically speaking, rust for SPAs is useless, at least for now.

> Speed?

As surprising as it might sound -- not really. There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization.

It's more of a familiarity/existing tooling thing. Same as Blazor in C# writing web apps in that. If your entire team only knows C# and you have all your existing tooling there then it could seem an appealing option.

But there's also the argument for more stringent safety with Rust compared to IE, Typescript.

> There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization

My understanding is that this is going to get a lot better in the future though -- last I checked the plan was for WASM to eventually have direct bindings to DOM APIs, at which point you won't need to interact with JS at all.

That's true, if the Interface Types proposal gets accepted that overhead should be significantly less. At that point it'll get really interesting what the potential performance looks like for DOM-interaction heavy apps.

https://github.com/WebAssembly/interface-types/blob/master/p...

I wouldn't think it's far behind. The Multi-Value proposal, which had huge ramifications, was recently accepted in April so WASM is clipping along at a fair pace still.

https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/

Firefox Nightly and Chrome Canary both recently landed multi-value and reference types: https://webassembly.org/roadmap/

This is true if you are writing code that has a lot of UI interaction, but one sweet spot for WASM I've found is if you just want to do a bunch of computation on the client and surface it. For example, I wrote a SPA for generating crossword puzzles[1]. Maybe I'm wrong, but I don't think I would have been able to get the same performance in JS even with modern optimization.

1. https://crossword.paulbutler.org/

That's really cool, thanks for sharing it. It found a 16x16 with a lot of complexity incredibly fast!

Nice crossword generator!

Now I'm somewhat tempted to write a js implementation to actually compare.

I was very surprised to find this. I have done some WASM experiments and found that JS is very often incredibly well optimised, often running faster than WASM. Do not underestimate the years of JIT optimisations that went into V8 and other JS engines.

V8 is an incredible piece of machinery, and I really wish other JIT's and languages got access to half the engineering and monetary effort that went into it.

> often running faster than WASM

This seems pretty counter to everything I've read about WASM - V8 is some black magic, but WASM should run far faster. What language was the WASM blob compiled from? Mozilla has also demonstrated that they can send the DOM to a WASM blob, have it perform the necessary transformations and return it, faster than JS could perform the same transformations itself.

I was actually playing with the raw WASM, but I checked what Rust compiled to and ran it as well (it wasn't any better). It was a simple fibonacci benchmark so perhaps not representative but it still left me very disappointed.

Same, do NOT underestimate V8 black magick + optimizations.

I've done a fair bit of benchmarking/performance experimentation with compiling Rust/Go/Zig etc to WASM (including with SIMD or parallelization enabled).

It'll be really interesting watching the progress of V8 + WASM SIMD proposal, it's been enabled behind a flag in V8 for some time now.

https://v8.dev/features/simd

Although Rust is most known for bringing safety to low-level development, it also happens to be a nice, modern programming language with things like match statements and sum types. I find myself using it frequently for things I used to do in Python, with greater productivity once a program reaches the point that I can't keep it all in my head.

Well, that's definitely a sweet-spot, but as a by-product of that, Rust is still a well-thought through language with a strong and logical type system, some very useful features for expressing domain models, etc. and a model of memory management which maps very well to WASM. So if you already know Rust, this is a short and logical step. If you don't already know Rust, I wouldn't learn it just to write web apps in - but if you do, you now have all the advantages of "same language client/server side" as well as the advantages of safety, good libraries in certain spaces, etc.

> I wouldn't learn it just to write web apps in

I'm going to be looking into the other way around: writing a web app in it to learn it. Seems like a great use case that would make it easier for me to learn, as someone who has experience with web apps and not so much with desktop software.

It's the reverse of what happened with JavaScript. In other words, JavaScript started on the front-end and then spread to the back-end because it was advantageous to have one language for both. One of those advantages is that folks who were experts in JavaScript were suddenly able to use their language of choice for back-end work too.

Rust started on the back-end but is fairly likely to spread to the front-end in the future for the same reason. One of the advantages will again be that folks who are experts in Rust will be able to use their language of choice for front-end work too.

Beyond this, I would argue that Rust's type system is a significant draw for many folks as well. I dare say it has a lot more potential than Elm, a Haskell-like language designed just for web development.

I don't think Rust is just for low-level development anymore, for example at Commure we have been using it very successfully for "enterprise app".

So if you're already using Rust for the app backend, I think the interest is more about using the same language in the back and in the front. Since nowadays one usually wants a typed Javascript (e.g. Typescript) anyway, it is far shorter of a leap to Rust.

I haven't seen it mentioned, but memory usage might also be better, and I have a good real-world example to show why it still matters in 2020: we use Jira to manage our software projects and our team's project manager uses a newish MacBook Air with 8GB of RAM. Jira is written in React and a single page for a ticket can easily eat 150+ MB of memory (it's even more for Jira boards). Our PM regularly complains about the slowness of his machine and I think Jira is a big contributing factor. I don't think much of the memory is used for presentation (so it might not be React's fault), but rather for business logic processing a large amount of data. And IIRC calling a simple `filter()` on a JS array creates a new array for the operation while Rust uses iterators.

I regularly slow to a crawl on a 32gb Mac Book Pro requiring a reboot because it starts swapping thanks to Chrome tabs, electron apps/VSCode, and webpack/cargo/whatever to the point that running cat on a file takes 5-10 seconds. All it takes is a little memory exhaustion for the kernel to pick a process for swap (iterm and its children? why, thank you kernel!) and drive it into the ground. With Chrome it might swap just a single tab process or it might swap the rendering process

I don't know why it seems React apps are some of the worst offenders, but I think it has to do with hooks injecting context components everywhere (at least that's what it looked like last time I popped open React dev tools). I'm guessing that out of tree state tracking is particularly memory intensive.

Possibility of sharing code between backend and frontend.

Yes. Isomorphic code was always about having to prove the correctness of a smaller body of code.

Web assembly will see a whole new round of people trying to do monoglot programming. Which I welcome, because I like JavaScript well enough but I don’t like writing it all day, every day, for years at a time.

Type safety is the key selling point here. Rock solid behavior for asynchronous and concurrent behavior is another one. Both could be considered weaknesses for Javascript.

I agree it's a bit too far out for a lot of javascript/typescript developers. But then the Rust community has a lot of former full stack refugees joining it. My observation is that "full stack development" using javascript is a phase developers go through before upgrading to some other language. You see similar patterns in the Go community. Both communities have lots of people who used to do lots of web and node.js development.

My money is more on languages like Kotlin, C#, and Swift crossing over to the browser. Both already have wasm compilers that are still need a lot of work. This work only kicked off for Kotlin fairly recently. Kotlin also has a decent javascript transpiler that you can use right now. Both Swift and Kotlin are very popular for mobile UI development. C# has been used extensieley for Desktop and web server development. Obviously these languages come with lots of features that make them very suitable and popular for exactly the kind of stuff people use Javascript (and Typescript) for.

I haven't done much with Swift and C# but Kotlin is great for this. Most of my experience with that language is server side but I have done a few things with kotlin-js as well as some Android stuff. As of a few months ago, the kotlin-js tooling is getting to the point where it's a very solid choice. It builds, it eliminated dead code, it runs webpack for you, etc. The upcoming version (1.4.0) is currently available as a release candidate and includes something called Dukat. Dukat generates kotlin type headers from typescript type headers for npm dependencies. So that means you can integrate a lot of existing npms if you have to. Also the build tools integrate with webpack and you can target both the node.js ecosystem and the browser ecosystem.

Most of the bottlnecks for adopting either transpilers or wasm compilers in this space is the relative immaturity (or lack off) mature alternatives to popular javascript frameworks. You can do react apps in a bunch of languages now but it just feels wrong to do it. The pattern you see in other language communities is that they pretty much start rolling their own alternative frameworks. In any case, the amount of third party code making it to a browser is typically not that much for most webapps. For all it's popularity, the react run-time code is not that large. A few hundred KB is considered a lot.

Predictability?

As far as I know, Rust's WASM performance is much more uniform than JS'.

A fast webapp is a selling point on it's own.

Of course, maybe just because it uses WASM it doesn't automatically have to be faster - but this looks promising.