1. 38
  1. 12

    even for long-lived SPAs that the user may habitually check in on (think: GMail, Evernote, Discord), there are plenty of opportunities for a page refresh. The browser needs to update. The user doesn’t trust that the data is fresh and hits F5. Something goes wrong because programmers are terrible at managing state, and users are well aware that the old turn-it-off-and-back-on-again solves most problems. All of this means that even a multi-MB leak can go undetected, since a refresh will almost always occur before an Out Of Memory crash.

    Then these same devs/orgs develop so-called “native” applications running under Electron and the F5 escape hatch is lost and your system is brought to its knees by the same SPA that “runs fine” on the web.

    Desktop developers have to absolutely think differently about everything in their app’s lifecycle. It’s not just that desktop devs traditionally didn’t have a language as easy as JS to develop in and Electron is leveling the playing field, it’s that desktop devs developed apps along desktop thinking (you can’t get away with memory leaks like that when everyone and their mother knows how it launch task manager and see the resource consumption) and used languages and tools suited to r the job which made them inherently more complicated than your average webstack - out of necessity, not because of gate-keeping.

    1. 3

      Ctrl + R still works on Electron (slack, discord at least) :).

      1. 2

        TIL! Thanks, amigo. (But in all cases, users aren’t (yet) trained to do that.)

    2. 5

      Once, 5-6 years ago, I was called in to troubleshoot a performance issue wherein the page was too slow for its users to tolerate. The page was written in Angular.js and they couldn’t figure it out. After some digging I found out that they had been loading almost 7k items into a filterable sidebar in a hierarchical disclosure component of their own design. As if this weren’t bad enough, they hadn’t deactivated data binding on those items so even after the markup was generated and inserted into the DOM, every interaction dispatched multiple events without any need. This drove memory and CPU usage through the roof.

      Turning off the sidebar component’s two-way data binding reduced the number of watchers on the page from ~8k to under 600 and stopped the subsequent memory problems. It did not, however, deal with the initial page load and the freezing of the browser for nearly a minute while all that markup was rendered and injected into the page. We never did convince them that 7k filterable items was too much and was maxing out the memory of their laptops.

      Endless profiling and deep investigations showed us that we had pushed the old Angular.js to its limits and we’d need to look elsewhere. We ended up rewriting just that part in vanilla JS which sidestepped the problems entirely.

      Since then I’ve seen that Angular 2+ would have been able to handle this use case without an issue, as likely would React and Vue and others.

      1. 3

        There are a ton of “virtual” list / tree implementations out there as well.

      2. 3

        Deezer web still leaks 10’s of MBs every minute. This makes it unusable as it craches the tab way too often.

        This has been going on for years with a lot of people complaining. But the devs are busy worsening other things instead.

        A good example of how this is still very relevant.

        1. 2

          I’ve reported this, but it seems like it’s a Linux only problem … I’ve had no problem on Windows 10. (And I have no idea how they manage to leak memory differently on a cross-platform environment, maybe something related to DRM ?) And obviously, since it’s linux they don’t want to investigate nor fix it.