[idea:26w25-liminal]2026-06-21

LIMINAL

Most of my week was sunk into developing a new feature for a platform for a forthcoming investigation about migrant pushbacks on the Mediterranean. I made a false start at rewriting the whole thing in bonsai a couple of weeks ago, but deadlines have demanded that I fall back into React.

The technical details of the platform are, alas, no longer very interesting to me. There was a time when I was excited to learn about the browser, WebAssembly, and other infrastructures of frontend development, but several years at grad school have shifted my perspective pretty substantially. One of the most difficult things about frontend engineering, I think, is that it almost always means you are interfacing with designers and/or clients who don’t have substantial software knowledge directly. This is essential and necessary work in so many domains; but it’s densely difficult, and requires good communication across many channels, which means meetings, changes, backtracking.

Frontend engineering is sometimes colloquially treated as less technically requiring than backend engineering or systems programming. To me this stems from a misunderstanding about what is hard about building software, about what it means to be ‘technical’. It’s easy, relatively speaking, to identify a problem in a domain with people who all speak your language, who all generally speaking approach the problem in the same way. It’s much harder to work effectively in the squishy channels of human-to-human communication, parsing and formalizing desires as features, and doing so with a bedside manner that allows everyone to feel like they’re getting what they want. Frontend engineering is almost definitionally on the frontlines of this kind of work, the most difficult aspect of engineering, because the browser is one of the most common places where software systems get exposed to users with vastly different understandings of computation.

Grad school has been a haven for me in which I have been allowed to work without guardrails towards aims largely of my own choosing. 1 I have chosen to work almost exclusively in Rust, a programming language at the other end of the spectrum: by design/definition, Rustaceans (those who work in Rust) get to work with colleagues who have a shared understanding of computation and how to handle it. An absolutely banal yet absolutely accurate observation: there is a cooperative joy to sharing a community with others who share your basic understanding of what work is! If given the choice, I can’t help but think that I would rather not do the hard, labyrinthine, and mercurial labor of translating between computational dialects, as good frontend engineers must do. Let me work in a terminal and modal text editor on a NixOS machine, so that the only people I have to explain my work to are those who already understand the vocabulary in the first half of this sentence.

Despite the above disavowal of frontend engineering, I have enjoyed learning the level of abstraction at which one needs to prompt models like Anthropic’s Opus 4.7 to get meaningful results in frontend development. It’s often not enough to say something like “make the red square clickable”, as an LLM is much more effective if you gesture using the language of HTML and CSS (“make div.nav-bar-button clickable”). Thinking clearly about data structures and how they will support the functionality in your application is also work worth doing, as Claude will not (in my experience) do it for you.

Footnotes

  1. ^ Not all PhDs have this latitude: but my program does, and I’m very grateful for it.