This also voids the argument "we need Electron, because it reduces development costs, and we can get truly cross-platform apps". Ripcord is written by a single indie developer and runs on Windows, Mac, and Linux. Imagine what could be done if Slack employed a team with 10 Qt developers.
Most web apps are egregious. The problem is that there is a whole generation that is not exposed to Delphi or Qt Designer and have the false believe that developing web apps is an order of magnitude easier. It's only an order or magnitude easier for them, because web tech is the only thing they know. Heck, I was writing GUI apps as a 12y/o with Delphi.
They will definitely notice. E.g. baseline MacBooks (which is probably what most people outside developers buy) still come with 8GB RAM. If you subtract the OS, video memory, and some disk caching. There is not that much left on modern macOS (or Windows).
Having Slack + Skype in the background and some tabs open with modern web sites/applications can easily much a few GBs of RAM, slowing down quite a lot of 8GB machines. I guess most developers just don't notice, because their employer give them development machines with 16 or 32GB RAM.
People don’t care.
They don't care because they don't understand. They will just believe that their computers are slow and that they have to throw more money at it. Or they just buy an iPad and it will feel fast, because Apple does not allow every application to ship and run its own web browser.
no offence to the dev of ripcord; IMO qt and gtk stuff always just looks super outdated
That's because the developer decided to use their own theme. I have made a few Qt apps and on macOS and Windows you can barely distinguish them from a native app, unless you know where to look. Fully agree with Gtk+ though, it does not follow platform styling and conventions and is very slow on macOS (don't know about Windows).
That might still be better (I'm undecided, personally), but it's worth recognizing that heavy native app is still there, just shared with a lot of other JS apps.
I understand the rationale for going async -- you can never be sure exactly how long anything will take, and invisible things like memory management and caching can blow up your runtime; and if you get synchronous operations wrong, that leads to spinning beach ball cursors and “app not responding” errors, which are even worse than lag. But in that scenario, an async app isn’t going to perform any more usefully, you’ll just get a blank or frozen screen instead of a beach ball.