I often get asked the question, "what is Frontend Engineering?". Typically, my answer is "I make the parts of the app you interact with: the boxes, buttons, and animations on your screen". While that's largely true and easy to digest, it doesn't capture the purpose of a frontend engineer. This made me consider the answer had I asked myself the same question. I reached the following conclusion:
"A frontend engineer builds the interactive User Experience while ensuring the data presented is in sync and accessible."
This answer is also standard, but I think this helps as a starting point to break the discipline down further. Almost every application frontend is comprised of the following layers:
- Data
- UI state (theme, navigation)
- Storage (typically your backend service)
- Interactivity (events)
- Presentational
- UI
- Animation
A change in the data layer should trigger a corresponding UI update. An interaction should mutate some local state or trigger business logic on the backend (both encapsulated in the 'data' layer), which then updates the presentational layer again. You may be asking "what about navigation or theme changes?". Well, I also consider these data: more commonly known as state (or local state). While many developers group local state and network state together (Redux-Saga users), I believe it's easier to structure your app when local state and remote data are stored separately. Allow me to explain...
As frontend engineers, our function is to present data, let people do stuff with it, and update what is presented. We must do all we can to keep data and the UI in sync, but first, let's split this category into two sections:
- UI State
- Storage (async)
UI state encapsulates more than just a user's theme or logged-in state. Often omitted from definitions of local state, navigation state is the most pertinent facet of local state. Almost all UIs need navigation to manage and switch application contexts, therefore I bucket it in the frontend data layer. To some, this may seem obvious, but if you participated in the, "store everything in redux" movement, navigation was often forgotten in talks of state as wasn't managed in Redux.
Remote data includes our backend and business logic. Arguably one of the biggest challenges here is de-duplication or caching (saving a local copy of what's been fetched so far to reduce round trips and improve performance). A user flair in one screen may be updated on the current screen, but not the previous: causing a divergence of what's presented in separate instances of flairs. Today, we are spoiled with libraries such as Apollo Client and React Query that encapsulate caching, storage and retrieval for us while handling subscriptions. With the help of GraphQL, Apollo Client takes this a step further by normalising our cache - meaning, if you fetch a list of comments that contain users, every cache entry pointing to a user in that list is updated, even if the source was a different query. This means your frontend is always in sync and old entities are updated.
UIs must be interactive. Almost all platforms provide event handlers we can attach to UI primitives. This is what separates applications from mere documents. Every interaction should be accompanied by a presentational response so a user receives some form of feedback. In some instances, developers turn loading indicators into small games such as Youtube's snake game during buffering. In most cases, however, interactivity updates some state or triggers an action, which then updates the presentational layer.
The presentational layer is always derived from the data layer. Here we typically work with the UI primitives given to us by the underlying platform such as buttons, lists, styles, and sometimes animations. The web was initially a decentralised network of documents, hence the Document Object Model and more static approach to rendering and UI updates. Native apps seek to turn the device into an extension of our body and surroundings and provide fluid screen transitions and interactivity, with animations modelled on Newtonian physics. The boundary between the two is being blurred however as JavaScript increases in power along with the proliferation of SPAs (single page apps) and the underlying Web platform adding native support for page transitions.
While much of this may be intuitive to you, as it was to me before answering the question outlined above: I found that deconstructing my definition of frontend engineering helped recenter my focus to the broader problem. This made different frameworks, tools, and libraries more approachable as they could all be traced to helping solve this one broad problem in my use case.