I know that the answer circles around developer productivity, but to me the "state of the art" still feels off. If I already have a browser engine built into my operating system, why should application developers ship a different one for use with their "native" app?Įspecially if that application is a minimal wrapper for an existing web application. I'm neither a performance engineer nor a desktop application engineer, but the Slack Lite approach just feels right to me. Ultimately, the numbers above are a proxy for the Chrome vs. Slack Lite is a Multi app, which means it's using a WebKit WebView behind the scenes. I suspect you could get similar numbers by applying this Slack Lite approach to any Electron-based macOS app. It's time to come clean: the performance differences described in this post are not really inherent to Slack Lite. In practice, the memory difference is negligible. I retook the screenshots between drafts of this post, and I suspect that's how I introduced that error.
In the Activity Monitor screenshots below, you can see the raw numbers (Slack Lite's processes are highlighted):Įdit: this post previously claimed that Slack Lite used 1.2x less memory, but the numbers in the screenshots do not support that claim. Slack Lite uses Slack's official UI, so it's visually indistinguishable from the official client.Įven so, Slack Lite uses 5x fewer threads, 3.5x less time to startup, and significantly less CPU. I recently created a macOS app called Slack Lite, which beats Slack's desktop app across a few performance metrics.
Creating a Slack app that uses fewer resources Creating a Slack app that uses fewer resources August 3, 2020
0 kommentar(er)
