Introduction

[00:00:00]
>> We're gonna talk about Electron today. What does that mean? We're gonna take the fact that we're web developers and ignore that reality for a moment. And just realize that in the modern era, being a JavaScript developer means you can do whatever you want, right? It means you could [LAUGH] hack on some hardware, it means that you can build desktop applications, right?

[00:00:22]
That's one of the great things about being a front end engineer in the modern era. So today, we're gonna talk a lot about building full on desktop applications. And one of the things I think a lot about is, at one point in my life, you had to show a slide which is like, and here's the one or two applications that are really reels that are built on top of Electron.

[00:00:47]
I looked at my dock the other day and realized that almost all of the applications that I use on a daily basis, many of them happen to be Electron applications, arguably Chrome as well. But these days between Visual Studio Code, Obsidian, which is a note-taking application, the GitHub client, unsurprisingly, is an Electron application.

[00:01:14]
Figma, Slack, by definition, you probably use at least one Electron app daily, right? And so today, what we're gonna do is we're gonna talk a little bit about how to build those. Right, and there are some conceptual pieces to think about, right, but once you kinda wrap your head around the model, right, the actual full range of possibility is incredibly exciting.

[00:01:44]
And at the end of the day, Electron is really just kind of the marriage of two things, right? A full Node.js runtime as well as a full Chromium based runtime. And so on one hand you've got chromium. And the nice part too is Electron comes bundled with both of these, right?

[00:02:06]
And so when you go and you package and you build your Electron application, you don't have to worry about are they running Node 16? Are they running Node 20? Whatever version build they're running, cuz you would package your own version of Node and you don't necessarily have to worry about browser support and capabilities, and something, something Safari right?

[00:02:25]
Because you are also packaging your own Chromium runtime. And so as I said before, Electron is basically kind of just bringing together a version of Chromium, a version of Node, and then creating a bunch of bridges between those two processes to allow you to kind of both have the full access of a Node.js environment slash what we might think of a lot of times as a server.

[00:02:49]
As well as, everything that comes in the browser, most notably the DOM, the runtime engine, all the web APIs as well. So from Chromium, you get full HTML5 support, GPU acceleration, Blink, V8, which you also get on the Node side, and all of the modern web APIs. And like I said, since you know exactly what version of Chromium you're using cuz you chose it when you chose the version of Electron, you can kind of rest confidently on what features you can and cannot rely on as well.

[00:03:17]
And then on the other side, you've got all of Node.js where, not only do you have full file system access and all the things you have normally from Node. You also can compile native module. So if you look at a lot of databases, the drivers are perhaps C/C++, you can also compile those and bundle those into your app as well.

[00:03:36]
So you can ship your app with a Rust module as well if you need to optimize for performance. And so you don't have these limitations on what goes on the server, what goes on the client. There's some amount of that to think about, but mostly predominantly for security reasons, because the part that your users interact with, you probably wanna have at least a little bit of a wall between that and the part that can write to their file system.

[00:04:01]
But other than that, you actually have both of these things together, which kinda opens up a realm of possibilities that are a lot bigger than either one independently, right? It's like the whole is greater than the sum of its parts. I think that's definitely true with Electron. And like I said, at this point we are far enough in to the Electron era, if you will, to know that, can you build desktop quality apps that feel at home?

[00:04:34]
I spend most of my life in Visual Studio Code, right? And unfortunately, as a manager, I spent a lot of my life in Slack as well. We don't talk about that part. But a lot of my life is in VS Code, which is an Electron app. My note taking app, Obsidian, Electron app, so on and so forth, right?

[00:04:50]
And once we kind of wrap our heads around the process model and the nuances of the OS integration, then the actual ability for you to build desktop applications for your need. Whether it's a direct business use case or, honestly, I wish I had this convenience app that I could just drag an image in and get it to do the right thing that I use over and over and over again.

[00:05:12]
The ability to kinda build these things and package them up and use them is I think really great as well. So we're gonna build a few little apps today. We've got just kind of a markdown rendering app. And I think this does a really great job of demoing a lot of the kind of interesting pieces of an Electron app, which is it can read from the file system.

[00:05:36]
It can write to the file system, right? It can export things. It can show that file in either Finder or Windows Explorer, depending on what operating system you're using, right? It can then also open that markdown file in the default application that the OS knows about, things that might be a lot harder to do in the browser are kind of just natural and easy inside of an Electron app.

[00:05:56]
So I think it's a really great way to kinda see. We can trigger native file dialogs, we can scope which kinda file and things along those lines, Marc.
>> What if you wanted a desktop app as well as the browser app with the single code base. Have you seen that before?

[00:06:12]
>> Yeah, I mean, you can theoretically, and when we get to the build tool, things. When we start building some of these apps using the Electron Forge, you'll see kind of that you have a lot of the browser code, you do separate from the main process code. You're not kinda jamming them all in together.

[00:06:27]
There is a little dance between the two. Would you have to do some work to figure out, making the actual API calls versus maybe talking directly. Yeah, but you could give yourself the abstractions, but the kind of code, especially when we look at Electron Forge. You might use Vite, for instance, or Vite, as they say, or Webpack or what have you, to build all the client-side assets.

[00:06:50]
You do need to do a little bit more of a mono repo dance, and you need to build yourself some of the abstractions, but there's nothing stopping you because it's just Chromium and Node, right? It's just some affordances you might give yourself in the code. And the nice part is, back in the day, also known as the last time we did this workshop, you could do a lot of just regular Node calls in the browser context, which theoretically would make it very hard to ship it to the browser.

[00:07:19]
Turns out that was not the best security posture in the world. And so can you go around that and circumvent and do that still? You absolutely can. Am I gonna show you how to do insecure things that you shouldn't do? I will allude to it, but I will not be doing that, right?

[00:07:34]
And so insofar that we do try to separate a lot of the UI piece from the Node piece, but still have that kind of integration point over this module in Electron called the context bridge, we already have that kind of separation of concerns. But there's nothing stopping you from having a version where you can export a client side UI piece, and then also having the full Electron piece.

[00:07:55]
A lot of it just becomes, how you set up a mono repo? And how do you make sure that you've given yourself an abstraction where you can swap in making the API calls versus whatever, right? But theoretically, you could also just spin up a server, so on and so forth.

[00:08:10]
Or maybe it's an application that lives, but then talks to a remote server as well. Which is true probably if you think of the GitHub application, Figma, so on and so forth, that they are by definition, right, just progressively enhancing the web experience with additional capabilities. So absolutely.

[00:08:30]
Yep, so we've got a markdown application. And then we also have, depending on what we want, we can always build the classic to-do list. And then the ability to build actual menu bar and system tray applications, depending on your operating system, right? So system tray for Windows, menu bar for MacOS, and kind of build applications like places that you normally don't find web views all the time, right?

[00:08:54]
i mean, you do because we live in a world where there's Electron apps all over the place. But generally speaking, the ability to kind of create all sorts of different experiences above and beyond what you might have in the browser as well. So kind of the high level we're gonna cover, obviously, like I said, and I will say this probably two more times before we really jump into it, is the biggest part of understanding and grokking how to build an Electron app is this dance between the main process and the render process.

[00:09:21]
We'll talk about the Electron process model in a moment. But in terms of the high level, what we wanna kind of talk about today is, again, triggering these native file system dialogues for both saving and opening files, and then accessing the file system accordingly. Some of the operating system level integration that you might leverage to make your app feel a little bit more at home, right?

[00:09:48]
We will skirt around the really, really OS specific stuff because you might be on a Linux machine or a Windows machine or a MacOS machine. We'll do a few little nods that make it feel correct, but you do everything from have touchbar integration on the 2016 to, whatever, 2019 Macbook pros, to the tiles in Windows 10 and 11, so on and so forth.

[00:10:15]
Outside of just the very first foray, as we showed just a high level look at Electron, we're just gonna use TypeScript out of the box. One, because it's super easy. Two, because that way we've solved that question right then and there. If you don't wanna use TypeScript, you can just change any of the file extensions to .js, but you will see that it is shockingly little TypeScript that I have to write to get everything working, right?

[00:10:47]
And also as someone live coding, having a type checker catch my booboos before I squint at my screen wondering why something's not working is beneficial to me. We will talk a little bit about, in the first example, we'll just do vanilla JavaScript, or I guess vanilla TypeScript, right?

[00:11:03]
But in the second example, just to kinda show how easy it is to integrate a front end framework, we'll grab React because it's the lingua franca. And we'll kinda do the second one using React just to show that integrating any of these front end frameworks is super easy, right?

[00:11:17]
The goal of our time together is to at least make sure that there's not a lot of huge unanswered questions. We'll talk about some of the other features, like accessing clipboard, triggering notifications, registering a global shortcut so you can activate your app from anywhere with a keystroke. Again, putting the menu bar in the system tray and then what it might look to use some native modules if need be, as well, right?

[00:11:44]
So we kind of have all of those different bullets that we'll hit along the way. The only thing that we're really not gonna focus on very deeply is the kinda packaging signing out cuz that's very OS specific. In a lot of cases, to just package the app, Electron Forge makes that super simply, just npm run package.

[00:12:03]
To get the Apple developer certs designed to put in the app store is $100 outlay that I'm not gonna ask everyone to do. But generally speaking, to build and develop the apps is kind of where we're gonna focus our time and energy today, rather than getting to the very nuance that is operating specific and involves laying out possibly $100 or more.