Electron and Desktop App Engineering with Shelley Vohr

0:00Electron is a framework for building cross-platform desktop applications using web technologies like JavaScript, HTML, and CSS. It allows developers to package web apps with a native-like experience by bundling them with a Chromium browser and a Node.js runtime. Electron is widely used for apps like VS Code, Discord, and Slack because it enables a single code base to run on Windows, macOS, and Linux. Shelley Vore is a principal software engineer at Microsoft where she works on Electron. She joins the podcast with Josh Goldberg to talk about her work on the Electron project. This episode is hosted by Josh Goldberg, an independent full-time open-source developer.

0:40Josh works on projects in the TypeScript ecosystem, most notably TypeScript ES Slint, the tooling that enables ES Slint and Prettier to run on TypeScript code. Josh is also the author of the O 'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on Blue Sky, Mastodon, Twitter, Twitch, YouTube, and.com as Joshua K. Goldberg.

1:19Shelly, welcome to Software Engineering Daily. Hello. Thank you for having me. Oh, well, thanks for coming on. We're really excited. You've been around on GitHub and in the web dev and C++ space for quite a while. Your name pops up on a lot of commits on GitHub. But before we get into all that and Electron, can you tell us who you are, how you got into coding? Yeah, absolutely. So I, as a kid, was always pretty interested in the way that stuff worked. So I really liked programming my calculator when I was in high school. And then when I got my first computer, I spent a fair amount of time trying to figure out how it worked, what I could get it to do, different ways that I could get it to not work.

1:58And then at a certain point, I realized that there was such a thing as programming languages that could interface with Mac. And basically, you know, felt like the horizons opened up as soon as I realized that I could make computers work in new and novel ways that I actually wanted to beyond just how they worked. Could I make it like work within the bounds of what I thought existed? And then spent a bit of time doing that. I took a couple of computer science classes in high school and then realized pretty quickly that it was a career that I wanted. I basically see software engineering as, I don't know, basically just being able to solve fun, interesting puzzles that challenge the way that I see things, challenge my brain.

2:41And yeah. That sounds great. Was it by any chance a TI-84 calculator that you were programming? It was indeed. Yes. Those were classic. Okay. So at a high school, you were taking software engineering as a career track. What was your first job experience? So after freshman year of college, basically cold emailed a million companies, mostly in the Boston area, which is where my family is based to see if anyone would take me on very little resume, a couple of computer science classes to show for it and ended up getting lucky and got a really great internship with a small company called Embedly based out of North Boston.

3:20It was a little startup, but it was like a really, really good platform for showing me what production software looked like. It was small in a way that everyone had to wear a lot of hats, which ended up being really good for me because it forced me to learn a lot of things really quickly. And also there weren't always people around to help me figure out what happened when things went wrong, which I think really also helped me figure out how to operate in that kind of environment. After that, I basically tried to get a software engineering internship every summer and also did one during the year.

3:51And ultimately, I think that really set me up well for what I ended up doing post-college. And what did you end up doing post-college? So actually, in retrospect, this is a little wild. So I interned at GitHub the summer before I graduated from college. And I finished my software engineering internship actually about four to five weeks early. And then I had been interested in Atom and Electron for a while. And I asked the manager if it would be possible for me to basically like temp on his team, just to see if I could, you know, make an impact last couple weeks, get to know some folks, branch out of what I've been doing in my internship so far.

4:30And he said yes. And that ended up going well enough that I contracted and worked essentially full time my whole senior year of college and then straight around the team as soon as I graduated. To recap, could you tell us what are Atom and Electron and how do those play into what is now called VS Code? Ah, yes. So Electron and Atom are both projects that came out of GitHub originally. A lot of people actually don't know this, but Atom came first. Electron was essentially made in order to enable Atom existing. Electron is a JavaScript framework that enables developers to use web technologies to write desktop apps on different operating systems and have them all work similarly across them.

5:12And Adam is an editor that built on that. That's like one of the canonical examples of an Electron app. Yes, it has since been sunset, but it was basically the first major use case for Electron. Originally, they were part of the same team. And then later, Electron was split out into its own team. Once the team realized that there was quite a lot of interest in the use cases and the opportunities that Electron enabled. So you're not a JavaScript developer, nor are you a pure C++ developer. What are you? That's a great question that I have struggled to answer a lot over the years, actually. Probably the closest thing to the skill set of people that work on Electron is browser engineering.

