Nate Meyvis

The last decade of front-end engineering

Here are some claims about front-end engineering:

  1. An era in front-end engineering began around 2016, when (i) React and Angular (and some successors) took off and (ii) a critical mass of users ran hardware and browsers that could support modern Web experiences.
  2. This era was way, way different from what came before it. If you have never tried to implement a non-trivial front end without the abstractions that modern Web frameworks offer, it will not be easy to grasp how big this difference is.
  3. Front-end coding, more than other environments, tends to be fundamentally asynchronous. (Things happen slowly; latency is less predictable; many things are happening at once; inputs are less predictable.) Asynchrony tends to break our brains.
  4. Relatedly, and I say this with nothing but love for my craft and its community, a lot of front-end code was and is quite poor. In every corner in tech I know of, and by every measure of code quality I can think of, front-end code tends to be worse than other code. (On average! There's a lot of wonderful front-end work out there, too. Before the LLM era, I considered myself a front-end specialist. More generally, I've long thought that we could be doing more on the front end.)
  5. It's a lot more common for engineers to say that they're "not really front-end engineers" than than they're "not really back-end engineers." Even senior-level engineers at respectable companies often feel very little pressure to be conversant with front-end programming tools and techniques.
  6. In many institutions, it's hard even to recognize that front-end code is in a very poor state, not only because the immediate engineering team might not have expertise but because the organization's leaders don't know or care about front-end code quality.
  7. A lot of what we try to accomplish on the front end now was effectively impossible before. Because of this, "front-end engineering" used to mean something much closer to "wrangling HTML and CSS so that the layout was reasonable across devices and browsers."1 Many of the questions that we often take to define software engineering (e.g., "Where do I store this information?" and "How do I encapsulate this messy process?") did not even apply as straightforwardly to these situations.
  8. So, "front-end engineering" often referred to tasks that are now described as "design," "layout," "UX," or similar.
  9. Even as front-end engineering changed so radically, it has retained these associations with visual design, superficiality, and poor code quality. This is partly because many of our colleagues formed their opinions before the React/Angular Era and have never revised their beliefs, and partly because cultural vibes change slowly.
  10. Front-end engineering was (and I'd say still is, though not as much) coded as a more feminine domain. It used to be common2 to hear stories of female full-stack or back-end engineers claiming, quite credibly, to have been assigned front-end work, on the assumption that they were less skilled and more suited for design and layout work.3
  11. The React/Angular Era (see (1) above) is ending, not because there are better frameworks (or alternatives to frameworks) but because LLMs are now writing so much of our code for us. Even if we're still using React and analogous frameworks, we'll be using them in radically different ways.
  12. It seems to me that LLMs are quite a bit worse at writing maintainable, solid front-end code than back-end code.1 I often find myself explaining what I think of as basics to the LLM. Other things equal, I often find it more efficient to spend energy improving an LLM's front-end code than its back-end code.

I am still not a futurist, so none of the above is a prediction about the future of React, the future of LLM competence in front-end code, or anything else. It is instead intended as a partial justification for these claims:

  1. There's a whole discipline of front-end engineering that basically didn't exist much more than a decade ago.
  2. When people complain about React or are having a hard time implementing something in React, what they're often actually complaining about or struggling with is intrinsic to the front-end environment.
  3. Although many of our individual colleagues know very little about the discipline before the "React/Angular Era," the collective vibes and attitudes around front-end engineering were largely formed before it.
  4. I suspect that this mismatch still creates a general sense that front-end engineering is less valuable and less important than it actually is, and this is bad both for the quality of our craft and for the culture more broadly.
  5. We might be more able to do good work with LLMs if we understand more fully how we got where we were without LLMs.

  1. It's amazing to me how few problems these days are caused by differences between browsers. Browser compatibility, and especially Internet Explorer compatibility, used to be a much bigger part of an engineer's job.↩

  2. Not that this doesn't still happen. I just haven't heard these stories in a while.↩

  3. Here as elsewhere, I don't mention these issues to contribute to a culture war. Rather, it seems to me that (i) the history and even recent history of front-end engineering cannot fully be understood without reference to sexist attitudes; (ii) it also cannot be understood without understanding how blurry the distinction recently was between front-end engineering and the historically less male-domained disciplines of design and UX; and (iii) this was all quite a bit more obvious before, say, 2018, so that there is now a generation of engineers who are less likely to have seen quite as vivid evidence for these claims.↩

#front-end engineering #front-end maximalism #generative AI #psychology of software #sociology of software #software