Migrating Slack's Desktop App to BrowserView
slack.engineering
slack.engineering
I'm a big JS guy, believe me, but I wouldn't call a chat app using "only" 800MB of RAM a "win." Sorry to the guys who worked hard on this.
So I could imagine that compile-to-javascript languages could get you much faster apps than traditional JS.
EDIT: Not defending Slack's choice of JS, or the consequences of that choice on its memory footprint, CPU utilization, or excess consumption of my battery in any way, but it's not purely a matter of "which one is the most efficient/performant/whatever?".
.NET Micro Framework | Apache 2.0 | Win+Bare Metal
.NET Core | MIT License | Win+macOS+Linux(x64+armhf)
Xamarin | Proprietary | Android, iOS, and Windows
mono | MIT License | Linux Mac OS X, iOS, tvOS, watchOS Sun Solaris BSD - OpenBSD, FreeBSD, NetBSD Microsoft Windows Nintendo Wii Sony PlayStation 3 Sony PlayStation 4
Of course "having a runtime" is not the same thing as "having a good way to write cross-platform applications".
Are those runtimes all bytecode compatible? Or is that another layer of developer cognitive burden that the more efficient/performant/whatever choice entails, atop the whole "having a good way to write cross-platform applications" tangle?
JavaScript does though, and it even doesn't need bytecode.
This is what I don't want, I want it to look like every other desktop app, I want to be able to set the theme of my OS and have every app adopt it, I don't want every piece of software thinking it's special and looking different.
> Harder to work with than CSS.
What native technologies have you used? Many are easier than css+html and look native by default.
Harder for a web developer for the first two weeks. UI builders are more suitable for making app layouts than CSS.
> Harder to align look of web and desktop.
Thousands of mobile apps do it without much trouble.
Meanwhile, Doist is a smaller company but they made Twist[0] clients native because they care about their customers.
[0]: https://twistapp.com
It's a problem, but is it an actual problem..?
But how much do you have left? Is RAM in computers to sit there, or to be used?
I get it, but all the fuss seems exaggerated to me.
Between NVMe disks and the ability to have 64gb of RAM if I want...keep it coming. I’d rather have heavy software than no software.
Some posters seem to think that, because you CAN build a chat app consuming a few megabytes of RAM, it means you should and it's practical. It's like pointing to 64KB demoscene games and saying "see, you can write a game in 64KB, why does this one take multiple gigabytes".
Well, by all means, create a Slack competitor in hand-optimized assembly if you wish. Or whatever else you prefer (Rust?). If it's a better product, it may take over market share. Assuming your users even care about that. Hint: most are not obsessing over TOP, Activity Monitor, or whatever your OS uses.
Otherwise, don't whine. Electron makes it possible to create and ship apps very very quickly. Apps which would not exist otherwise. Every time you remove a barrier, you open up doors for more people.
While spinning up an entire browser for a single app has memory usage implications – namely, the baseline consumption is high, as is download size – the biggest issue is that it is easy to be wasteful when using web technologies. Look at Visual Studio Code, for instance. It's light and nimble compared to alternatives. It's true that a single one of its workers consume as much memory as a whole Emacs instance, but the development pace is staggering. And it still uses less memory than Slack...
I defend decisions made by IDE developers because those are niche markets, but slack is not a niche market. They're "IRC for normies" (yes, yes, they fix a lot of cruft too but, it's effectively the same system).
We're not talking about hand optimised assembly, but maybe assuming that I'm going to throw 1/8th-1/3rd of my system resources into your IRC clone is not healthy.
the highest tier macbook pro can only handle 16G of memory. I had to get a special laptop (precision 5520) in order to get 32G of ram, which I feel is the only option that is future-proof for the next 3 years, and if everyone follows the slack model then it will be the minimum in less than that.
But that would encourage competition and open up the market, something that web 4.0 companies never want.
Most users think their computer is broken, or they have a virus, or something along those lines because the perceive how slow their computer is but they don't have the knowledge to place the blame where it belongs.
RAM is pretty cheap, I'd rather put money towards a better Linux machine than give that money to Microsoft for the OS.
Eventually, when every single desktop app is like this, and we can no longer keep shoving more RAM into computers, we'll realise that the only way to manage such hogs is to pickle background apps to disk Android-style and to just have one foreground app in memory. And that's when we'll all realise we might as well switch to Chrome OS. Well played, web devs, Google says thanks.
Or maybe Electron is a conspiracy by someone heavily invested in RAM production?
No, the real casualty in this cycle have been spinning rust, good old hard disks. Their performance was never great but a sure fire way to kill it and make sure it never recovers is to trigger a full fucking unthrottled index scan at every boot that inevitably finds nothing changed. Looking at you Dropbox.
Everything is cheap when you have a high salary even by your rich country's standards. There are other users outside of SV.
I rather put money towards responsible developers than contributing to the waste of more computing power and more electricity than Bitcoin wastes, while doing basically nothing over what Sublime Text can do.
I mean, if there were no other way to code a text editor I could accept the idea of Atom. But with faster alternatives, it is just an exercise in consumerism. Wasting computing power for the sake of wasting computing power.
It's the rolling coal of computers.
There are many laptops which have fairly low total system RAM limits. Those in our workplace are 4GB and 8GB for example. Once you hit that limit the cheapness of RAM is irrelevant.
It was quite productive and straightforward. That said, Java likes to use as much RAM as it can get even if it could release a lot back to the OS. It looks at it, sees it's free and thinks "I might as well take that".
That shouldn't be the goal. Linux and Windows have different norms when it comes to UI design, and (usually) have completely different widget appearances. You can save yourself a lot of headaches by just specifying the bare minimum (i.e. the widgets themselves) and letting the user/system remain in control of exactly how they appear.
In other words, if you're treating desktop GUI design as equivalent to web GUI design and expecting your app to look the same across all platforms, you're going to have a bad time.
https://github.com/yuya373/emacs-slack works on Linux, and doesn't chew up CPU, RAM & disk to do it.
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.
Either I'm getting old and grumpy, or it used to be possible in the year 2000 without your computer fans taking off and 1gb of ram.
In 2017 there’s no tech stack that lets you write consistent UIs across multiple platforms. Except, unsurprisingly, Electron
I don't want something which is as weak & unusable as what I'd get on Windows or macOS.
Slack has raised some serious capital, however. The desktop app is the cornerstone of their product and performance is a known pain point (cpu/memory). Why haven't they left electron in the dust and taken performance seriously?
I won't use the desktop app because I have standards. But apparently we're too few in number to matter. And from a business perspective there's nothing wrong with that. Frequently what engineers want and what makes (good business) sense are different.
Slack switching to something like Qt would (maybe) fix Slack, but then we would still have many slow Electron apps.
That would be awesome post if it was made as an experiment, to test the limits of Electron, to learn and let others learn, to just play with BrowserView. But seeing this as a technical write-up about one of the very popular chat apps used out there, it's just sad and wasteful.
But then, it takes 30 seconds (!) from opening the application to being able to type the first message. There is no other app on my MBP that needs so long, and we're talking pretty new hardware with SSD and an i7.
Sorry, but I don't care about your portability across different platforms, I just can't. I want the best experience on mine.
Though at least there is a workaround: put it all the way to the right, then let other windows obscure the rarely-needed left portion of the Slack UI.
It's a wrapper for the system-supplied Webkit, so it inherits those benefits from that. I've been experiencing a similar performance to Chrome in Safari 11, but lower RAM/CPU/GPU usage overall.
[0] http://jimpurbrick.com/2017/01/04/vr-redux/ , http://jimpurbrick.com/2017/07/04/react-vr-redux-revisited/
[1] https://github.com/markerikson/redux-ecosystem-links/blob/ma...
Furthermore, BrowserView versus WebView isn't even necessarily a concern for every Electron application. It's used for embedding remote (read as web server hosted) web pages. In the Electron apps I've been building, 100% of the code is hosted locally, and I don't have a need to host outside webpages.
So to make electron less of a hog, you ditch the web part?
[0] https://blog.figma.com/introducing-browserview-for-electron-...
Stop being lazy. You’re not a scrappy startup anymore. Build real native apps for each platform.
Using electron solves your problem. As a user it sure as hell doesn’t solve any problem I have.
Even the TLDR at the bottom didn't succinctly explain the advantage of browserview over the old way.
>For now, HipChat Cloud will continue to be supported, but eventually we will encourage all HipChat Cloud customers to upgrade to Stride.
This seems like business speak for "get converted to Stride sooner rather than later because HipChat won't be around for much longer".
https://confluence.atlassian.com/stride-documentation/faq-st...
HipChat will live on as the behind the firewall solution for companies that do not want a pure SaaS app.
http://tc39.github.io/tc39-notes/2017-05_may-25.html#17iiia-...
The BrowserView API is currently experimental and may change or be removed in future Electron releases.
Looking at my dock I have Discord, Slack, Textual (IRC), WhatsApp Web open.
I wish there was a service that just amalgamated all these together into one thing, with a rough set of common features (e.g. ability to post images/gifs/videos, text etc)