Rust in the Browser is About More than Performance

I see folks talking about compiling Rust code to WebAssembly (so that it can be run in the browser) as if it were just about performance. They might further judge that most apps are fast enough in Javascript, so Rust in the browser is going to be a very niche thing.

Of course it’s true that Javascript is the de facto language of the browser, and that isn’t going to change anytime soon. However, looking around at existing applications and saying “meh, they’re fine in Javascript” really misses the point.

First, Rust is a far, far better language than Javascript. I don’t want to start a language war, but Javascript is well known to have more warts than a frog. If you don’t like type systems you won’t like Rust, but then you won’t have any use for my blog either. I recognize the value of good type systems, and Rust has a good one. It also does concurrency well, has a good macro system, and much more.

So another reason (besides performance) that you might want to use Rust rather than Javascript for certain tasks is that you want to write higher quality, more robust code.

By the way, even if Javascript performs well enough for your app, you might appreciate not having garbage collection pauses. Rust doesn’t have any.

Nor does Rust come with a runtime. One reason that Rust is especially attractive in the browser is that it is little more than the WebAssembly for your code, and a memory allocator, that is going to get downloaded. Sure, you could use C# or Go or whatever, but if the language is garbage-collected then the downloaded WebAssembly has to include a garbage collector — and whatever else is in that language’s runtime. Rust makes for a leaner download.

Also remember that by virtue of being more performant, Rust uses less battery to do the same task. If your app does something cpu-intensive, then even if Javascript is fast enough to be usable, phone/tablet users will still appreciate you not sucking the battery dry.

And RAM. Given a language that wants all objects on the heap and a header on every object, like Java, you end up using 40 bytes to hold the empty string. That’s not true in Rust. And depending on the type of garbage collector, extra memory may be needed for copying objects around.

And finally, don’t just think about *existing* applications — having a more performant language with no GC pauses opens up new possibilities for things that people would not previously have considered a browser app suitable.

It is still true that most applications present no compelling case for using WebAssembly — they just don’t do anything that significant outside of the GUI and talking to some server. For an app like that, with a team that is already facile with Javascript, and given the gymnastics of getting into and out of WebAssembly modules, why bother with WebAssembly?

So I agree that WebAssembly isn’t something that you will use with every app. However, when you do want a better tool than Javascript, enough to be worth dealing with WebAssembly, why would you choose anything but Rust? Much of the point was to improve performance and/or avoid GC pauses, right? Well, Java/C#/Go/etc. are going to take longer to load, perform worse, have GC pauses, use more RAM, use more battery, and be vulnerable to null pointer exceptions, data races, and other problems. If you are going to go to the trouble of using WebAssembly to improve a browser app, why not use the language that will do the best job of it?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: