Are Frontend Frameworks Too Fast?

When I first started Cause of a Kind, we envisioned being an apparel company, not an agency. One of our first projects was a short film we produced to promote our mission and products. Being budget constrained I was the de-facto Director of Photography and did the filming for the whole thing. It was a super bright, sunny day at a beach at the East end of Long Island. I adjusted the frame rate and aperture settings as I was used to for still photography. With sun this intense I was regularly shooting at stratospheric frame rates. Seemed fine to me, until we viewed the footage.

I later learned, when shooting video, you don't want to shoot a high frame rates like this. The reason is that most of the TV we watch is shot at a lower frame rate. The movements for the characters thus have a slight, but unnoticeable blur to them. A softness if you will. My footage by contrast, was too intense. It felt abrupt and trippy. There was something about it that just felt wrong that you couldn't put your finger on. Thankfully, some post processing software allowed us to correct the footage to an acceptable degree.

Now what does all this have to do with front end frameworks? There's been a lot of talk about performance of front ends and one metric that comes up often is how many frames per second a framework can handle. For the vast majority of us, these frameworks have been fast enough in terms of fps for the last ten years. In fact, just like my cinematography experience, I suspect we're making our applications feel unnaturally fast.

Have you ever gone to a site where you navigated to a new page and didn't know if anything happened?

I have, quite often in fact. With the speed at which frameworks like next and nuxt navigate between pages, if your layout looks nearly the same, it's easy to miss if anything happened at all. Only by reading the content do you realize the titles changed and the content is different. When sites are so fast that items filter and pages navigate without even a flicker, it creates an unease. A fleeting moment of doubt, where you have to scan the content to figure out if the program took you where you wanted to go. In our quest for speed, we've forgotten that most people are used to a web that's just slower. That quick flicker of a blank screen or loading indicator or page transition, lets us know, that we just did something.

But let's take it a step further. What about all the modals, overlays, and toasts we add to our websites and interfaces? Ever have a mod once that instantly just took over the screen on a click. It felt abrupt and sudden. I was annoyed by it. But let's soften things a bit by adding a fade transition. We can also add some motion so the obligatory GDPR banner slides in from the bottom instead of just appearing a few seconds after the page load. It feels just a little less annoying and obtrusive when these elements politely disrupt our experience rather than just being there.

My argument here is two fold. One is that 40 - 60fps is not merely fast enough for most applications, it's desirable so our user's faces don't melt off. The second is we need to be intentional and slow some things down. Let's get back to using CSS transitions to soften disruptive UI elements and to indicate that our actions are being responded to. A loading bar, or a nice page transition can be what separates just another tool from what is truly delightful to use.