Creating a Slack app that uses fewer resources
kofi.sexy
kofi.sexy
For them, the biggest lever to improved user experience is almost certainly _product features_ not performance or native integration.
As much as I'd like drag and drop support or less RAM usage, Slack are mostly trying to convert people who have never used instant messaging in the workplace to using it daily (which I think is overall a win), and mostly trying to make users who are not as comfortable with software as we are use a new piece of software.
As an example, when I share a Google Docs link in Slack, I get a prompt from Google Docs _in Slack_ with a one click button to "fix" sharing so that those in the channel will be able to see it. That feature is probably vastly more impactful than improving system integration.
For there to be features like that, or an ecosystem of third party integrations, speed of development is likely a huge factor, and for that, being able to share the codebase across web and desktop apps is likely a no-brainer.
As much as I'd love to see a more performant Slack, it's likely that it would have large negative impacts on the speed of iteration elsewhere, and so I can understand why they don't do it.
Yes there are faster Electron apps, but typically they manage that by... not being Electron apps in certain areas, and sacrificing adaptability for that.
Also, Slack doesn't change _that_ much right?! Well yes and no. As an end user we probably only get ~10% of the changes – 90% may be experiments that never see the light of day but still have to be built in order to find the 10% that are worth it. And even then, assuming the new features are only designed for ~50% of users, because users don't typically use every feature of a product, you'll only actually see 1 in 20 changes that the Slack team build.
Not sure it even goes that far. They're trying to convince corporate gatekeepers to adopt it, and 'more features' sells to them. The avg person in charge of deciding to use slack at a company is likely not going to care if memory usage impacts other stuff on the users' systems.
re: the google docs sharing thing - I really hate it, because I'm pretty much always asked this question, and I say 'no' or remove the alert, then I'm asked again next time. And the next time. And across every org i have to use slack for. Either use 'corp' or 'room' preferences for this, or remember and respect my own preferences. Quit asking something repeatedly.
This is definitely the "enterprise sales" area where they seem to be doing a lot of work now, but a few years ago it was much more about finding an evangelist on a team somewhere with a company card, the pricing was structured so that you could get to critical mass on a typical pre-approved expenses limit.
> re: the google docs sharing thing - I really hate it, because I'm pretty much always asked this question, and I say 'no' or remove the alert
Yeah I absolutely get this, but I'd say that in wanting to solve a repeated annoyance like this we're already in the minority. Most users would treat this as a feature – they don't need to find a solution because it just asks them every time and it's easy to click the button to make it do what they what it to do.
Each time my wife turns on her work issued laptop (T470s, i7, 16GB RAM, SSD) with mandatory Norton Antivirus and mandatory Slack it's always fans on 100% and it pretty much stays that way all day. Not to mention the fact that it's a fucking chore to work on it because of the CPU utilization so the laptop usually stays on longer.
I wonder how much extra electricity does that use since there are a lot of people in her org and a lot of other orgs using Slack and whatnot...
With some napkin maths I'd say a laptop maybe uses 150 kwh a year. Google seems to suggest a heavily used machine draws about 30% more power than an idling one, so over a year your laptop going ham is still only a fraction of a single bitcoin transaction.
It does seem that the comparison I made is apples & elephants, but I do think that the point still kinda stands. Unoptimized monstrosities like Slack waste a lot of electricity, decrease producitivity and make life miserable.
Energy is spent securing the chain, not executing transactions.
It can't because the entire uniqueness of crypto-currencies lies in their decentralisation. If you make an arbitrary large block you'll increase the running costs of the node, which will centralise the control of the chain. If you have a bazillion transactions on a block you've just reinvented a bank, because the integrity of countless of transactions then lies with one institution outside of the actual chain, and the only one who'll run the node is someone with a huge data-center
I'd honestly help with a Slack rewrite in a less wasteful technology for that reason alone: let people's laptops sit quiet!
fwiw, this is how the original Slack Mac app worked and it sucked. We had to tell users to upgrade their OS so that their app worked, because NSWebView (and WKWebView) are tied to the OS release. If their computer was too old, telling a customer to Buy a new Mac is a pretty terrible experience.
Yes not sure where they got the 1.2x ratio in their favor, although if we're only rounding to the nearest unit the official slack uses 220MB, not 200.
TBF the machine has plenty of memory available, so trading some memory for less CPU time, less GPU time, better idling and faster startup seems… a pretty good tradeoff.
The one thing I'm doubtful of is whether the official slack application really does nothing but wrap the webapp with no additional functions?
On my MacBookAir with 4GB of RAM, Gmail+GCalendar+Slack+GChat+Trello+Docs is enough to put memory pressure on the system. Gmail+Calendar alone end up taking up 1.5-2GB after a while. No respect for memory.
It is worth noting that the official Slack app has gotten massively more memory efficient about a 1.5y ago, its bad reputation comes from the time before that (when it easily used more than 1GB of RAM). (I think it still has other performance issues, but they aren't as big anymore, it is doing quite well IMO)
Having said that I'm working on improving memory consumption in Shrugs.app - it is a tentpole feature planned for v1.1 (it'll take some time until this will be ready though).
Any performance differences between the two approaches should essentially boil down to the Chrome vs Safari differences.
I'll keep an eye on it. I have no problems buying after it gets good enough. Thanks for your work.
It can also function as a client for Discord. A shame that it is closed-source though.
In particular if your slack channels are heavy users of actions then you'll have problems - the buttons often don't work and the layouts are messed up.
On the plus side it doesn't animate anything, which is a huge win.
In OP's context you're also using a Qt application of macos, which is as much a match made in heaven as using x11 applications on macos (very much not).
If you have to use Slack for work that's one thing. But people chosing to use Discord is just sad and unfortunate. It's just another Facebook situation wherein they are the product and in a few years it'll become unignorable.
Slack is less obvious. Slack boils the frog like they did with IRC bridges and has weird nationalistic restrictions re: USA enemies wherein, say, if the client was developed in Iran then it'll get banned. But it's a lot better odds than Discord where no third party clients are allowed specifically.
Er, no, they aren't. Ripcord is 4 years old. I have no idea what you're talking about.
> Slack boils the frog like they did with IRC bridges and has weird nationalistic restrictions re: USA enemies wherein
Uhhhh
> But it's a lot better odds than Discord where no third party clients are allowed specifically.
Nope, this isn't listed anywhere in their rules.
Shareware was about leveraging the now defunct sneakernet via physical medium such as floppies and making it ok to copy software and give it to friends on the premise people who like it will feel morally obligated to pay a modest fee.
The second part is still there but the first part is dead, long dead.
I feel like you need to push this social capital and exchange back into the model somehow to bring it forward but not through nagware or review feelers. Something more real and unprompted
I was intrigued because slack used to have APIs and and IRC proxy, and I was wondering if the author has used some kind of weird way to connect to slack and impersonate an user.
However... The latest versions of Windows 10 now use the newest Chromium based Edge as the native web view. So the need to use Electron is slowly going away.
You can't patch webviews nor change their behavior.
Also windows webview2 is very alpha and currently not useful. No v8 access, very little configurability, and its not using any less memory. It will be years before it's ready.
Chromium itself should have impliments webviews long ago.
This doesn’t logically follow?
- How does using 2 or 3 different rendering engines solve the problem for the developer? They have to now put in the extra effort and QA for each engine/platform.
- So at the time Electron was founded, it might have made more sense to ship Webkit on Windows. But the developers instead chose to plug in all the extras from Chrome (?). Might have been a better choice to build directly on raw Webkit.
- Even if a Hello World app was 200mb shipped and took 500mb of ram to run, it's still on the developers to get it to a state where it's an order of magnitude worse once it gets to do something useful...
I'm still torn on the issue. I firmly believe going full native is the most user-friendly option, but I appreciate the increased cost and complexity of development, testing, support. But using an embedded web view of any kind feels incredibly, incredibly cheap. Especially for companies with the scale and budgets of Github or Slack.
The one on my system updates pretty frequently, probably more often than WebKit updates on my Mac.
> How does using 2 or 3 different rendering engines solve the problem for the developer? They have to now put in the extra effort and QA for each engine/platform.
They’re already doing this for the website.
Maybe. Your Linux distro of choice is a single data point in a sea of headaches. https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-secu...
> They’re already doing this for the website.
Yes, but the effort testing the app on browser A, on platform X, doesn't directly benefit the testing of the desktop app on platform X. From QA standpoint they are separate entities, and while there will be shared bugs, there will also be unique bugs, which cascades back to development, design, perhaps even business decisions.
But with separate browser engines for the desktop app on platforms X, Y, Z you will now have more variance in bugs between these platforms. Whether there's standalone web browsers involved as well is not as huge of a factor - they will have their own share of unique bugs.
[1] - https://pointlessramblings.com/posts/why-always-electron/
I’m now curious how multi[1] compares to Fluid[2]. I haven’t used it in a while, but that app used to be present on all my installs.
Can’t remember what happened that I stopped using it.
Fluid was proprietary commercial software (and the author was also a real jerk).
The license seems ambiguous though because there's no LICENSE file in the repo and the website has copy about requiring a paid license to use the software; the only place GPLv3 is mentioned is in the README. I opened an issue requesting clarification.
Edit: no idea what the software mentioned above does, just correcting a common misconception.
If I'm incorrectly co-opting some open source nomenclature, I'd love if someone could let me know. As I said in the issue linked above, I do need to update the purchase website to bring that language more inline with what's on GitHub.
It's perfectly legit. You can find the sources for these items elsewhere on the web but the hassle and security implications just aren't worth it.
I had some positive interactions with the author. He went out of his way to explain how to do something that wasn't officially supported (how to include my own user scripts).
Nothing major. But way better support than I ever expected for a $5(!) desktop app.
Nit: the plural of axis is axes. (Due to its Greek etymology I think? https://en.wiktionary.org/wiki/axis) I'd probably use "metrics" though.
https://gunnarpeipman.com/blazor-on-desktop-webwindow-experi...
All Catalyst apps on Mac that I've tried (including Apple's own Home) feel about as badly out-of-place as anything Electron.