April 25, 2021
Tags: Development
It used to be that we’d see web versions of enterprise software. Gmail for example was one of the first web applications.
Something I’ve been thinking about more recently in consumer software, is how as we are now approaching 15 years of the Smartphone era, we’re seeing a lot of the same software being re-done over and over as the same concept but with a incrementally more enticing value proposition. Perhaps it’s a fintech Card, but it’s Green. Or it’s a Messaging App, but it’s Privacy Focused. It’s Roam, but it’s Open Source.
A lot of the time it feels like we’re running out of new ideas for the mobile platform, and we’re just rehashing old ones or slightly more narrow vertical markets. It’s Headspace, but for Kids.
as opposed to the traditional Make It Work, Make It Right, Make It Fast.
One of the most interesting patterns that I’ve noticed across both Consumer and Enterprise has been Speed. It’s Jira, but it’s Fast. It’s GMail, but it’s Fast, it’s Chrome but it’s fast.
We all want fast, responsive software. When software runs as fast as we can think, or interact with it, we can enter a state of pleasing flow, not only purely from a productivity sense of getting things done, but it feels nicer.
One of the best pieces of whiteboarding software I’ve used has been Excalidraw. Before Excalidraw there would be a lag between how fast I can think and how fast I can draw it. But with Excalidraw I can turn ideas into a visual markup and then share it really easily. Excalidraw’s key feature is speed.
Speed truly is a feature of software and the relationship between speed and technical choices is a fascinating one. Building for speed becomes a series of technical choices that aren’t yet quite figured out in the same way that User Interface design feels figured out.
I’m finding being able to dig deep into these technical choices about how to allow users to interact with software faster much more interesting than a slightly different design system (but perhaps that’s because I work full-time on a design system).
Take iOS vs Android as a musician. Android still in 2021 has such bad audio lag that musicians don’t use it, for well, anything. And this dates back to 2012 where 500ms of latency was measured. So the world’s most popular operating system isn’t used by any musician for creating music, crazy.
Is the responsiveness of the iOS keyboard the main reason I want to use it over Android, why is it so sluggish?
Speed as a feature means thinking critically about what programming language you write in. We consistently see great technology companies make serious bets into re-writing their products to allow for speed.
Mozilla who make Firefox actually invented Rust because they wanted to maintain the speed of C++ but not lose sleep at night over memory safety.
Why is multiplayer in Figma so fast? Is it because their CTO Evan, who definitely knows how to write fast software, chose Rust?
Was speed the reason why TypeScript became the default for type checking over Flow in the React communities, even though both Flow and React come from Facebook. I remember Flow, choking my IDE on every keystroke. I also remember a PhD in Category Theory and lover of Haskell told me Flow had a better Type System. Speed won and now I use TypeScript everyday.
Sometimes re-writes of software are attempted in a slower language and they become a disaster. This Twitter thread details Uber’s attempt to re-write the app in Swift from Objective-C.
The best tech companies consistently apply speed to their best products. That’s why Google Search has always been fast but doing anything in Gmail feels like it’s has a migraine.
And I haven’t even mentioned games, the makers of League of Legends basically had to fix the internet to make multiplayer fast.
VR has always constrained by speed, and John Carmack is still worked up about it not being fast enough.
When you value speed in your products, and you have resources, you’ll do anything to get improvements. Turns out Facebook Marketplace, which is a core product inside the Facebook mega-app uses React Native, and React Native requires a JS VM to start running, which is a bit slow on Android (obviously), and we can’t have Facebook running slow (that would mean less connecting everyone and ads clicked), so we better go write our own VM. Because Facebook wasn’t happy with with Google’s Chrome’s V8 Engine which was written for Google by a guy in Denmark or Safari’s JSC they hired a guy to write a JavaScript VM called Hermes. It provides about 50% faster time to interactive.
React Native is fast enough for Marketplace, but not fast enough for Messenger, so Messenger had to be re-written in C and SQLite. This architecture seems to be pretty trendy because Audacity 3.0 has also jumped on board the SQLite for everything, and Audacity is, guess what, a snappy C++ audio editing software. The SQLite-First architecture is now everywhere for write-heavy applications. It even is helping solve Notion’s problems.
Why do I think about Speed a lot? Well for the last few years, I’ve been working with React Native. And the React Native ecosystem often has this tradeoff which is really common: If you want it fast, you’re going to have to turn on “hard mode”.
For example, we’ve just mentioned Data Persistence. Let’s say you’re a banking app in React Native, and we want the user to be able to access their balance and a list of transactions from starting the app quickly.
Well you might use managed Expo, Redux with Redux Persist and store to AsyncStorage. Let’s turn on hard mode. Eject from Expo, and setup WatermelonDB, MMKV or LevelDB which use JSI meaning less bridge talk and faster app. Hard mode is now on, so welcome to long compile times, and having to use XCode and Android Studio. Want faster Animations? Now you’ve got to dive into Reanimated. Want faster Navigation? You should probably be doing it natively-ish. Managed Expo still doesn’t support Hermes.
But the Learn Once, Write Anywhere model of React and JavaScript is too strong. Even React’s view-is-a-function-of-state ‘model’ is now being copied by SwiftUI and Android Jetpack Compose.
Thanks for reading! If you have any comments, questions or feedback please get in contact. Have a nice Sunday.
I'm Henry Moulton, a software design and development freelancer living in London, UK.
My portfolio will be online soon.