Modern Front-End Problems

November 3, 2022 Engineering/Front-End

This is a list of non-trivial problems I have come across in the front-end community over the past few years. It mostly exists as a personal reminder. Let me know if you have something that should be added here!

  • Accessibility: Making web apps accessible beacuse it’s so easy with the Web fundamentals to break things.

  • Bundle coverage: A lot of the code that is shipped in today’s bundles (CSS, JS, etc.) is not needed for the first render.

  • Data waterfalls: Waterfalls is a term used to describe serial loading dependencies. E.g. to render a list of users we first download the list component, wait for it to load, then the list component makes a request to an API, waits for it to load, etc.

    This is the number one issue that I have seen causing websites to be slow. It often manifests itself as a myriad of uncontrolled loading states that sometimes end in another loading state popping up. 😵‍💫

    An interresting observation: Most applications could be able to resolve all the data needed for the initial page load on the server side based on the URL, params, and authentication tokens.

  • Overfetching/underfetching: A client should only ever get as many data as it needs to render. Anything more is not needed and everything less is not enough.

  • Interaction delays: If I interact with an item on the website, it should show an instant response.

  • Layout shifting: Once the first elements on a website are shown, you don't want to have them jump around. This only causes confusion to the user and results in a poor experience.

  • Developer experience: I think this term is often overused but the current way we write apps is definitely not the end game. We need constant improvements to the tooling because the cost of building is still way too high.

  • Hydration: When you have a server-rendered HTML page and it needs to become interactive ASAP.

  • Reliability: A meta-term that is all about knowing if your app functions. There are many vectors this can be done, however easy mechanisms also have a weak correlation to actual user problems.

    • Error handling/tracking. Unfortunatly knowing that an error was thrown does not often relate to a broken website—Is the error recoverable by a user or is it crashing the whole page?
    • Browser crashes/freezes/loops
    • Uptime
    • Tracking core interaction uptime
  • Performance: This is a very convoluted term that justifies it’s own note. Until then, here are some thoughts:

    • Measuring page loads is usually simpler than measuring interactions (navigations, popups).
    • You can measure performance in a lab but this will only ever be a proxy to the real-user performance metrics (aka RUM—Real User Monitoring).
  • Efficiency: Another meta-term for a few lower-level optimzations that rarely cause problems (but when they do, they are noticable):

    • Memory usage
    • Heavy CPU usage
    • Uncontrollede scheduled tasks (e.g. setInterval)
    • Browser rendering issues
    • Network/IO overhead
  • Testing: While software testing is hard in every environment, front-end has a couple of special complexity with things like visual regression testing, accessibility testing, the reliance on a backend API, or the flakieness of browser instrumentaiton.


Other Notes

Engineering/Front-End/Modern Front-End Problems
November 3, 2022
February 27, 2022
February 25, 2022
Engineering/Test Matrixes
February 25, 2022
Engineering/Front-End/React’s Escape Hatch
February 21, 2022

About the author

Philipp Spiess
Philipp Spiess [ˈʃpiːs]

Engineer at Sourcegraph. Prev: Front End Engineer at Meta, curator of This Week in React, React DOM team member, and Lead Engineer at PSPDFKit. Loves fixing Web things.