I really enjoy modern front-end web development. In particular, being able to develop components in isolation and being able to couple the display of DOM elements to the state of JavaScript data are great.

But invariably it seems that we neglect overall application display state in favor of working on components in isolation. This often results in a rather janky user experience—for example, loading indicators covering up actual content or multiple components otherwise displaying simultaneously when they clearly shouldn’t.

Why is this happening specifically with modern front-end development?

It’s not out of malice, but rather complexity.

Back in the old days (cue me yelling at the kids to get off my lawn), each page load would happen on the server, making sure all data are loaded before sending a fully-baked HTML page to the client. Then, the page would display in a very predictable state. Our users may have had to wait a bit longer to see the page, and it may have been a less “app-like” experience, but at least the content on the page all made sense together.

Even as we started getting more interactive content on each page (think jQuery AJAX calls), we were usually only working with small pieces of the app. So you could reasonable carry the dynamic context in your head: “this one widget may go through some loading states but the rest of the page is static.”

Thinking about the combinatorics

Let’s think about this another way: if I have a static page with a jQuery AJAX widget that has a loading, success, or error state, my page has three total state combinations. However, if I have a React app with 10 visible components, each of which have 3 possible states, I now have 10^3 = 1,000 total state combinations! That’s just way too much to comprehend.

We need a better way to enumerate allowable display states app-wide

I have a confession: this post isn’t offering any solutions, but rather just pointing out a problem: we simply don’t have a good way to enumerate all of the allowable display states of our complex applications. If we could enumerate these allowed states, we’d be able to theoretically prevent the unallowed app states (either through testing or some kind of automated checks—think type errors during compilation). Of course, enumerating 1,000 possible states is ridiculous, but there must be a way to approach this problem sensibly.

If we’re going to keep marching down this road of independent component-based front-end development, we need to do better at gluing them together. Users are having really poor experiences with our disjointed apps and we owe them better.