https://www.rfleury.com/p/programmers-are-users-bad-performance
I thought this was a really well written piece describing some of the unforeseen consequences of optimizing toward DX. If you haven’t read it, read it.
I’m someone who, to his dismay, spends a great deal of time building software for businesses which have accepted the exact tradeoff Ryan is describing in his post. While I’m proficient in Rust and other lower level languages, almost all of my lifetime development income comes from “full stack Typescript”. Node, React, React Native, and so on. Languages and frameworks responsible for the enshittification of the digital landscape.
For those of you who don’t know, React Native is a JS-based mobile framework which essentially sits atop a native mobile app. When the mobile app runs, it spins up a React app inside of the phone’s JS runtime. However instead of updating a DOM, it sends VDOM updates across a bridge to the native layer, which updates the UI.
This is a gross oversimplification, but React Native is a perfect candidate for understanding the tradeoff between performance and DX. The tradeoff here can’t be understated. From the business perspective, React Native enables you to write a mobile app as a React app instead of breaking out multiple codebases in Swift and Kotlin. You can quickly adopt webdevs to your mobile project, and have them build business-effective, moderately well performing mobile apps.
And on the other side, React Native runs into some real, magnitudinal performance issues. RN binaries are usually many times larger. And your mobile app is now running inside of a Javascript runtime instead of the near native Swift/Obj-C runtimes. There are extra steps in the build process; every significant library has to be implemented in both native layers - essentially a sort of symlink between node_modules, cocoapods, and gradle. (Just in case you thought webapp dependencies were bad.) Certain features, such as lists and animations, can be much slower. And in general, the UI less performant.
However it must be said that mobile development is hard and expensive. Developing even a simple mobile app without any best practices will cost a hundred thousand dollars. And when you account for live pipelines for design, infrastructure, builds, tooling, QA, and deployments, it’s usually in the millions. A single mid-level React Native developer’s salary runs over $100k, and good luck finding one at that price who can architect everything with best practices, and manage the design, QA, and product management aspects.
Usually apps cost much, much more. I’ve worked for two different Fortune 50 healthcare companies, both with mobile development teams in the tens of millions of dollars of salaries per year. And if you were to look at those mobile apps from a UX and design standpoint, you would be hard pressed to see where that money is spent. Tens of millions of dollars every year for what is essentially a CRUD app - a mobile view of a website.
This is the reality of non-tech companies building products. They don’t have the engineering culture of somewhere like Google or Meta.
The situation I described - an enterprise company spending $15m a year in perpetuity for a CRUD app - is already the best case scenario for DX-based cost accounting. The apps are in React Native, usually architected to make everything as reusable and idiomatic as possible.
What then, would it look like if instead of hiring highly commoditized React developers, they had to hire separate specialist teams to implement - and ensure parity - with iOS and Android? Would the cost center’s budget need to double? Would there be any guarentees of actual performance benefits? Would the company’s bottom line improve? Would DX actually improve for those respective teams?
The best-case answer for all of those questions is: maybe. Probably not.
What good programmers often fail to account for is bad programmers. While it’s true that in sophisticated environments, over-abstracted tooling leads to computational inefficiencies which sort of taints the water supply. But to counter that over-abstraction, not only do you usually need larger budgets, you also need more talented developers. In other words: these hyper-DX-accessible tools like React Native enable an entire class of business applications which might otherwise not exist at all.
The reality of business development is rather grim. At most enterprises, you’re lucky if you can find half a dozen developers who have ever touched a systems programming language. Usually there are only a couple of engineers who even have the ability to wrangle a monorepo or manage a mobile build pipeline.
In my experience at not-FAANG, I’d say a solid 50% of the developers I’ve met have no business being developers. I don’t mean that as a sort of personal attack against them, market forces and all, but rather that if companies refocused on quality and intentionality, they could stop modeling their DX for the lowest common denominator. But it is really hard to make the business case for this when hundreds of millions of dollars are on the line.
Regardless of everything I said in defense of slop code, I still strongly agree that system performance should be more important. It should be a cultural issue for developers. It’s sad that we’ve offset the last two decades of Moore’s Law simply to deliver better DX. And as Ryan mentioned, even that isn’t a success story. I often point out to my gamedev friends that World of Warcraft’s netcode from 2010 is better than basically anything since.
Since 95% of software projects don’t last a decade, it seems like we have plenty of wiggle room to be more deliberate in what we’re building anyway. Many of these projects and their wasted resources are the result of over-accessibility of development.
It certainly feels like the internet is overcrowded and bloated with low-quality content, whether that is from content creators within platforms, or the platforms and products themselves. If not us, then who will stop the enshittification?