31
votes
React, Electron, and LLMs have a common purpose: the labour arbitrage theory of dev tool popularity
Link information
This data is scraped automatically and may be incorrect.
- Authors
- Baldur Bjarnason
- Published
- May 2 2024
- Word count
- 2138 words
The implication here seems to be that the tech stack developers work in is decided in a top down decree from management.
This might be the case in some companies but has never been my experience, every team I’ve worked on has had complete control over their choice of tech stack at least at the start of a project. One of the big selling points for the microservice craze was always pitched as different teams could work in different languages.
Maybe I’ve just been lucky and others can pitch in their experience but I’m not seeing this as the real mechanism behind certain tech/framework’s popularity.
Exactly. I think the author is also missing another key feature of the tools he mentions (at least, the ones on the list that I have experience with) - - they are all both easy to start using at a basic level, but can be used for highly complex applications. Being easy to start using is appealing for employers, but also for ordinary developers who want to jump in and churn out their personal project.
Create-react-app made setting up a first React project literally 5 minutes of effort. You can have a cross platform application building in Electron in under an hour. That's seriously a feature for a new developer trying to throw together an idea at a hackathon.
And once they start working on an employer's dime, a developer is much more likely to suggest a framework they've used before for that greenfield project.
I've definitely been in an environment where you don't always get to pick your tech stack, but Electron and React wouldn't have become nearly as entrenched as they are without being something developers want to use.
One note for future readers: create react app is no longer recommended. There are a variety of alternatives, but my recommendation is the vite react template.
I would recommend NextJS which will set up an app for you with one command.
Yeah, I know. I suppose my past tense wasn't as obvious as I thought.
I don’t think I’ve ever worked for a company (besides one I founded myself) where the engineers were allowed to unilaterally decide the tech stack.
Sure, it’s a group decision and there is internal politics. But at least in Silicon Valley, managers can be pretty technical themselves and they can be influenced by staff that advocates for technologies they like. In some cases, that’s actually part of your job, to write design docs making recommendations.
At non-tech companies, I imagine things are different. Each company has its own culture, and that’s more true at larger companies.
Maybe I've only ever worked at particularly tech-y tech companies, but while it's not like the business people have no say, rarely is the final decision not in the hands of engineers in my experience. Especially for things like frameworks.
This article weirdly dodges discussion of technical merits, ecosystem alignment, and network effects. It abstracts out a theory without engaging with the content.
Here's an example:
No mention of ES6 or what TypeScript did well, instead it tries to generalize patterns as if the technical details, developer incentives, user demographics beyond managers, and many other contextual factors don't matter.
The better starting points IMO are the technology adoption curve and the technology itself in the ecosystem's context. I wasn't looking to be negative and I'm politically sympathetic but this reads to me like thin punditry from motivated reasoning. I'm not denying that labor arbitrage happens but the story does not land for me - as others pointed out, technology adoption is not as simple as this suggests and the agents in play are not represented in a way that matches my work experience.
I definitely agree with the article's point that systems being reusable/componentizable explains a lot of their popularity, but I disagree that this is inherently bad for software developers, that React is bad in an obvious way that makes its popularity a mystery, or that software built with some bespoke expert setup is better for that than something similar built with React. I can understand this attitude with Electron and ChatGPT-produced code to a degree (there are inherent compromises in each; Electron loosely approximates native app paradigms) but putting React in that bucket doesn't make me think someone understands much about its strengths and weaknesses. React is well-fit to server and client HTML rendering in a way that little else before it was.
Separate from the argument about quality, I don't like the other argument the page seems to be pushing: "these tools make software development easier, which is bad because programmers will be paid less and have less job security". I don't like it partly because I don't think it's true (easier software development doesn't necessarily mean the same amount of software will be made with fewer people; if the market has appetite for more software then it can mean that much more software gets made with the same number of people), and partly because even if it's true, I think resisting making software development easier is a terrible route that will cause less software being made, less productivity across the population from that, and less people discovering the joy of making software. It's just gatekeeping. We'd still be programming in assembly without standardized operating systems/platforms and getting relatively little done today if people of the past thought that way.
The thing about increased productivity is that in the context of corporate environments (indies and FOSS are a different ball of wax) whether it’s “good” or not from the perspective of a developer depends on how the company chooses to make use of it.
If it’s used to deliver higher quality products or ensure employees are given less stressful, more manageable workloads for example that’s great, but more often it’s management and execs that reap its benefits while little changes for the developers doing the work, all while average software quality decreases.
I could certainly see an argument against increasing productivity when doing so yields little material benefit for developers and/or end users and in fact may even be making things worse for them.
I'm reminded of this article by Andrew Kelley https://andrewkelley.me/post/why-we-cant-have-nice-software.html - not exactly similar but definitely related.
It's similar in that both blame capitalism for the software world's problems. Such is common at The End Of History. Correct, too.
Well, they blame it in different ways. I think I personally buy Andrew Kelley's take a little more, he acknowledges technical merit better than the OP. There's probably a nugget of truth in both takes. They aren't mutually exclusive.
I assume it's easier for companies to hire a React developer to replace another React developer than it is to replace a Marko developer with another Marko developer. But if Marko were more popular than React, the situation would be reversed. Therefore, I disagree with the author's claim (at least in the case of React) that it is popular because it enables labor arbitrage. Instead, I argue that it enables labor arbitrage because of its popularity.
An interesting perspective on what determines which technologies survive and thrive and how they factor into the labor market for developers.
I’ve had similar thoughts myself for a few years by now, so it’s interesting to see those thoughts echoed by somebody else.