#SLACK CLIENT MOVE FROM ELECTRON FULL#
That makes it easy to load the node process inside a window instead of in the background, allowing full access to Chrome's developer tools for debugging. That's right! Once I got the background process working, I realized that we have all of Chrome's developer tools sitting right there, and the ability to create a window with node integration. Wait a second, what's with the last point? It runs the server inside a window in development?
#SLACK CLIENT MOVE FROM ELECTRON HOW TO#
In order to encourage people to create truly local Electron apps, I created electron-with-server-example to demonstrate how to set all this up. This project will still be helpful to you to learn how to set it up. It's the only place where it's safe to access them. See the next section for all the crazy things you're allowed to do.Įven if your app is heavily web-based, you might need a background process if you need access to node APIs. It also turns that that using a background server in Electron also provides an extraordinary developer experience. Moving things into the background process also frees up the UI to be as responsive as possible. The best thing to do is to use something like SQLite which is already highly optimized for this sort of stuff (seriously, just use SQLite). The background server can optimize its memory usage by only loading the appropriate data into memory as needed. I plan on rewriting one of the critical and memory-intensive pieces in Rust which should significantly reduce memory usage. Other apps like Notion and Airtable sit around 400-600MB, so we're still beating that by a good bit.Īnd that's before I've really optimized anything. Slack is an outlier though, and Electron gets too much flack for its specific problems. That's better than the 1371MB that Slack is current taking up on my machine. That's a total of 239.1MB of memory when the app is resting (it will go up depending on the page, but this is the baseline). For a data-heavy app, the results speak for themselves: It's 100% local, and syncing across devices is an optional feature that happens on the side. This is how I built Actual, a personal finance manager. This ignores other benefits like your app working when offline, but that's for another post. Usually web apps need to build up a lot of local state in order to have good performance, and this is one source of memory bloat.
Since all your data is available instantly, the client doesn't have to be concerned about caching so much. That right there will be a huge speed increase. You never have to wait for data to load over the network, it loads from a local data source instead. The less you rely on the cloud, and the more powerful you make your background process, the more you can reap these benefits: The "secret" is to do the bulk of your work locally in a background process. What if I told you there's a secret that automatically minimizes these problems? The bigger problems (memory hungry and sluggish) can be managed in user-land, but it takes a lot of care to do so. Some of Electron's problems (large file size, slower boot up time) are inherent in the architecture and need to be solved at a lower-level. We don't want to accept Electron's bloat though. I won't spend time arguing for Electron, but the incentives are obviously there given the success of it. It's hard enough to build good apps on web, why the heck are we bringing the web to desktop and causing even more problems? This feeling is validated when looking at the apps on your machine - they eat up memory, boot slowly, and aren't very responsive. The idea that an app includes an entire copy of the Chrome web browser sounds ridiculous.