Journal Jun 22nd, 2022

Public facing e-commerce sites have very different performance requirements and tolerances and even useful metrics than internal productivity tools. And that’s just two types of apps out of probably hundreds (or more)" #

  • I do think web apps need taxonimies, or holotypes for another phrasing. However I really struggle to find empathy with the stance that different apps have different requirements wrt to performance. With the taxonomy I've seen it many times where people then say "well productivity app's like gmail don't need to meet this core performance criteria" because you spend all day in them. I keep my gmail tab open because it takes so damn long to load. I click on a mailto link on the web and I want an instant "compose email" form to appear. #
  • I remember when I used to work a lot more in the enterprise space, we upgraded a major bank in the UK from our old terminal based Fraud Detection system to a spiffy new .net WinForms app. We thought it was the shit, they thought it was shit. And it wasn't until I watched the work flow of the Fraud Analysts that I realised that with the terminal they had a few milliseconds latency for all of their interactions including loading the "app" and actioning fraud cases. Our new magic solution to 15 seconds to load, 5 seconds to perform an action and 5 seconds to navigate between screens. #
  • DX was important to us as a company, we chose .Net because it enabled us to build new modern interfaces instead of forms using an Informix database. It allowed us to hire more quickly, use source control, integrate with a modern IDE so we could refactor and unit test. Ultimately the customers didn't care we could work faster, we were slowing them down and losing them money... just wait until I tell you what happened when we moved to ASP.Net :D (ViewState happened!!!) #
    • Relating back to Surma's "The cost of convenience" this is one of those places where ASP.Net hurt us bad. The framework was a great developer experience, we could move our WinForms thinking to the web, but the consequences were severe for the user experience. #
  • Maybe the take-away for me is: understand how apps work and fix lighthouse and our tooling to keep focusing on an holistic performance narrative, not just load. #
  • #

About Me: Paul Kinlan

I lead the Chrome Developer Relations team at Google.

We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.

Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.