These all have a lot more network overhead than an RSS reader that only has to periodically fetch a bunch of xml files. I feel like optimizing these kind of apps is a whole different problem space and a "native" app is probably not going to change that so much.
At heart, Slack is a chat app. Chat apps have existed for 40 years and don’t require a whole lot of data.
The complex part might be displaying the data, but that’s not much different than what an RSS reader does.
Even calling a chat app “complex” sounds absolutely ludicrous. It’s just that devs are now used to shipping 100MB apps in the name of fast development, so Slack is what we get.
I'm not sure when you used Slack the last time but there's a lot more than "just a chat app" and it sounds like one of these "I can build that in a weekend" comments.
There's video calling, audio calling, screen sharing, file sharing, permissions, media files sent around. It's not comparable to some old chat app where you only have to get new messages and display them in a chronological list.
I'm sure the app has to be able to deal with all that, and that unmistakably adds a layer of complexity which ought to exhibit _somewhere_.
On the other hand, when using the Slack app as a simple chat app - formatted text only, a few formatted in-line code snippets, things like that.. the experience can often be abysmal.
Just the other day, I was typing a _text_ message in a private chat, text only - no images, no fancy stuff other than a few bold and italics and inline code tags, and I could visibly measure the delay between typing and the text appearing on the screen.
That should never happen, regardless of whichever other fancy features the app _might_ be able to do.
> video calling, audio calling, screen sharing, file sharing, permissions, media files
Back before Apple dumped half the features and renamed it Messages, iChat had literally all of these features and then some and it was fast. It was efficient. It didn't run my CPU up to max no matter how I was using it nor how much, and it used very little RAM for an application in its class. It ran very well on hardware that Slack would choke to death.
Slack is the way it is because Slack has other priorities above being fast and efficient, it's not inherent to the nature of a chat app with AV calling, screen sharing and file sharing (file sharing was table stakes for a chat app even 15 years ago or more).
Telegram has done it twice, since both their cross-platform and their native apps are speedy, and they're different codebases started by different people.
Slack/others got where they are by not paying attention, not because it's all that difficult.
There is an unofficial one for Mac (i.e. not actively developed and anyway not by the core devs) - Seaglass. Pretty much dead/abandoned.
Besides, irrespective of what the founder (or someone) might say/indicate at times I really don't think Matrix/Riot is looking to compete with Telegram/WhatsApp/Signal. They are trying for a pie of what Slack and the kind have. I am giving up on Matrix as well for it to ever be a personal IM app/service. It' just doesn't make sense and biggest reason for that not happening are:
- People are not going to bother finding different instances, or host their own - they just want one service, one server
- The UI of Riot is specifically designed for group/team chats and I don't think they will try to stand in two boats in one app or have two separate apps.
- There's no money in personal IM apps. So unless there's a coffer like Fb/Telegram or someone like Acton donates handsomely at some point there isn't much there other than just being another Diaspora but in instant messaging space.
> It’s just that devs are now used to shipping 100MB apps in the name of fast development
Reminds me of that time people where upset they had to download a hundred MB OS update file instead. Turned out someone forgot to downscale some installer images from the raw bitmaps. After that the update was actually a few MB's.
But they control both server and client, so they could use an optimized protocol over a socket like in the protobuf family. Keep in mind that XML is a weird format in that you take your data, convert it to text, then compress it, transfer it, decompress it, convert it from text back to data, then interpret it. With binary formats these steps are a lot faster and more native to the machine.
RSS readers usually refresh every 15 minutes per default. So it’s number of feeds requests every 15 min which is very low. Compared to Discord and Slack which are permanently polling and streaming.
Discord always feels pretty fast once it’s started. Slack is a different beast, at least on my machine. I’m not doubting there’s room for improvement, just that the comparison to the RSS reader in the OP isn’t a good one.