5:49So essentially, Electron is built by pasting together Node, File System, Access, Networking, and then Chromium, which enables you to create UIs. and then quite a lot of glue paste in between those two things to enable them to work together. But essentially that means that on any given day, I could be writing TypeScript, JavaScript, Objective-C, C++, perhaps some Python. Basically just whatever the day throws at me, it's hard to prepare for or expect or know, but it's really kind of a hybrid, yeah, browser engineering job. I'm not really sure if there's a better way to describe it. I always laugh a little when people are like, are you front-end or back-end?

6:27I'm like, I don't know with that. I have no idea. Both? Neither? Secret third thing? Yeah, a lot of people view there being a single linear access from front to back or back to front. But you and I, we work not really in that access. There's a separate access of dev tooling, you know, from the machine to what people actually interact with. So do you see yourself as even aligning on the front to back end? Are you some different spectrum? Yeah, I think I would agree with you that it's not really like my job doesn't really exist along that axis because I think that like that presupposes that you work somewhere on the web in a browser or like that the product you work on is ultimately like a web product per se and I think at least for me like that's just never really like a framework that's applied yeah so before we get into what you do with Electron and how one becomes a principal engineer in that world I want to talk a little bit about the how Electron works because it's actually kind of fascinating.

7:24Is there a 30 second overview or one to two minute overview that you're comfortable giving of this giant project that you work on? I will do my best. So as I kind of originally said, Electron is a framework that essentially enables you to write desktop apps using web technologies. However, it is actually ultimately a fair amount more complicated than that. Electron's proposition is essentially to mix and match native and web as you see fit and as your use cases demand. So for example, you could, you know, use Chromium's UI capabilities to write a desktop app where, you know, everything you're kind of looking at is JavaScript, CSS, HTML, and then, you know, you have a bunch of native node add-ons that you farm out to different native libraries, capabilities that you wouldn't be able to access using either to enable really kind of a whole broad range of use cases that were pretty hard to access and are pretty hard to implement before Electron came along in a way that was accessible to broader teams of devs with more web-based backgrounds.

8:26Yeah, a lot of folks, when they think of a JavaScript or TypeScript app development cycle for something like an editor, and if you want to build it in that type of stack, the first reaction is, oh, why don't you build it in the browser? But we're describing file system access being a native app. That's a different style of use case than just open a new tab in Chrome, right? Yeah. So a small example is Apple maintains a couple of APIs that are all in Swift. So if you were writing a web app for a browser, there's really no way you could access any of those APIs. But using Electron, you could write a native node add-on that was written in Swift and then expose it up into JavaScript.

9:01And then using your app, call out to the Swift only APIs and then leverage them within your app. Okay. Let's say I have an app built in Electron, like a VS Code, how does that get built and distributed to users, given that you have to support Linux, Windows, Mac, and all sorts of other platforms? So there's a fair amount of tooling that exists in the ecosystem for doing those things, depending on what it is that you need. But yeah, at its core, the general Electron team maintains a few of them. Electron Forge is one. That's typically the one that we've maintained more effectively, although there's several other lovely libraries in the ecosystem that we try to support where we can.

9:35You touched on tooling, and then because this is audio only, I want to say that there is this wry kind of joyous look on your face that came up. You work in tools day to day. So one must imagine that the tooling built around Electron, built around VS Code is rather impressive. How do you support your work? Are there any tools you want to shout out in particular? This is a great question. As someone who has unfortunately spent so much time in Electron bot land over the years, fundamentally, and actually, I also think this is something that I think most people wouldn't know is that the electron team is quite small.

10:05I think total governance is 25 ish core engineering less, but electrons tooling is essentially a small enterprise level tooling. So almost everything that we do, we have thought about what automation support we need, what number of developer hours that we could save with it. We've done those metrics. We've built automation to allow us to automate almost all permissions around electron. So we actually wrote basically like a permissions flow that essentially democratizes permissions within the Electron project. So it's a private repo. All the permissions are structured in a YAML file and any new permission you want, you open a PR to the repo.

10:43And then once it's approved by people with appropriate permission, that you automatically gain access to that repository, that set of logs, that GitHub app, what have you. Our whole release process is also automated. Certain people with permissions, you can trigger the bot to do releases in Slack. And then people with permissions have the 2FA access to be able to approve the release via OTP. All of our backports are automated to release lines where possible. Failures are surface to engineers who can then do manual backports, but on average, it's about a 10 % shearer for every stable line going back one.

11:18We've also done a lot of those metrics over the years. So we do know actually to the relative specificity exactly how effective our automation is and how well it's serving its stated purpose. There's an old joke about software engineers that we will spend 10 hours of effort to automate a one-hour task. If I was on a web platform team for a company and heard or felt gripes or pains about some tasks that could be automated, how would you advise I determine whether it's worthwhile to automate that task or to keep doing it manually? Great question, actually. So I think the thing that's interesting within the Electron project itself is that there aren't really like, I'm not really answering to someone who's telling me what features I need to implement or what bugs I need to fix in the same way that I think I would if I was on a closed source intro Microsoft team.

12:06So ultimately, I think that's forced all of us to develop a stronger sense of what is my time worth? Where should I be dedicating it? And how am I keeping track of my like risk reward calculus, I suppose. Because ultimately, the only one that ends up kind of losing if I make a mistake is me because, and like community in general, I'm automating something that doesn't really matter at the expense of fixing like 10 bugs, then I'm just getting yelled out online. And you know, I don't really want that. So I mean, ultimately it's kind of an intuition you develop. Having looked at a lot of and spent a lot of time in our automation over the years, I think it's pretty easy for me to sit there and be like, okay, like, what is the point of this?

12:48What problem am I actually trying to solve? That's a question I think, you know, we're kind of forced to ask ourselves constantly, what problem is this solving? Is what I am doing actually solving that problem? Is it solving a symptom of that problem? Is it just up the wrong tree entirely? I don't know. But that is something that I think at least I can kind of sense now enough. Developers are notoriously pretty bad at doing cost estimates or time estimates for tasks. But is there like a one particular metric you think has worked well for you in developing that intuition? Good question. I don't really know.

13:22I feel like the best way to describe this is going to require me to use one of my like most horrifying metaphors. Anyone that knows me well enough knows that I love a metaphor. Josh, are you familiar with the art of chicken sexing? I'm worried. No. Okay. So basically it's extremely hard to tell the gender of chicks and there's professionals that are trained for thousands and thousands and thousands of hours to be able to tell the gender of chicks when they're so young that you can't. And after enough hours, they develop the ability to tell that within like half a second, based on entirely intuition.

13:56They basically cannot explain to you why they know that, but they just do. That's so fascinating. Yeah, sorry. It's kind of a curse metaphor, but I promise I was going somewhere with that. And ultimately, I think that like, to be honest, I don't really know that I could say because I think it's just been enough years and like I've had enough evidence to accumulate and form the patterns in my mind that I just kind of like know sort of without being able to necessarily describe in super deep detail like how I can look at for example like a bug in Electron's bug tracker and pretty accurately estimate how long it would take for me to solve it probably within five to ten minutes and then make like a snap decision and whether it's worth me doing then putting off till the next couple days, putting off like basically short, medium, long-term mental task list.

14:42Okay. Thank you. That's an interesting tidbit right there, chicken sexing. But I want to take us back a little bit towards the technical side, because I'm sure a lot of listeners are fascinated, as am I, with how Electron works. So from the tech stack perspective, you mentioned there's Node in there, there's Chromium. Can you tell us, are you using Chromium directly, or even what is Chromium, and how is that playing into the whole system? So, I mean, Chromium is fundamentally almost an operating system. I think there is a misconception that every single Electron app ships with all of Chromium.

15:12That is actually not the case. We like strategically depend on various layers of Chromium. Content shell is the layer that is primarily exposed or like primarily shipped by us. It's basically like the embedder accessible layer. And then we pull in certain other features of Chromium, certain other subdirectories, depending on need, depending on what features certain users have asked for and which web APIs we want to support. There's a bit of schism in where some features, for example, some web APIs are exposed within Chromium. And so sometimes we'll selectively either copy or pull in what's in the Chrome layer in order to enable those use cases for end users.

15:52we also try to have an okay relationship with upstream chromium engineers to try to work with them to make sure that you know we kind of upstream things where possible so we don't have a ton of patches on our end but essentially we are leveraging the ability to access the file system networking via as i said earlier with the ui capabilities of chromium with like other franken pieces where necessary but ultimately yeah i think a lot of people do think we ship like all of chromium And that just is not the case and has never been. But you do ship multiple runtimes, right? You mentioned both JavaScript and C++.

