I can write a long list of reasons why Electron is bad for performance. Having read this blog post though, I can see none of those reasons apply to Slack. The

I can write a long list of reasons why Electron is bad for performance. Having read this blog post though, I can see none of those reasons apply to Slack. The kind of performance optimizations that they're calling "a radically reimagined desktop client architecture," are actually basic engineering practices that apply equally to all development platforms. > Using a CDN-cached HTML file, a persisted Redux store, and a Service Worker, we were able to boot a stripped-down version of the client in less than a second None of these are specific to the browser or Electron. For example: > a CDN-cached HTML file Assuming the HTML file simply points to the styles and the scripts (i.e. no content-related markup), I am surprised that they weren't already caching it on the client and the server. Without caching the HTML file, upon boot, everything has to wait until a meaningful chunk of that file is loaded. What happens in a regular native setup is that what functions as that minimal HTML file is already bundled into the app's package and is always read from disk. > a persisted Redux store There is nothing radical about this. Storing part of the application state on disk and re-hydrating upon reload is standard practice. And again, not specific to the browser or Electron. On iOS (and I'm sure on Android), models can be decorated with a persist/re-hydration mechanism. In fact, having this redux-style single-source-of-truth state object makes it even easier to serialize the state to disk and read it back. In fact, not a single optimization mentioned in the article is specific to the browser or Electron. Slack is not slow because of Electron. Slack is slow because of Slack. They could've written it in assembly, and without these basic optimizations, it wouldn't have run much faster. ps. I'm not trying to bash on the engineering team though. I'm certain they had other priorities, being a hyper growth startup and all. I cannot say that I would've done differently under those same constraints.