I exclusively use Discord in a browser tab. I simply won't use a dedicated app for anything that can be done in a web browser.
IMHO, mobile operating systems have gotten better than legacy desktop operating systems in a bunch of key areas. But of all the platforms, the web is the worst one. The web has tracking everywhere and often uses a lot of CPU, memory, battery, and bandwidth.
The alternative to using something like Discord on the web is not a well-optimized desktop app that is somehow more respectful w.r.t. tracking than the web version. Same goes for Slack, Zoom, etc. It will still use lots of CPU and memory, and now in addition to tracking you with the techniques available to it in the browser sandbox, it will gleefully list the processes running on your machine, rifle through your files, try to get itself to start up automatically on login, try to get it so that when you "close" it it's still running in the system tray, and generally just make itself at home.
Desktop apps written by devs who first learned to write desktop apps are better than web apps. Desktop apps written by web developers are like demons that have broken through the summoning circle. The browser sandbox doesn't protect you from fingerprinting techniques and the ensuing tracking, but it protects you from a whole lot of other stuff. Take away the sandbox and the shameless data vampires get anything they want.
I think you're correct that desktop operating systems are in sore need of a permissions model for non-free apps. It should be possible to build one, and then shame vendors into using it.
The extra crap -- especially information gathering -- ends up making the native apps slower and buggier.
I bet iOS electron based apps are tracking significantly more than FF + uBlock. It's also why I strongly dislike Electron. It's basically Chrome without uBlock.
(I'm not an Apple user and never will be because, with the highest privilege level being reserved for Apple themselves, I don't own the device / can use it for general computation. It goes against my principles so I'm not some apple apologist, it just doesn't make much sense to assume what you said. Google wouldn't surprise me at all....when using Google Chrome/-ium. That's a choice. On Android, your data is fully in your hands, even if you have to fight tooth and nail for getting it your way.)
Negative. It's actually the other way around. A browser is more controllable, especially with extensions.
An application in a browser cannot do certificate pinning preventing you from inspecting SSL traffic. Nor can you have uBlock origin running for your Discord app.
If you think websites track you, why wouldn't the app made by the company that adds the tracking on your browser ignore tracking you with their app?
In 2023, what app experience is still impossible to do in the browser?
The only things I can come up with are apps requiring access to outside hardware or files. There are now several entirely unique ways in which a AAA gaming experience could be delivered to a client browser. If we can ship resident evil frames to a Chromebook at 30+fps, is there anything we can't do?
That's not even 100% true either [1]. For instance, you can flash Android devices from the browser. The example in [2] talks to an attached Arduino device.
One use case also used to be that you would use a browser tab for one discord account and the desktop app for another, but container tabs + browser profile switching made that less necessary. And then discord eventually added support for multiple accounts.
I think we are just 1 tiny browser API away from this one being solved too.
If we can agree on a way to capture the pointer device, I'm sure we could figure out a reasonable way to capture certain user-defined keys. The actual key that is subscribed to can be abstracted away by using some registration API. I think this would eliminate key logger concerns (you'd have to ask the user for every key on their keyboard) E.g.:
RequestGlobalHotkey('my-hotkey-id', 'Discord Push to Talk');
and then if the user presses it, we call something like OnGlobalHotkey(e) where the arg contains 'my-hotkey-id' and keypress state.
a) communication protocols that aren't encapsulated in http(s), websockets, or webrtc. There's good reasons for some of this, and it's not that limiting, since popular protocols tend to grow some of these encapsulations to circumvent lazy firewalls, but it sticks out to me. Additionally, a page/app can't run a server for other browsers to connect to, it's got to be intermediated with a separate server; it would be difficult to make an offline LAN multiplayer game work.
b) reliable non-interactive push messaging and/or background connectivity. Again, there's good reasons, and you wouldn't like every page/app to have this capability, but this capability enables good offline usability by fetching data when available and pushing user driven updates when available.
For example, Email should be offline capable, and it should have nearly all the messages that were available when last the device had connectivity, and it should let me compose new messages and replies and queue them until connectivity returns. Maybe it should even speak IMAP and SMTP, but JMAP is probably good enough and browser accessible. Same with other messaging systems, assuming they have queued messages and aren't online only.
Screen capture API has been a thing for a while now:
https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capt...
It has a UX almost identical to discord with regard to screen/application capture experience.
The demo has infinite days, but it's a good idea to actually donate if you like the project :)
I've been using ripcord for half a year now, and my account hasn't been disabled so far. If they actually choose to terminate my account because I'm using a more efficient client, I'm going to be really upset.