16:27Like if I have an app, am I writing both JavaScript and C++ when I'm writing stuff in Electron? No, you as the end user, unless you're using native Node add-ons, would really only ever be interfacing with the JavaScript layer that we expose as proper APIs. Gotcha. You can vault whatever you want onto that. But yeah, that's all you're ever really interfacing with. So there's a couple of interesting things that come up, I guess, from that. So, you know, Node ships with V8 and Chromium actually also ships with V8. So we had to do some interesting things to basically munge together the fact that there's two V8s.

17:02So we actually only ship one and then we essentially have Node patched to use a more recent version of V8 that Node itself is actually using, whatever version that is being shipped in that version of Electron. So we actually often interact with ways in which V8 requires changes to Node before Node does, which has led to some fun afternoons of debugging. Has that ever benefited the Node project, taking learnings from you and shoving them into Node earlier than they would have happened? Yes, actually. I typically try to upstream anything that comes up, although Node actually also does a lot of great work around that.

17:36They maintain a fork of Node that is basically rolled every single day for whatever the newest version of V8 is. So they also catch things pretty fast. And then, you know, if I come up with an exciting crash that they weren't aware of, then I'll usually report that on to the issue tracker for the fork and not node itself. You know, you can tell when someone has been working in code as a software developer for a very long time because they use phrases like exciting crash, which you just did.

18:02APIs are the foundation of reliable AI and reliable APIs start with Postman. Trusted by 98 % of the Fortune 500, Postman is the platform that helps over 40 million developers build and scale the APIs behind their most critical business workflows. With Postman, teams get centralized access to the latest LLMs and APIs, MCP support, and no-code workflows all in one platform. Quickly integrate critical tools and build multi-step agents without writing a single line of code. Start building smarter, more reliable agents today. Visit postman.com.sed to learn more. what is an example to you of an exciting crash in node or v8 or those areas ah i could probably spend all day talking about the bugs that i found most interesting in electron over the years there's been so many of them i don't know i think like what is most interesting to me is when there's some kind of like a wild crash or like a error that looks innocent but actually belies something far more like interesting and requires more work than i expected a very simple example or not simple the actual bug was awful but like a example off the top of my brain is a bug that I encountered where mac os was showing ghost windows in some full screen transitions and it turns out that there was an sdk change I think maybe three ish years ago which is when I was dealing with this that meant that you couldn't do nested full screen transitions and so I ended up having to implement this like very small little queuing system for full screen transitions on macOS and Electron and there's this really long comment that's basically like this is here because there are three apple bugs in a trench coat do not ask questions never change this code have people tried to change the code since you wrote that not really because I think that as soon as I say something like three apple bugs in a trench coat people are like you can deal with that forever.

19:57Yeah. I do a lot of the macOS stuff in Electron. So usually if it's like frightening and macOS related, it becomes my problem. That sounds exciting indeed. But okay. So continuing on through the Electron process journey, as you said, I, as a user of it, if I'm writing an app on Electron, I might only be writing in JavaScript, but there are multiple JavaScripts in the world. As you said, there's the Chromium side of V8. So there's the, I don't want to say front end, but the browser oriented to JavaScript code. And then there's also the node area of code. If I have two processes running in JavaScript, one in each of those areas, how would they communicate?

20:32Or how do I do message passing there? So it sounds like you're asking me essentially, like how we communicate between the browser process and then render processes. Sure. So essentially, Chromium is a multi-process architecture. There is one browser process, the main process, and then it's so it's a one to many relationship, many render processes. There's also a concept of utility process, which is a different thing I could go into more detail about at some point. But essentially, yeah, the renderer can send messages back to the main process because a lot of Electron APIs are process specific.

21:04So for example, you probably don't want to be doing a lot of compute heavy things like dealing with complex menus or changing them or managing them or what have you from the render process. That's something you really only ever do in the main process. But if you need to affect that from like a change you made in the renderer, then you'd use what's called IPC, inter-process communication, to send a message back to the main process to then make that change on that side. Typically speaking, anything that would be more process specific would be you can access Node in the renderer process, the utility process, and the main process.

