But I think it's a mistake to jump to the conclusion that these apps should be written in a native framework rather than a web view. Slack is doing much more than Adium: web previews, document previews, pulling in pre-rendered fragments from the server and modular stylesheets. I wonder how much RAM Adium would have used to do the same things, and I wonder how much time the developers of an equivalent cross-platform app would have spent if they had been split trying to optimise lots of different platforms. They would essentially be re-inventing a modular layout and rendering engine (aka a web browser).
I don't know what the answer is. Maybe the detractors would prefer that the app did less. I know I'd prefer not to have previews and emojis, but I'm sure my colleagues find them useful.
(EDIT: Per reply below, turns out Adium did use a web view for presentation!)
Also, to echo your point: yes, the amount of free stuff you get in a web browser would be an absolute nightmare to reproduce in some native code environments (especially cross platform).
The only reason I'm still wary of running any Electron app for long periods of time is because I do end up feeling the same sluggishness that I feel with Chrome open after awhile, and I don't think there's much that can be done about that. With that said... I've been using sluggish apps since the Windows 98 days, this isn't a new concept.
I took a look at the Telegram source code right now, and…I'm not impressed. It appears to be written without a real knowledge of how Swift or Cocoa works, has no consistent style, and seems like it reinvents significant portions of standard APIs. Like anything, the benefits from migrating to "native" only work if you actually utilize it correctly.
I also pointed out Telegram because people, consistently, in every one of these threads, trot it out as an example of a native chat app (I don't count the Qt version in any of this, because it does not in any way feel native on macOS).
To be honest, I welcome anyone to point out a competing cross-platform chat application that does almost as much as Slack does and doesn't eat up memory.
Yes, but I don't feel that a message app really needs to do this to the extent that Telegram does–they've managed to make their app look out of place on macOS.
The rest of the apps I find myself using don't use those same UI/UX patterns/designs, and I don't think it matters that much: Photoshop, Terminal, Telegram, Bear, Fantastical... the list goes on. The applications that keep me coming back are the ones that are smooth and don't interrupt my train of thought (most everything here), or have some big use case (Photoshop) that keeps me coming back.
I'll also point out one more time that Telegram is what people bring up every time this discussion rolls around, so they're clearly doing something right and people must not think it looks _that_ out of place.
Hell, I'd argue that the consistency of UI/UX on Apple products matters more for the initial purchase and wow-factor than it does once a user has settled into their environment. Every application does not need to function and look exactly the same.
To be honest, this all feels like moving the goalposts, and is why I usually refrain from getting into these discussions.
EDIT: Leaving aside the question of whether the other multi-platform messaging apps also do it that poorly, and merely running with your assertion to that effect. I have neither the time nor the inclination to gather data on that question.
So if you know a way to achieve your ideal, then you can propose that alternative, and you can say, here is how, without much more cost of development, you can achieve X, Y, X improvement on performance while keeping all features. But, if you do not know, and have no known examples, it could indicate that it is not currently technically known how, and thus impossible with the current hardware and software knowledge at hand.
I'd also say that in the case of Slack, their ideal is probably defined more in terms of profits. So it could be said to be the right choice, simply because of how popular their service is and has remained, even though they picked Electron for their desktop client.
Why not just use another tab in your existing browser then? Or another service entirely?
Either way, it doesn't change anything in creating a widely used application for the least amount of time and effort. The vast majority of their users will not care or even notice if there was a more efficient native app.
My employer dictates the choice of communications tool. I don't just get to "pick another service entirely."
EDIT: And their site's 2FA (which I'm required to use, because $work) also reliably gives me "too many login failures" on the first login attempt, so using it in a browser tab is a non-starter, even without also losing desktop notifications.
With the amount of money they've been given, both by VC and by customers (I know what we pay them per month, and although we're not a small company, we're far from their biggest customer), this quality of software and service is absurd.
I am using Slack since more than 3 years too. I have tried their web-app, desktop client, iOS app, everything. The iOS app is pretty good and gets constant love. Both the web app and desktop client are pretty much equal in performance: laggish and slow. My laptop has only 8 GB RAM and a 3-4 years old CPU. The next Lenovo I'll be getting is available with max. 16 GB RAM.
I have switched to the web app in my Chrome since ~2 years, because after all, the desktop client does eat more RAM, since it will have 2-3 extra processes, whereas running as a Chrome tab, those processes already exist anyway (i.e. GPU process).
To have the Slack tab always open as a single dedicated window, without the toolbar and tab bar etc. I use this as a bookmark:
javascript:(function(){window.open('https://your-company.slack.com', 'Slack', 'scrollbars=no');;})();
Coming all the way from ICQ, IRC, Miranda etc. Telegram is the best chat client I have ever been using. The iOS app is great and about the same quality as the WhatsApp app (which is maybe slightly better), but since most of the time I'm infront of a real keyboard, I'd rather use the desktop client, which is just really snappy. The product design comes close to Apple products. All the drag&drop features, selecting of multiple messages/pictures, search, hotkeys ... Someone really did an effort and thought about all these small details. You can't imagine how easy it is to show all sent photos, easily browse through all of them with hotkeys and they show up instantly, or show all sent URLs, and so on. It is so good, that many times, I'd rather get up from the sofa and sit down at my desk to type a 2-3 sentence message to someone, than using my iPhone (WhatsApp or Telegram or iMessage). Oh and it has bots! I actually did one! Announcing delays and stuff for public transport in my town, using a server with php that is doing all the web crawling. I'd never even think about doing that in Slack.
I'm happy to be wrong! I think one thing that sucks about these discussions is that everyone gets different results on their machines and it's difficult to pinpoint why memory usage might be so high - e.g, I have a slew of cryptocurrency chats open, so maybe Telegram is just doing that much more work or something?
Sorry, that argument just does not hold water. On my Mac currently, MS Outlook is using 483 MB versus Slack using 704 MB, with just one tab open. For all of Outlook's bloat, one can hardly say it does less than Slack; it's just a glorified chat app for pity's sake.
Even IntelliJ is using only 2x as much RAM as Slack with 4 medium sized projects open and IntelliJ is orders of magnitude more complex than Slack.
The only reason we are trying to switch from Skype is for the persistent and searchable history. I say "trying to switch" because about half the company prefers Skype messaging and so now we have to have two clients installed.
Whether people use all of Slack's potential or not it's a different discussion, but I'd rather have the ability to do more if I wanted to than having to look for yet another tool to solve a small problem.
I don't think that means that the default client can't be lean and efficient.
As to web hooks and bots, if you really think that necessitates having it be a bloated Electron app, I don't know what to say.
All of these are dormant features.
> 3rd party integrations
Which are processed on the server.
The complaint is that Slack uses an ungodly amount of resources when they're just sitting idle consuming new messages.
It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag.
1.0 release is going to be out in early November.
1. Downloading embedded web browswer had been at 0% for a few minutes. At I went to close it, I noticed the counter creep up to 1%. The download is _slow_!
2. Not open source. I cannot trust a proprietary app with my login information to my communication channels.
Once the app is open source, I'll happily give it another try. Thanks!
I'm setting up a company right now to increase trustworthiness. Like the home page says, no data will ever be shared with anyone and soon it will be possible to verify this.
Why is that? Are you licensing code from somebody else?
Browsers—well, Gecko and Edge; WebKit and Blink aren’t quite so good at it—tend to do things properly or to a remarkably high fidelity. They put enormous amounts of effort into getting it right, because it’s worth it for them. Something like Qt also puts a lot of effort into getting it right (even if it still commonly requires the developer to make certain choices to use that rightness).
But something like this, not using any GUI toolkit? Games can do it, because they aren’t trying to fit in with the everything else, but regular applications just shouldn’t do it. I have never seen a single one that was even good, let alone great. They always fail to handle various important things properly, and so tend to wind up painful to use or even unusable for many users.
If you care about your users and are not making a game, the sad truth is that drawing all the controls yourself is irresponsible.
I agree, but the solution is not going to web, but instead using the OS provided UI toolkits.
OpenGL is not accessible and the current UI looks hacky.
No, it supports Gmail via the Gmail API. Soon it's going to have a full email client built in.
EDIT- here’s a source on that http://meyerweb.com/eric/thoughts/2005/12/19/adium-chatting-...
Slack, on the other hand, feels like JavaScript frameworks piled three or four deep, often getting its UI out of sync with the actual state.
Chats/channels will briefly flash (1) unread in the sidebar to tell me about my own message that I just sent, or I’ll continue to have a blue “10 new messages” banner in a conversation that I’m actively participating in.
I use it because it’s convenient, but there’s definitely room for improvement.
It is a list, with some images. They have Rubegoldberged themselves into some Sisyphusian box of poo while they expect us to row the SS Honeybucket to work and back.
You know what my solution is for when I need to slack? I RDP to a VM running Slack. Mother of Lord! How about Slack sell lil USB ARM computers, like a chromebit that just runs Slack? Maybe I could pair them with my Snapchat glasses! Modular, yes you can!
please define this new word
I would. Unfortunately with these browser-based app solutions, rarely are features and resource usage proportional. Therefore, runtime configuration doesn't help that much.
I personally would like to see Chromium take a more staunch approach at memory reduction.
Last I checked, they had full control over all the rendered content, including the snippets that show up when you paste, say, a YouTube video. They do use HTML UIs here (e.g. the embedded YouTube player), but is this stuff coming directly from the upstream source or from Slack? I would hope the latter. After all, it seems you can paste a direct link to a video file (e.g. .mp4), and Slack renders its own video player.
I never understood why Slack didn't spend their many billions of cash rewriting the desktop app with something like React Native. Even if they do need to render third-party snippets, they could still embed web views for those instances, which should hopefully be in the minority.
Of course if we'd use an interoperable standardized protocols instead of walled-garden apps, then your colleagues could have their cake and you could eat yours too by allowing everyone to choose a client based on their preferences.
It's not like my laptop is just brimming with extra RAM, and being a Mac of course the RAM isn't user upgradeable.
My choice shouldn't be "be present in chat, or carry out work". Guess it's time to figure out IRC integration.