Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Electron Pro-Tips

Ana Betts
November 05, 2018

Electron Pro-Tips

Electron is an awesome new framework from the folks at GitHub for writing Desktop Applications using Web Technologies, that many successful companies such as Microsoft, Slack, Facebook, and others have used in order to ship great experiences to their users. In this session, learn some common pitfalls that many developers new to Electron fall into, especially for people with a web background who are new to Desktop development, as well as learn some great new Tricks and libraries that you can use to make great app experiences for your users.

Presented at QCon SF

Ana Betts

November 05, 2018
Tweet

More Decks by Ana Betts

Other Decks in Programming

Transcript

  1. HI.

  2. Every conversation I've ever had about Electron memory usage: Them:

    IM SO MAD ABOUT MEMORY USAGE Me: I understand! So, what's the "Commit Charge" say in Task Manager? That's the percentage of RAM that is actually in-use. Them: Oh, it's 40%.
  3. ...but on the other hand, as Electron Developers, we've got

    great tools to do something about this, so we should!
  4. LOAD LESS STUFF ▸ Lots and Lots of DOM Elements

    ▸ Especially Images and Long Scrollable Areas ▸ JS Heap Memory
  5. LOAD LESS STUFF ▸ Libraries that you load in your

    app never get unloaded ▸ Bad for startup performance and for memory usage!
  6. NO

  7. WHAT THE MAIN PROCESS IS NOT ▸ "The Backend" ▸

    "A Background Thread" ▸ "The Server"
  8. THE MAIN PROCESS IS FOR ORCHESTRATION Running code in the

    main process slows everything else down Chromium uses IPC internally to do things, such as signaling window size changes So when the main thread is busy, your app glitches!
  9. THE MAIN PROCESS IS FOR ORCHESTRATION ipc.send is asynchronous which

    is Better, but not enough! The main process can still do a lot of work as a result of ipc.send, and block stuff
  10. THE MAIN PROCESS IS FOR ORCHESTRATION The main process should

    really only be used to tell other processes what to do ▸ Sending information between windows ▸ Signalling menu items and dock events ▸ Crash reporting and other APIs that only work in the main process
  11. ELECTRON-REMOTE, DOING WORK FROM THE MAIN PROCESS import { createProxyForRemote

    } from 'electron-remote'; // myWindowJs is now a proxy object // for myWindow's `window` global object const myWindowJs = createProxyForRemote(myWindow); // Functions suffixed with _get // will read a value userAgent = await myWindowJs.navigator.userAgent_get()
  12. ELECTRON-REMOTE, TASKPOOL import { requireTaskPool } from 'electron-remote'; const myCoolModule

    = requireTaskPool( require.resolve('./my-cool-module')); // This method will run synchronously, // but in a background BrowserWindow process // so that your app will not block let result = await myCoolModule.calculateDigitsOfPi(100000);
  13. REQUESTIDLECALLBACK IS SUPER COOL Like setTimeout but only runs once

    the UI is no longer busy The callback allows you to repeatedly schedule requestIdleCallback to do work in a loop Writing App Data in the background is a great place to use requestIdleCallback
  14. JUST MAKE AN HTML PAGE Putting a website into an

    Electron frame is easy, but not great for Users Offline Mode is way easier Your app will start Really Fast Starting with a Desktop Mindset will make your app feel like an app
  15. HTML PAGES ARE MORE SECURE Designing a hybrid app is

    Very Security Sensitive, so that you don't accidentally give Desktop Powers™ to remote content When all of the code for your app is local, you remove this possibility altogether XSS is still extremely important to watch out for!
  16. DON'T RUN WEB SERVERS IN YOUR APP ...cause like, what

    if more than one user uses your app? Your web service now a great way to move data between different users If you run as Admin, it's now a great way to local EoP ...or if you're really unlucky, have arbitrary websites run Desktop code
  17. USE ELECTRON-FORGE electron-forge handles all of the things you might

    want to use Express or Webpack for, like Hot Module Reload It handles Babel/TypeScript/LESS/Sass via hooking Electron and compiling on-the-fly during development electron-forge does all of the packaging and compilation work too
  18. BUT I LIKE WEBPACK! Trying to interact with Electron itself

    gets Weird because now there are two separate module systems Native node modules are a pain with Webpack, both at runtime and on the build side Packaging becomes way more complex
  19. ¯\_(ϑ)_/¯ There's no easy way to call macOS APIs from

    Electron, you have to write a Native Node Module. You can do very simple things with node-ffi, but more complicated things will lead to Segfault City