21:38Although typically from a security perspective, you'd really only want to expose the APIs you need in the renderer process and then really try to do all that in the main process. That's actually something that Electron has disabled by default for security reasons. In the render process, you have to explicitly opt into enabling certain APIs there. But typically, you'd want to expose those preemptively, like I said. I think in my head, I've always kind of conceptualized Electron is it's really just like a big toolbox. You can bolt on whatever you want to it. And then whatever ultimately emerges from that that your team decides to write or create is a property of how you've architected your app, the decisions you've made, what security considerations you've taken into account, what performance considerations you've taken into account.

22:19And there's always, to be clear, things that the Electron team can be continually working and approving upon. But Electron in the end has always kind of been like what you make of it, I guess, for better or worse. So we've already mentioned Adam and VS Code editors, which are rather large and complex examples of what you can build with Electron. Is there a good just after the hello world example of an app that you would give as an example of something someone could build with Electron? Good question. I think it's hard because it really just like is so much. I guess this app is like not super simple, but there's a lot of apps that I use all the time that I like don't necessarily know where Electron until I like realize there's a bug and then try to clone the repo and then consider contributing to it and go, oh, Electron, fun.

23:00But like one that I like a lot and I've contributed to a little bit over the years is Gitify. It's a GitHub notifications app that lives in your menu bar. And I think it's like a pretty good example of a main process concerns, render process concerns, uses React, I think, and just kind of illustrates like how you write an app that solves a pretty specific use case, but in a way that I think is like readable, understandable, and like gives you a decent idea of what Electron lets you do. Sure. Which brings up a good point that because it is air quotes here, just JavaScript or just the browser or Chromium, you can use things like React, right?

23:37Like there are plenty of, although VS Code itself isn't built with React, there are plenty of apps that are built on electron or similar web technology, where the code base is virtually the same or extremely similar to what you might find in a browser app, right? That's really interesting. That's a good cost coding measure, right? For teams, if you want to build an app, if you want it to run, say in the browser and on your desktop, electrons part of what makes that possible, right? Yeah, which actually kind of leads me to, I think, another thing that a lot of people don't really recognize about electron, which is that electron is at its core, not something that like, solves a use case for everyone.

24:11Like the type of team and the type of company that would really benefit from writing their app in Electron is very different than say the considerations that like an indie dev would have if they're trying to write like a interesting little to-do app for their users that may be better served by writing a native app. That's totally fine. But I think like one of the biggest benefits of it is that it does let you ship applications to more users more effectively using skill sets that a lot of your engineers probably already have because a lot of developers have low development skills. But at the same time, if there is a difficulty in, say, getting something to work on the web or a difficulty in getting something to work with JavaScript, that would impact your app no matter what you write in, whether it's Electron or the browser or other JavaScript environments, right?

24:55Yeah. Cool. Day-to-day, there are a lot of apps that folks use that are known to be an Electron, like VS Code, and you mentioned there are quite a few that aren't. Are there any particular apps that you use that a lot of folks would know that are surprisingly written in Electron, the way you mentioned Getify is? Good question. I feel like a lot of the big ones, a lot of people kind of already know. Actually, interesting misconception that I think some people have is that Spotify is an Electron app. Spotify is actually not an Electron app. Spotify is also a Chromium-based app. It actually predates Electron, which is why, I mean, there's many other reasons.

25:30It's probably not Electron. I don't know. But it does predate Electron. It's written in Ceph, which is the Chromium embedded framework, which it's like a similar framework that lets you embed Chromium to make a desktop app, but it is not, in fact, Electron. Trying to think of a couple others that people might know and or use. I don't know. Is Notion an Electron app? Yes, actually. Notion is also a great contributor to the Electron project. Oh, shout out Notion. Thank you for that. Do you find that a lot of the bigger companies that write apps in Electron end up contributing back to the project?

26:03Genuinely, a really mixed bag. We've had a lot of really great contributions over the years from a lot of companies that have written flagship apps in Electron. I also think there's a pretty broad range of ways companies can give back. So even like on a smaller scale, something we really appreciate is when companies who are, you know, having issues or whatever using Electron write really good bug reports. Show up with really interesting information, do a little bit of research on their own. That's super helpful to us, too. Sometimes you get issues and they've done like a little deep dive into, okay, this is the investigation we did.