5 ms·

I found this little thread on Twitter interesting, complaining Hey (powered by hotwire) is too slow https://twitter.com/youyuxi/status/1337851036015480843 http

• petey283 6y ago
  And here's some additional followup. Minor speculation that maybe his location is what caused slowdown. https://twitter.com/swyx/status/1292825527116369922 https://twitter.com/swyx/status/1292825527116369922
  • methyl 6y ago
    That's one of the reasons SPA aren't going anywhere: trying to handle all the user microinteractions on the server is great when you leave next to it, but it falls apart when your users are spread across the world, especially if it's not western-ish world with fast internet connections.
    • vasachi 6y ago
      Huh? How does SPA help here? JSON payloads don't go faster over the wire than html.
      • jeroenhd 6y ago
        JS interacting locally can make a web page be perceived to be faster, even if there's no meaningful content yet. Humans enjoy working with systems that so _something_ as soon as they interact with them and a placeholder/spinner/animation is that exact something. Of course, you don't want any placeholders or animations to go on for too long, but it's good to know that the button you just pressed actually did something and the screen hasn't hung. Minimal JS pages often have very little direct interaction built in, so they feel blazing fast when the connection is good and the payload is small (HN is a great example) but terribly slow if your internet connection is bad and it's not masking the network delays (again, HN is a great example). The 2-5s mentioned on Twitter are something else though, perhaps the Hey app is being transferred through a saturated connection in the US or something.
        • vasachi 6y ago
          Well, a spinner can be added even into non-SPA applications. So I don’t see how that is an argument for SPA. I presume you can lie to user by pretending that their change was instantly submitted, while syncing in background. In that case, yes, SPA all the way.
          • ZephyrBlu 6y ago
            That's not really lying, it's good UX. Optimistic updates feel a lot better than waiting for something to happen.
            • hombre_fatal 6y ago
              This varies on how important the action is. Optimistic updates are great for inconsequential stuff like an HN upvote. The user likely doesn't even want to see an error message if their upvote timed out. But it definitely is "lying to the user", or better phrased "breaking user expectations". It's just that the user isn't likely to care except for important actions. For example, imagine applying optimistic update to sending an email. The user would expect to be able to close their laptop after sending an email and seeing the UI transition. It would be catastrophic if the email was never actually sent. Optimistic updates are best relegated to micro-polish imo. Frankly, I think it's overused especially in combination with autosave UI.
              • tompazourek 6y ago
                Gmail does this all the time, and it makes me mad. I just sort out some mails to have my empty inbox, and then close the browser tab. And it says that the changes haven't been saved, so I need to deal with the popup, and then close the browser tab again...
        • dsego 6y ago
          Skeleton screens and spinners don't feel faster.
      • dashesyan 6y ago
        Because the DOM can be updated client-side before the server responds
      • mromanuk 6y ago
        An app with longer usage leans towards SPA. Quick or sporadical stuff, shouldn't be a SPA. The problem is always doing, SPA all the things or Do everything in the backend like if it's 2005
      • deergomoo 6y ago
        Surely a JSON payload is almost always going to be considerably smaller than the contents of that payload laid out in an entire HTML document?
        • IggleSniggle 6y ago
          It’s not the entire HTML document, it’s piecemeal. As for sizing equivalent data in HTML vs js, I remember reading an investigation that XML and JSON are generally closer than you would expect and that for some data structures, XML is terser.
          • deergomoo 6y ago
            It's not XML though, it's HTML. HTML with additional nodes for layout, class names, etc. If you're not invalidating the cached code multiple times per day (which, in fairness, a lot of the stuff from Google, Facebook, etc probably are), an SPA should use less data over time than a comparable server rendered app. The initial outlay is bigger, but once it's cached you only need the raw data as you navigate around.
      • tonyhb 6y ago
        You're right, but the data can be cached and the views shown optimistically. After the first fetch it should be faster.
    • bryanrasmussen 6y ago
      In this non-westernish world the internet is slow but how much processing power do the computers have to render the SPAs?
  • Existenceblinks 6y ago
    Hey approach needs server on at least 2 regions to cover 90% of worldwide usage. I guess they only have server in the U.S. and some users may experience some lacking. I'd say having SFO3,FRA and NRT are pretty much enough for global customer.
• save_ferris 6y ago
  I got into the Hey beta, wound up purchasing it and I haven't had any performance issues to speak of. I'm curious to know what their setup is.
  • eecks 6y ago
    I've used Hey daily since it launched on desktop and mobile and I can't see it being slow in any way. I guess you could count that it shows a loading symbol for a file to appear (on the first load only).. but that would be excessive nitpicking.
  • corytheboyd 6y ago
    It never performed slowly for me. It ended up having none of the features I wanted, but that’s a different concern altogether. Definitely rode the hype train and feel dumb about it now haha
• konha 6y ago
  The inventor of one of the most successful js frameworks might be a tad biased when it comes to the whole „as little JavaScript as possible“ thing.
  • rk06 6y ago
    he is complaining on Hey's lack of speed and interactivity, not complaining about the lack of js. which is a fair complaint, I would say.
    • konha 6y ago
      It is. But he also wrote this in a subsequent tweet: > For a typically long running app like an email client, the obsession with shipping as little JavaScript as possible is actually detrimental to the end UX.
      • ZephyrBlu 6y ago
        I'd argue that's almost objectively true. For a long running app, initial load time isn't as important as something like a ecommerce store.
        • ymolodtsov 6y ago
          Hey probably is the worst example for this approach, even though it works and it's impressive what they were able to achieve. It should be much better for most website out there that aren't trying to be a low latency app you run 24 hours a day.
        • strzibny 6y ago
          Nope. And I will tell you why. To read my email I need the app to load. Gmail did not load for me in several countries and takes forever on a train wifi for example. I never leave an email tab open, but even if I did, I first need it to load...