Electron, v3

Main Process & Renderer Overview

Steve Kinney

Steve Kinney

Electron, v3

Check out a free preview of the full Electron, v3 course

The "Main Process & Renderer Overview" Lesson is part of the full, Electron, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Steve discusses handling communication between the main and renderer processes. Newer versions of Node.js security differences and preload scripts are also covered in this segment.


Transcript from the "Main Process & Renderer Overview" Lesson

>> 90% of the battle is trying to just wrap our heads around the dance between the two process models, right? And I would say that maybe five or six years ago, four years ago, that was maybe 50% of the battle. That said, there is a little bit more security posture than there was back then and a lot more protecting bad actors, so on and so forth.

When you can run all of Node in the browser, that's fine and great until you start pulling in a third party script off a CDN or even your own script off of a CDN. It could just say like fs.writeFile or something along those lines, right? So you can circumvent all of the security things and you shouldn't and I'm not gonna talk that much about it, Marc.

>> Does it handle auto updates? Maybe you answered it, but missed it.
>> So you can handle auto updates. You need to be running a server that has those updates, right? So what they're gonna talk about is regular Electron out of the box, it's kind of agnostic around that.

Electron Forge, which is, I would say, not dissimilar to Create React app or what have you for Electron and it wires up like Webpack and all of these things. Does support Squirrel, which is kind of the app updater you've seen and loved throughout your entire life. You do need to wire up a server that pushes out those updates.

There are some libraries that will use GitHub actions and GitHub releases to try to help you with it. Some of that becomes specific to how you wanna release it. The other option for all these things, of course, is there is nothing stopping you. There is the built-in capabilities for both in-app purchases in, for instance, the Mac App Store, as well as using the Mac App Store Writ Large for pushing out your updates.

So those are all possible and doable. And they do involve standing up at least a server to say what the most recent update is and stuff along those lines. And if you use Electron Forge, the ability to check for those updates, download those updates is built-in, right? You just need to set up the server at that point, so yes.

So yeah, like I said, 90% of the battle when building Electron applications, and 90% of our focus today is going to be just understanding how to communicate between these processes. But I think if we're gonna do that, we should talk about the two, right? And so I kind of said, hey, we've got Node and we've got Chromium, right?

The term of art in Electron is the main process versus the renderer processes, right? And ideally, that should probably already fit into a certain mental model on which one is Node and which one is the browser, right? And also, you can see when I said the main process versus renderer processes, you can get a sense of how many of each there are.

Now, you don't necessarily need more than one, right, but you might have more than one, right? And so for most of apps we're gonna build today, we're gonna keep it relatively simple, which is we got a main process that spins up a renderer process. But there's nothing stopping you if you think about VS Code, where you might have multiple windows open, right, that has multiple renderer processes.

In the same way that in Chrome, every single one of your tabs is its own process, right? And they're isolated from the other processes. That is true in your Electron app as well. You could spin up multiple, yeah, you can have multiple different files open. You could do any of these things.

They are essentially separate processes and they're kind of the main process is what ties them all together. The main process can spin up these, they can take them down, they can also close themselves, so on and so forth. The main process is that it is not wrong to think about it like a server, right?

It is that model that we have as front end engineers of our client side code, which maybe is running across many of our users' browsers. Yes, I understand how microservices work, or one server, right, that they talk to, right? That model, that mental framework, is not wrong when thinking about Electron apps.

I think it's a decent heuristic in this case. Like I said before, back in the day, this is a screenshot from the last version of this course, you could literally just pull in Node in the renderer process. Can you do this? Yes, do you have to opt into it since Electron 12?

And to be clear, at the time of this recording, we're on Electron 26. One thing I should note, though, is that the numbers go very fast nowadays, not because there are breaking changes, that it's SemVer per se. It is based on a cadence of Chromium and Node releases, right?

And so in a lot of cases, if you go from Node 18 to 20 per se, there might not be any breaking changes in the Electron API. You're just bumping up a version of Node or a version of Chromium or something along those lines. And so there's a rhythm and a cadence to that.

So I think for a while, there was forever before you hit Electron 1, and then years before Electron 2. Now it's kind of on that you don't necessarily think, I mean, you do think a little about what version of Node, but it is less of a churn on that one.

So we are on at the time of this recording Electron 26, which came out earlier this week. From 12 forward, just letting you do whatever you wanted to someone's computer from a browser context that could load arbitrary code is now frowned upon. I will make one allusion at one point on how to opt out of that, and then I will never talk about it again because it's a bad idea.

And it's better to just learn how to do it correctly. But if it's a quick and dirty thing you're just running on your own, sure, go for it, have at it. But nowadays, we do need to figure out how to talk to the main process back and forth.

And so IPC or inter-process communication is gonna be the big way that we do that over our time together, and we'll be doing it a lot. There's various different ways to interact with it. The other kind of new thing since the last time we talked about Electron together is these preloaded scripts.

Before, there was just the main process and the renderer process. In terms of process model, that's totally true, right? But you do need a little help getting some stuff from the main process into the browser context. So you have this preload script, which exists in the renderer process, right?

And it's in a place that kind of before the DOM loads, before you load in any third party scripts, before you do anything that might in any way interact with the outside world. A place to kinda set up an allow list, what different kind of interactions you wanna have with the main process.

And then that is kind of you can expose just the very few things. It's kind of the regular security principle of least access, right? So as much as you need, as little as you can get away with. So you're gonna expose the very small set of things that your renderer processes need access to in order to talk to the main process, right?

Those happen in a preload script. That is technically part of the renderer process, so it's not an additional process beyond that. It is just like a one last stop before we go into what is normally a full browser environment, right? And we get a bunch of ways to just make sure that we are isolating just what you need, and then those are exposed.

And then we use those to communicate back and forth with the main process.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now