I’m the opposite. If there is a well written app on iOS or iPadOS, I’ll use it for the increased privacy protections, lower battery and CPU usage and (sometimes) lower bandwidth consumption.
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 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.
Webapps have better privacy protections than native. Battery/cpu is a tossup depending on the app. With the example above of chat apps I've found that the webapps use less cpu/memory.
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.
A well written native app should use less battery and CPU than a well written web app. Lots of native apps are not well written though and, like Gruber said, many are just a wrapper around a web view showing their website.
Native code should be able to do more work with less power, yes. But in practice, these kinds of runtime efficiencies aren't the overarching factor. Native apps add features and these features in aggregate end up using far more memory, cpu, and being otherwise invasive into the system -- for example, the discord native app attempting to ptrace everything else on the system.
The extra crap -- especially information gathering -- ends up making the native apps slower and buggier.
I can use uBlock on the web, I can't do that on iOS. I'm fairly confident that it gives me more privacy than what I can get on iOS. It's much easier for me to get a vague idea what a webapp is tracking and what it's doing. You can see all the network requests, you can disable javascript, disable access to certain APIs etc.
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.
Of the two major mobile OSes, one is literally owned by an ad company and the other is increasingly succumbing to the dark side of advertising. Why would I trust Apple not to do nefarious things with all the tracking they do ("privacy" my ass) when I could just use a browser with an adblocker and do even better?
(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.)
> I’ll use it for the increased privacy protections
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.
> I simply won't use a dedicated app for anything that can be done in a web browser.
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?
> The only things I can come up with are apps requiring access to outside hardware or files
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.
I believe the discord app has some weird limitations around global shortcuts and push-to-talk when you use the browser tab instead of the desktop app.
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.
Discord optimizes streaming your gameplay by injecting DLLs into your game when you go to stream it (I discovered this, and the setting to disable it, after trying to figure out how the hell Puzzle Pirates could crash due to being streamed). I would be very. Very, very surprised to learn a website could do that. Hell, any streaming of whatever separate application you're running seems like it shouldn't be possible from a website.
If you'd rather use a native application, I can recommend Ripcord[1]. Ripcord is an alternative client. Unfortunately, the developer doesn't seem to make many sales, so some features are not implemented.
The demo has infinite days, but it's a good idea to actually donate if you like the project :)
Is that tweet ripcord related? The original tweet to which discord is responding is deleted.
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.
