This is developed in QT by one person, and it looks pretty feature-complete to me. I really don't understand why a company the size of Slack invests all their development effort into such a subpar platform as Electron, when a native solution is clearly doable with very limited resources.
Several things I can think of: "quantity is not quality"; JS developers far outnumber everyone; making web apps look exactly the way they want is easy, and they are not interested in platform-native functionality, preferring a "consistent" UI across platforms instead; "premature optimisation" dogma that means no one cares about efficiency anymore.
Microsoft Teams and (later versions of --- they actually moved away from perfectly decent native Win32) Skype also use Electron, and that's Microsoft. That says the size of the company and its resources matters little in things like this.
Its easy peasy with Qt as well. I am the only dev for https://www.sostronk.com/app and it looks (and behaves) _exactly_ as our designer wants it to. (Oh, and this is when I'm also spending time working on backend stories).
> no one cares about efficiency anymore.
That is not true. Discord and friends spend a lot of time for efficiency because they're using Electron. It is not impossible to have a (relatively) efficient application with Electron (VSCode for example), it just takes more effort. Compare that with Qt where performance is free of cost - in the last 5 years at SoStronk, I've hardly ever needed to spend dedicated effort for improving performance. Another example, and I wasn't aware of this till very recently, is the Telegram Desktop app which is Qt as well.
But yeah, I do agree with your first point, the only reason Electron is in use is because JS developers are a plenty. At the end, cost is the #1 thing when businesses make decisions.
When Atlassian finally pulled Hipchat last year I was tasked with finding the replacement. Turns out the one that met everybody's needs best was a local IRCd and whatever desktop client for it people liked.
Some problems have been solved correctly for a while; chat is one of them.
It is very far from a solution in 2019.
I've never had a problem with DCC transfers, but I suspect I'm in the minority.
"It does not keep history of discussions."
Actually, there were several servers which had "MsgServ" bot which would remember your last logout time, and could go back to retrieve all those messages from its logs and auto-relayed them to you, all you did was ask it to replay missed content from x channel and you got it.
"It does not have media embedding."
If you used pIRCh98 as your client you had live video capability and could easily do a quick desktop share through OBS or similar software, but that did rely upon everyone using pIRCh98.
Slack is basically a modernized version of a mix of the best features that IRC clients and daemons and bot creators had.
The only thing slack hasn't seemed to copy yet from all the old IRC stuff is the ability to use mIRC as a desktop file system browser (that was fun to see being coded.)
IRCd - real time, ram buffering of messages. Quassel - reads and stores buffers in a database, allows users to retrieve them.
If only there were some sort of Universal scheme for denoting the Location of a Resource. That would let you map a relatively short string to one of many possible file access services, and put that string in a text chat channel, rather than conflating two distinct problem domains.
Also every server I know and most clients do logging.
So dial back the snark.
How does IRC handle end-to-end encryption in groups?
How does IRC handle editing messages?
Servers can re-send history when a client join. At least InspIRCd supports this (though it's not enabled by default.)
Blowfish normally.
Press up arrow, retype message, or type *correction.
Which specific daemon did you settle on?
Not really looking for replacement though (team is currently on Mattermost)
A lot of reasons... a solution 1) grows to match the size of its budget constraints 2) becomes more complicated the more people with long titles have a say in it 3) becomes more difficult to implement the more people that are working on it 4) becomes less useful the more people there are that can dictate what it does and how 5) fulfills more of the letter than the spirit of its requirements as more hierarchies of people manage it 6) becomes less user friendly as fewer typical users are involved with its development
Though the actual answer is "somebody with power just wanted electron for personal reasons and nobody had the power to turn the ship once it started on its course"
Personally, I recommend switching to Ripcord as a Slack client. That's what I did some time ago, and I couldn't be happier.