Bjarnason: the labour arbitrage theory of dev tool popularity

A reader of BCN pointed out Baldur Bjarnason's essay from 2024, "React, Electron, and LLMs have a common purpose: the labour arbitrage theory of dev tool popularity"¹, which argues that the long-term popularity of any development tool is proportional to how much labor arbitrage it enables.

Basically, the more a tool lets management treat developers as interchangeable components, the more funding and adoption it gets, regardless of technical merit. The essay traveled, and it traveled because it explains things the merit-based story cannot. Nobody has ever mounted a convincing technical defense of Electron². It exists because paying one web team is cheaper than paying three platform teams, the output is worse by nearly every measure, and it wins anyway. Bjarnason has an answer for that, and the standard "best tool wins" story does not.

Bjarnason is not an unbiased writer. He has a destination in collective bargaining, and biases his arguments towards it; the piece closes on Ethan Marcotte's You Deserve a Tech Union, and everything upstream points in that direction. The frame he is working in is the deskilling tradition, the line of labor analysis that runs through Braverman: capital funds technology that separates conception from execution so that execution can be bought cheap. It is a real tradition with real explanatory wins: Taylorism is the canonical one.

But that frame carries requirements. Management intent has to be the motor of history, and developer choice has to be recast as either noise or false consciousness. When Bjarnason notes that developers "came up with our own excuses" for React, that is the frame talking. The workers who chose the thing must have been duped, because the frame requires the choosing to originate with capital.

Here is what the frame cannot see: adoption is a pair of scissors, and it takes both blades to cut, if you will. One blade is what management funds. The other is what developers reach for, and developers reach for joy, leverage, and escape. MongoDB, one of his examples, spread not because of a procurement strategy; it spread because developers who had spent a decade wrestling ORMs and filing change requests with DBAs discovered that they could just put the thing in the thing, and it was fun. Early React was genuinely ergonomic in 2014; the people who adopted it were not confused about their own experience. Bjarnason tells the entire history from the buy side. The build side was running the whole time, and most of the tools he names only make sense when both blades were cutting at once.

The JVM is where this gets interesting, because the JVM did not run the arbitrage experiment first. It tried to replicate an experiment that had already succeeded somewhere else, and it got exactly half the result.

The precedent was Visual Basic. By the mid-90s, VB had the thing every component pitch since has promised: an actual market. VBX controls, and later OCX, were sold retail. Grids, charts, serial port handlers, and calendar widgets were advertised in the back pages of magazines and shipped shrink-wrapped to armies of VB developers who were the canonical interchangeable workforce of the decade. Both of the blades - funding and joy - were cutting. The workforce was commodified, and it largely did not mind, because VB was pleasant enough to use and the components meant you shipped. Delphi ran the same play with the VCL and a smaller but real third-party economy behind it.

JavaBeans was Sun's explicit attempt to import that economy, and everyone - well, everyone at Sun - said so at the time. It never came³. Neither did the EJB⁴ marketplace, which added a standards committee to the arbitrage and produced the purest expression of the deskilled developer the industry has ever built: the bean-wirer, deployed by the hundred thousand into enterprise Java shops, XML descriptors as far as the eye could see⁵.

If Bjarnason's dial were the only one, this is where his theory should shine, because the arbitrage motive was explicit, funded, and standardized. What it produced instead was resentment and workarounds. The componentization the platform promised did eventually manifest, but it manifested invisibly. Oracle built a genuinely rich JSF component library in ADF Faces, and it sat behind commercial licensing where the JSF developers who needed it most never saw it⁶. The markets the JVM was promised became technology investments instead. The bazaar cannot form if the stalls cannot take money, and Java's structure never let them: committee standards instead of one vendor, plural app servers instead of one IDE, and an open-source culture that undercut anyone trying to sell a grid control.

There is a wrinkle in this history, and it is Microsoft's J++. Java was supposedly driven by community while Microsoft held .NET in a vise, but the "supposedly" earns its keep, because the community-driven platform had to survive rapacious actors inside it. J++ shipped delegates, J/Direct, and WFC, extensions that broke write-once-run-anywhere in precisely the embrace-and-extend direction everyone feared. Sun sued in 1997. The settlement killed J++, Microsoft took Anders Hejlsberg's team and the lessons, and shipped C#. The expulsion of the bad actor from the community platform created the platform held in a vise next door. And C# succeeded partly because Microsoft removed the choosing: default tooling, MSDN⁷, enterprise agreements, the Windows black hole. Partly. It also had genuine developer affection, because for a long stretch it was simply a nicer language than Java, and the man who built it had already built Turbo Pascal and Delphi. The joy blade was present; the fiat just meant it did not have to win on joy alone.

So the same component promise produced three outcomes under three different power structures, which is a problem for any one-dial theory. And the two governance bargains deserve to be laid side by side without a thumb on the scale. Java's contested pluralism meant nobody could yank the wheel: slow standards, survivable vendors, boring stability. Microsoft's vise meant coherence, fast decisions, and the standing risk that today's blessed path is tomorrow's deprecation. Ask anyone who rode VB6 into VB.NET, or WinForms into WPF into Silverlight into whatever this year's answer is. Today you do this, tomorrow it's that, sure hope it's good. For Java, the community process was real, and so were its vendor-shaped boundaries. Both were facts of working life.

Which brings us to the case Bjarnason's theory cannot digest at all.

Spring won from below. It was dragged into enterprise shops by the people writing the code, over the objections of architects who had already signed the WebSphere purchase orders. Management did not choose Spring to commodify anyone; management mostly found out about Spring after it was already doing the work of freeing Java developers from the burdens of J2EE deployment models. And what it delivered was the deskilling arrow running in reverse. The EJB world had separated conception from execution and handed developers the execution half (sort of); Spring handed conception back. You designed your own application again. That was freeing in 2004, and the freeing has held, which you can verify by watching the competition.

When Quarkus pitches itself as doing Spring better than Spring, the comparison is the acknowledgment. You do not measure yourself against a thing unless the thing is the standard, and Spring is still the standard for what liberation looks like on this platform. If long-term popularity were proportional to arbitrage enablement, none of this history is possible. Insurgency needs contested ground, and Java's mess, the same mess that strangled the component bazaar, is what made the ground contested enough for a Rod Johnson and Juergen Hoeller to take it.

That leaves the live case, which is the one Bjarnason is angriest about and analyzes least. He files LLMs under deskilling: another tool funded because it makes the worker replaceable. There is another reading. LLMs do not remove a skill so much as reveal which developers ever had the one that mattered. People can write code. LLMs can write code. The gap was always design, and being a coder hid the gap, because writing code gave people something productive-looking to do whether or not they could design their way out of a wet paper bag. Now the productive-looking activity is cheap, and the concealment is going with it. Both blades are in motion right now. Management is funding the component-spewing side, exactly as Bjarnason predicts, and developers are discovering leverage on the other side, exactly as he cannot account for. His prescription is a union card. Mine is not a prescription, because I do not know yet which blade cuts deeper, and neither does he.

What I know is that we have run this experiment before, three times, under three different flags, and the results never once matched the theories of the people funding it, or the theories of the people warning against it. Both camps keep seeing one blade and calling it the scissors⁸.