Rust vs. React Native—What?
Tradeoffs, or: Speed and stability are for everyone
I was recently discussing some thoughts I’ve had on building a top-notch application experience in a Slack team I belong to, and noted that I believe that a Rust core with native UIs is a massively winning strategy. A friend in the group responded that he thinks “React + JS is eating the world right now” and that “Rust as awesome for if you want to write a JS vm, or something like that… or a compiler… anything involving lots of speed and stability.” What follows is my response, lightly edited to remove details specific to that friend and to add a few further thoughts.
Here’s the thing: I don’t care what’s eating the world today, for three reasons:
- What was eating the world five years ago? Ten? Is it still eating the world today? I don’t feel obliged to follow those trends (not least because, not being a consultancy, following those trends doesn’t buy me anything for the things I want to do; your tradeoffs and mine look way different).
So much for my initial response. On reflection, I wanted to expand it a bit. So here’s another few hundred words!
Beyond this, I think there’s a bit of a false dichotomy here: the idea that “lots of speed and stability” aren’t values we should be seeking more aggressively for all our apps. Fully granted that not every app needs the same degree of each of those, and moreover that there are a lot of ways to get to those goals. Still: speed and stability are core user experience values. I don’t really care how you get at those goals, whether it’s with Rust, or Elixir or Clojure, or, yes, React with TypeScript or Flow. I do think that Rust is, for the moment at least, uniquely positioned to add real value in this space because it gives screaming performance but with so many niceties we’re used to when writing languages like Python or Ruby and so much of the power you get in languages like OCaml or F♯.3 But at the end of the day, I think all apps should focus much more on speed and stability than they do today. We have supercomputers in our pockets, and we’re often shipping apps that are slower and more finicky.
But I have this dream of a world where apps aren’t needlessly power-hungry or memory-intensive, where every swipe and or click or scroll results in buttery-smooth responses. We won’t get there by saying, “You know, Facebook is doing x so that’s good enough for me.”
Of course every developer, and any given product shop or consultancy, is going to have to make decisions about which stacks it invests in. If you’re primarily shipping web applications, investing in Elixir and React with React Native for your apps is a very sensible move. Most of your clients’ native apps may not need the degree of polished performance you might get from writing their iOS app in Swift and their Android app in Kotlin and the core in Rust (or even C++). That tradeoff is a tradeoff.
But let’s remember that there is real value there, and that some apps do deserve that investment. We should evaluate the tradeoffs at every turn, and our core considerations should enduringly include speed and stability. Don’t dismiss Rust (or Swift, or F♯) out of hand.
Equally importantly, we need to stop assuming that just because something is eating the world today means it’s also the future. Betting big on Flash in the mid-2000s wasn’t a bad move by a long shot. But its massive popularity then wasn’t a good predictor for its future. That goes double, frankly, for projects coming out of Facebook or Google or similar: big companies like that have the resources to drop everything and use a new language, or a new tool, as it suits them. If you don’t believe me, look at the actual open-source records of both of those companies! What’s hot today is far more relevant to a consultancy than to a product shop. And in both cases, choosing tech suitable for the job at hand is more important yet.
My friend gets that, for what it’s worth. He’s making the right moves for his business as the owner of a consultancy. I just want him—and lots of other people—to see where languages like Rust and Swift and F♯ might be worth considering. And speed and stability matter in a lot of places besides just compilers and VMs.
I’m aware that React-Native ultimately binds down to native widgets. It’s still not quite the same.↩
or, frankly, Ember or whatever else; React is great, but it is also overhyped.↩
Swift too, and honestly for a lot of things Swift is an easier experience for not that much less performance than Rust. But as of today you can’t ship core functionality in Swift for Android or Windows.↩