1. 9
  1.  

  2. 1

    From The Origin of Stimulus

    At Basecamp we’ve used this architecture across several different versions of Basecamp and other applications for years. GitHub has used a similar approach to great effect.

    I commented the other day to a friend that it clear that GitHub is using a turbolinks type approach because it feels slow. I’m on GitHub a lot and I feel like I’m always waiting for it. Compared to FastMail or Twitter for example where the app feels much faster. I’m not a huge proponent of JavaScript but React and co often make for a snappy experience.

    1. 1

      (edited because I posted before my writing was good):

      The turbolinks approach is much more efficient (eg almost no JS required), but:

      • When you click a link, the page doesn’t know which parts of the DOM are going to change (you could, in theory, make this happen - but it’s not done)
      • As a result, you don’t get the same quality of loading indicators (eg a progress bar at the top vs instantly changing the design to look like the new page)
      • It generates less-cacheable requests because the previous layout tree forms part of the cache key.

      For me, my Fastmail inbox takes ~5s for an initial load, ~3s for a refresh and 1-2s for an internal navigation.

      The linux project page on Github takes an initial ~4s load, ~2s for a refresh, and 1-2s for internal navigation - but it feels much slower because instead of replacing the page content with a loading indicator, it uses a progressbar across the top.

    2. 1

      I’ve been playing around with Stimulus. It is really cool.

      The main difference with Stimulus verses other JS Frameworks is that Stimulus aims to manipulate existing DOM elements verses adding them in. With the combo of Turbolinks, it can be very powerful.