EPISODE 1832

[INTRODUCTION]

[0:00:00] ANNOUNCER: Electron 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 codebase to run on Windows, macOS, and Linux. Shelly Vohr 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. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, the tooling that enables ESLint 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 Bluesky, Mastodon, Twitter, Twitch, YouTube, and .com as Joshua K. Goldberg. 

[INTERVIEW]

[0:01:20] JG: Shelly, welcome to Software Engineering Daily. 

[0:01:22] SV: Hello. Thank you for having me. 

[0:01:25] JG: 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. 

[0:01:37] SV: Yeah, absolutely. I, as a kid, was always pretty interested in the way that stuff worked. 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. And then at a certain point, I realized that there was such a thing as programming languages that can interface with Mac. And basically 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 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. Yeah. 

[0:02:43] JG: That sounds great. Was it by any chance a TI-84 calculator that you were programming? 

[0:02:47] SV: It was. Indeed. Yes. 

[0:02:48] JG: Those are classic. Okay, out of high school, you were taking software engineering as a career track. What was your first job experience? 

[0:02:58] SV: 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 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 in north Boston. It was a little startup, but it was 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 sophomore engineering internship every summer, and also did one during the year. And ultimately, I think that really set me up well for what I ended up doing post-college. 

[0:03:56] JG: And what did you end up doing post-college? 

[0:03:59] SV: Actually, in retrospect, this is a little wild. I interned at GitHub the summer before I graduated from college. And I finished my sophomore 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 temp on his team just to see if I could make an impact last couple weeks, get to know some folks, branch out of what I've been doing in my internship so far, and he said yes. And 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. 

[0:04:41] JG: To recap, could you tell us what are Atom and Electron and how those play into what is now called VS Code? 

[0:04:46] SV: Yes. 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. 

[0:05:12] JG: And Atom is an editor that built on that. That's one of the canonical examples of an Electron app?

[0:05:17] SV: 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. 

[0:05:34] JG: You're not a JavaScript developer, nor are you a pure C++ developer. What are you? 

[0:05:39] SV: 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. 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 browser engineering job. I'm not really sure if there's a better way to describe it. I always laugh a little and people are like, "Are you front end or back end?" And I'm like, "I don't know what that - I have no idea." Both? Neither? Secret third thing? 

[0:06:33] JG: 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, from the machine to what people actually interact with. Do you see yourself as even aligning on the front to back end? Are you some different spectrum? 

[0:06:52] SV: Yeah, I think I would agree with you that it's not really - my job doesn't really exist along that access because I think that that presupposes that you work somewhere on the web in a browser or that the product you work on is ultimately like a web product per se. And I think at least for me, that's just never really like a framework that's applied. 

[0:07:13] JG: Yeah. 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 how Electron works, because it's actually kind of fascinating. Is there a 30-second overview or a one to two-minute overview that you're comfortable giving of this giant project that you work on? 

[0:07:31] SV: I will do my best. 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 for use cases demand. For example, you could use Chromium's UI capabilities to write a desktop app where everything you're looking at is JavaScript, CSS, HTML, and then you have a bunch of native node add-ons. You farm out to different native libraries, capabilities that you wouldn't be able to access using either to enable really a whole broad range of use cases that were pretty hard to access and were pretty hard to implement before Electron came along in a way that was accessible to broader teams of devs with more web-based backgrounds. 

[0:08:26] JG: Yeah, 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? 

[0:08:45] SV: Yeah. A small example is Apple maintains a couple of APIs that are all on Swift. 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. And then using your app, call out to those Swift-only APIs and then leverage them within your app. 

[0:09:06] JG: Okay. Let's say I have an app built in Electron, 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? 

[0:09:17] SV: 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 are several other lovely libraries in the ecosystem that we try to support where we can. 

[0:09:36] JG: You 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. 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? 

[0:09:53] SV: This is a great question. As someone who has unfortunately spent so much time in Electron-bought 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. I think total governance is 25-ish. Core engineering, less. But Electron's tooling is essentially a small enterprise-level tooling. 

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. We actually wrote basically a permissions flow that essentially democratizes permissions within the Electron project. 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. And then once it's approved by people with appropriate permission, then 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 surfaced to engineers who can then do manual backports. But on average, it's about a 10% shear for every stable line going back one. We've also done a lot of those metrics over the years. We do know actually to the relative specificity exactly how effective our automation is and how well it's serving its stated purpose. 

[0:11:31] JG: There's a little 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? 

[0:11:50] SV: Great question, actually. I think the thing that's interesting within the Electron project itself is that there aren't really - 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 into Microsoft team. 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 and the community in general. I'm automating something that doesn't really matter, fixing 10 bugs, then I'm just getting yelled at online and I don't really want that. 

I mean, ultimately, it's kind of an intuition you develop. By having to look at a lot of and spend a lot of time on our automation over the years, I think it's pretty easy for me to sit there and be like, "Okay, what is the point of this? What problem am I actually trying to solve?" That's a question I think we're kind of forced to ask ourselves constantly. What problem is it 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. 

[0:13:09] JG: Developers are notoriously pretty bad at doing cost estimates or time estimates for tasks, but is there a one particular metric you think has worked well for you in developing that intuition? 

[0:13:20] SV: Good question. I don't really know. I feel like the best way to describe this is going to require me to use one of my 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? 

[0:13:34] JG: I'm worried. No. 

[0:13:36] SV: Okay. 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. They basically cannot explain to you why they know that, but they just do. 

[0:14:00] JG: That's so fascinating. 

[0:14:01] SV: Yeah, sorry. It's kind of a curse metaphor, but I promise I was going somewhere with that. 

[0:14:05] JG: Yeah. 

[0:14:06] SV: And ultimately, I think that, 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 how I can look at, for example, 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 a snap decision. In the night, if it's worth me doing then, putting off till the next couple days, putting off basically short, medium, long-term mental task list. 

[0:14:42] JG: Okay. 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. 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? 

[0:15:05] JG: 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. That is actually not the case. We strategically depend on various layers of Chromium. Content shell is the layer that is primarily exposed or primarily shipped by us. It's basically like the embedded accessible layer. And then we pull in certain other features of Chromium, certain other sub-directories depending on need, depending on what features certain users have asked for, and which web API they want to support. 

There's a bit of schism in where some features, for example, some web APIs are exposed within Chromium. 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. We also try to have an okay relationship with upstream Chromium engineers to try to work with them to make sure that 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, as I said earlier, with the UI capabilities of Chromium with other naked 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. 

[0:16:23] JG: But you do ship multiple runtimes, right? You mentioned both JavaScript and C++. If I have an app, am I writing both JavaScript and C++ when I'm writing stuff in Electron? 

[0:16:34] SV: 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. 

[0:16:40] JG: Gotcha. 

[0:16:41] SV: You can bolt whatever you want on to that. But yeah, that's all you're ever really interfacing with. There's a couple of interesting things that come up, I guess, from that. Node ships with V8, and Chromium actually also ships with V8. We had to do some interesting things to basically munch together the fact that there's two V8s. We actually only shipped one, and then we essentially have node patch to use a more recent version of V8 than node itself is actually using whatever version that is being shipped in that version of Electron. We actually often interact with ways in which V8 requires changes to node before node does, which has led to some fun for some debugging. 

[0:17:25] JG: Has that ever benefited the Node project, taking learnings from you and shelving them into Node earlier than they would have happened? 

[0:17:31] SV: Yes, actually. I typically try to upstream anything that comes up, although Node actually also does a lot of great work around that. They maintain a fork of Node that is basically rolled every single day for whatever the newest version of V8 is. They also catch things pretty fast. And then if I come up with an exciting crash that they weren't aware of, then I'll usually report that onto the issue tracker for the fork and not Node itself. 

[0:17:52] JG: 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. What is an example to you of an exciting crash in Node, or V8, or those areas? 

[0:18:06] SV: 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 what is most interesting to me is when there's some kind of like a wild crash or like an error that looks innocent but actually belies something far more interesting and requires more work than I expected. A very simple example, or not simple, the actual bug was awful, but an example off the top of my brain is a bug that I encountered where macOS 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 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." 

[0:19:12] JG: Have people tried to change the code since you wrote that? 

[0:19:14] SV: Not really, because I think that as soon as I say something like three apple bugs in a trench code, people are like, "You can deal with that forever." 

[0:19:22] JG: Yeah. I love it. 

[0:19:24] SV: I do a lot of the macOS stuff in Electron. Usually, if it's frightening and macOS-related, it becomes my problem. 

[0:19:31] JG: That sounds exciting indeed. But okay, 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 running in JavaScript. But there are multiple JavaScripts in the world. As you said, there's the Chromium side of V8. There's the - I don't want to say front end, but the browser-oriented 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? Or how do I do message passing there? 

[0:19:59] SV: It sounds like you're asking me essentially how we communicate between the browser process and then renderer processes. 

[0:20:05] JG: Sure. 

[0:20:06] SV: Essentially, Chromium is a multi-process architecture. There is one browser process, the main process. It's a one-to-many relationship and many renderer processes. There's also a concept of the 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. 

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 renderer 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 do 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. Although, 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 renderer process, you have to explicitly opt into enabling certain APIs there. But typically, you'd want to expose those pre-emptively, 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 architectured your app, the decisions you've made. What security considerations you've taken into account? What performance considerations you've taken into account? And there's always, to be clear, things that the Electron team can be continually working and improving upon. But Electron in the end has always kind of been like what you make of it, I guess, for better or worse. 

[0:21:54] JG: We've already mentioned Atom 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? 

[0:22:08] SV: Good question. I think it's hard because it really just 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 don't necessarily know where Electron until I realize there's a bug and then try to clone the repo and then consider contributing to it and go, "Oh, Electron. Fun." But one that I like a lot and have 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 main process concerns, render process concerns. Uses React, I think, and just kind of illustrates how you write an app that solves a pretty specific use case, but in a way that I think is readable, understandable, and gives you a decent idea of what Electron lets you do. 

[0:22:53] JG: Sure, which brings up a good point, that because it is "just JavaScript, or just the browser, or Chromium", you can use things like React, right? 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? 

[0:23:12] SV: Mm-hmm. 

[0:23:14] JG: That's really interesting. That's a good cost-cutting measure for teams. If you want to build an app, if you want it to run, say, in the browser and on your desktop, Electron's part of what makes that possible, right? 

[0:23:22] SV: 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 solves a use case for everyone. 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 an indie dev would have if they're trying to write an interesting little to-do app for their users that, "Maybe better serve by writing a native app." That's totally fine. But I think one of the biggest benefits of it is that it does let you ship applications to more users more effectively using skillsets that a lot of your engineers probably already have, because a lot of developers have low development skills. 

[0:24:05] JG: 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? 

[0:24:20] SV: Yeah. 

[0:24:21] JG: Cool. Day to day, there are a lot of apps that folks use that are known to be in 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 Gitify is? 

[0:24:36] SV: Hmm, 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, probably not Electron. I don't know. But it does predate Electron. And it's written in CEF, which is the Chromium Embedded framework, which it's like a similar framework that lets you embed to 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. 

[0:25:15] JG: Is Notion an Electron app? 

[0:25:16] SV: Yes, actually. Notion is also a great contributor to the Electron project. 

[0:25:21] JG: Oh, shout out Notion. Thank you for that. 

[0:25:23] SV: Yeah. 

[0:25:24] JG: Do you find that a lot of the bigger companies that write apps in Electron end up contributing back to the project? 

[0:25:28] SV: Genuinely, 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. Even on a smaller scale, something we really appreciate is when companies who are having issues or whatever using Electron write really good bug reports, show up with really interesting information, do a little bit of research on the room. 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. This is the exact version in which this started breaking." And even that's great. That really helps me. 

And then generally speaking, Electron is part of the OpenJS Foundation and has a governance model as a result of that. And we have representation from a fair amount of different companies who participate in a variety of different working groups. We have the API working group, we have the releases working group, the ecosystem working group, the upgrades working group, all of which I could go further into if you do like. But generally speaking, any app that wants to contribute to some extent could understanding the way that our governance model works, start participating in governance and start helping guide the direction that the project takes. 

[0:26:40] JG: For the interest in time, I would love to dive into those. Could you pick one of those working groups and tell us what that means and how that works? 

[0:26:45] SV: Sure, yeah. The Electron governance model has a chunk of different working groups. Generally speaking, what you work on within the project is largely dictated by what working groups you are a part of. Personally, I'm in the security working group, the upgrades working group, the API working group, community safety working group. Did I say upgrades already? I think I did. Anyway, a bunch of them. The more engineering you want. 

But just to pick one, the releases working group is responsible for releases of Electron. If you are in that working group, then you are responsible for an issue triage rotation. That is a weekly rotation. You are responsible for all associated ecosystem apps around releases. The release automation flow that I described earlier in this call, that would fall into the release purview. Generally speaking, for every release, there's a release captain. One person is designated as the kind of DRI for that release, making sure that all - 

[0:27:40] JG: DRI? 

[0:27:41] SV: Directly responsible individual. 

[0:27:44] JG: Thank you. 

[0:27:44] SV: For making sure that release gets out on time. Making sure that pull request, that should be in that release, go out in that release, and making sure that all other general bookkeeping is done. Release notes are correct, the blog post is published, any other any other related tasks that need to get out for every release. All of this information is also public in case anyone's curious. You can go on for any given working group and see what the requirements are for joining it. What the responsibilities of being a part of it are? And also, who is a member of it? 

[0:28:11] JG: I'm struck listening to this, how in some and perhaps most ways it is similar to how a larger company's platform team internally might do releases where you have different individuals working in different areas. You've got customers internally or externally who are stakeholders in it. Do you find that it is similar or different in particular ways from working within a company, the way that you're doing all these things in the open and open source? 

[0:28:35] SV: Yeah. I mean, really, yes and no. Like I said earlier, we do genuinely kind of operate a tiny little enterprise in terms of just the scale of our tooling, the scale of a lot of what we've built, the way that we've architected it for non-community members. For example, you could go to releases.electronjs.org and see all of our release success history indefinitely. You can see every nightly that we've successfully released and/or missed. All associated release information, all of the release notes, all of the links to PRs that you would kind of want. Because inherently, we do recognize that Electron's user base is broad and vast. And that the people that want to see this information might need to see it within a more corporate structure. They might need to access that information for security reasons, other reasons, whatever. I do honestly think it really is a little bit more of a, like I said, tiny enterprise, a small team doing things for a pretty surprisingly big scale. 

[0:29:32] JG: Do you have any idea how many different apps, or is it thousands, hundred thousands, millions of users you have of Electron? 

[0:29:38] SV: - It's really hard to say the exact number of total apps that are written with it, but I do actually maintain or help maintain within Electron just a little running repo that categorizes all of our daily downloads for Electron. And I think on average for monthly downloads as of now, it's about 100,000. 

[0:29:55] JG: That's pretty great. 

[0:29:56] SV: Yeah. 

[0:29:57] JG: Cool. For the rest of the interview, I'd like to just take a little bit of a step back from the internals of Electron and its working groups and talk about kind of how it's positioned in the industry. For a few years, at least a few years ago, there was kind of a common gripe about Electron and performance. And many gripes about performance, I think it was partially insightful, partially just misunderstanding. Do you know what I'm talking about? And would you like to talk about how people have voiced concerns on Electron's performance? 

[0:30:27] SV: Yes. Well, as I mentioned earlier, there's always ways that Electron can be improving its performance, making sure we're staying up to date with Chrome, which actually we've been doing for more than five years at this point. But new versions of Chrome bring with them performance improvements, et cetera. But ultimately, a lot of the performance of an Electron app lies in the way that you architect and the way that you approach using Electron. 

I think a lot of people see electron as also wanting to maintain a position of "dominance" or wanting to be the thing that everyone uses and I think that that's not really true and hasn't ever been. Shout out to Felix actually, who works at Notion, who has been working on electron for about 10 years, has written two extremely good blog posts that kind of cover this in a bit more depth. The first of which is - sorry, Felix. I don't remember how old exactly this post is, but It's called Defeating Electron and it basically goes into what gap Electron fills and what would be necessary for something to basically take Electron's current place in the software engineering industry. 

And I think something that all the people don't recognize is that our whole team, generally speaking, we're totally fine with that. If something comes along and basically makes Electron obsolete, I'd be like, "Cool. Now, I get to work on some new other cool stuff. I don't know." I enjoy working on Electron because I think that it's a project that enables a lot of really cool software that otherwise just wouldn't have shipped. And so I'm not really interested in working on something just to work on it or for something to exist just so that I can say that it does. 

[0:32:04] JG: Yeah. There are a few bad words in open source, "winning or competitors". Why are those bad words in this context? 

[0:32:12] SV: I mean, I think a lot of people really see it as like a zero-sum game. I've had some conversations with people over time where they're like, "I used Tauri and it was awesome." And my response is like, "Awesome. Cool." What was it? I have no interest in you using Electron if Electron does not stop your problem. And I don't think anyone else in my team really does either. It's really cool that you used another framework that, I don't know, had potentially a smaller bundle size or performed faster along the happy paths of the app that you wrote. That's cool. I have no issue with that. I don't really see any of those things as like a competitor that I have to, I don't know, kill or whatever. 

[0:32:53] JG: Yeah, neighbors rather than. But that is a good point to bring up actually. Thank you, Tauri and other apps. What is different between, say, the way Electron does things versus, say, Tauri or other equivalent CEF in the area? 

[0:33:05] SV: I mean, fundamentally, I think the biggest difference is that Tauri requires that you write Rust, which is a lesser have skill set than web development primarily. I think that the type of person that would really benefit from writing their app in Tauri is very person or the type of company that would really benefit from writing their app on Electron. And that's totally fine because, like I said, Electron is fundamentally a toolbox that comes with a bunch of tools. And if you look through the whole toolbox and you realize that the tool you need isn't there, then you should look for another toolbox. You shouldn't try to sit there and start whacking away your nail with a wrench. I have no interest in that. I don't think the rest of us do either. 

[0:33:44] JG: Do you often get bug reports about how this wrench is not performing very well as a hammer? 

[0:33:49] SV: Sometimes we've done some real wild bug reports over time about people that are like, "It worked for my absolutely wild esoteric use case." And I really don't have that much problem being like, "Don't do that. Why are you doing that?" I remember this one where someone was like, "If I open 500 sub-menus of my menu with itself, 300 sub-menus, the performance is bad." And I was like, "Don't do that." 

[0:34:12] JG: Yeah. 

[0:34:13] SV: You shouldn't be doing that. I have no interest in solving this use case. 

[0:34:19] JG: One struggles to imagine what that use case is. 

[0:34:22] SV: Yeah. 

[0:34:24] JG: Cool. Okay. But one of the questions that comes up a lot is Electron ships with Chromium. It's an opinionated distribution. And if you have different apps in your system built on different versions of electron, you're then going to get different versions of V8, of Node, of Chromium together. What would the architectural difference between that and, say, "just using these systems" built-in browser or JavaScript runtimes? Is that something that is doable in Electron or any of its equivalents? 

[0:34:49] SV: I'm going to actually shed out to Felix again here because this came up with a more recent blog post, which is that a lot of the main reasons that developers look for Electron isn't actually surprisingly about performance. It's a lot more about be able to have control over the distribution security and stability of the platform that it is that you're shipping. Shipping with, for example, the system web views removes actually quite a lot of agency and control from you as the app developer and what it is that you're shipping, what versions of it that it's relying on, et cetera, et cetera. 

At least that I can kind of conceptualize it and being able to ship with specific versions of Chromium, of Node, of V8, or whatever does allow you a lot more control over your app security. Because ultimately, you were able to make sure that you have pulled in all relevant security backboards that your app is written in a way that you know potential vulnerabilities it might have. You've taken steps to mitigate them, et cetera. 

Where I think if you're using a system, WebView, or whatever, then you can get quite a lot of benefit from, say, performance having fewer copies of certain parts of Chromium around your computer. Sure. But you do lose a lot of control. And I think that the question there is not, "Oh, which one of those is better?" Because I think that's another thing that I can't answer that for you, company. I don't know that. That is for you to kind of evaluate, decide, and then commit to. 

[0:36:15] JG: I think one of my favorite use cases for something like Electron is when you have a performance-critical thing, which isn't necessarily like a game or rendering edge, it's just an editor or something people expect to be snappy. But then another great use case for something like a built-in web app is if you have an internal customer support portal. Maybe that thing, which is only accessed on an intranet by a team of a few dozen people, maybe that thing doesn't really need perfect bundled performance concerns. Maybe you can just throw it up in a web page. 

[0:36:42] SV: Yeah, I would generally speaking agree. I think a lot of what Electron enables you to do too is if you don't have developers with a skill set to ship three different native apps or three different operating systems, oftentimes what will happen is that you just don't ship apps for those operating systems. And I think a lot of users would prefer an application that might not look perfectly native on every single operating system to having no app at all. 

[0:37:06] JG: You mentioned earlier the trade-off in how you tackle bugs, where if you go down some rabbit hole, the opportunity cost of that is that you might not have then fixed the several bugs you would have fixed in that same amount of time. In a sense, Electron allows - and things like it allow people to write more features and fix more bugs because they're not spending time working cross-operating system or on different native apps. Yeah? 

[0:37:28] SV: Mm-hmm. Most of the people who are really suffering and the idiosyncrasies of various operating systems and their foibles is us, yes. 

[0:37:35] JG: That's you. 

[0:37:37] SV: I mean, there are some  various APIs within Electron that we expose that aren't perfectly equivalent across platforms. And I think that's, generally speaking, fine. We do try to mitigate that where possible, but there's certain APIs, and concepts and paradigms that just only exist on certain operating systems. And it is what it is. But no. Yeah, generally speaking, if we are doing our jobs correctly, that shouldn't be, as the developer, your problem. 

[0:38:02] JG: Are there directions or investment areas you're excited about for Electron for the next two, five years? 

[0:38:07] SV: Good question. Really kind of also a mixed bag. I know I've fallen back on that phrasing a bit during this call. But I think that Electron, technically speaking, it's a framework. It's not really like something that's halfway done or in development, that's saying that a lot of big name companies have been using it for many years. I think, ultimately, one of the interesting promises of it is that it can be and it can move towards whatever it is that like we want it to be, that our customer base wants it to be, that we can reach out and figure that out kind of as we go. 

Generally speaking, our general concerns are always the same, which or make sure we're always shipping on time, make sure we're always keeping Chromium up to date, make sure - and this is actually something that we've talked about a fair bit and actually made a lot of changes about with an Electron in the last four or five years is to make the intuitive choice, the simple choice, the easiest choice. 

It shouldn't really be the case that if you're developing a new app that you're accidentally footgunning on some security horror when that is the easy thing to do if that makes sense. That's actually a big part of why we got rid of their remote module. It's now no longer bundled with Electron. You can install it separately, but it was the easiest thing for people to do for a long time, but it was also a performance nightmare. It was a security nightmare. And ultimately, the easiest thing to do is just to make it so the correct thing to do, which is, for most people, IPC is the easiest thing that you can find the most documentation and resources for. 

[0:39:35] JG: Do you think that developers reaching for Electron in, let's say, the next year or two, do you think that things have gotten significantly more streamlined or reasonable for them to understand at first? 

[0:39:45] SV: I would say yes. I think we can always improve documentation. We can always improve the ways in which we make sure that you know what our security recommendations are, performance recommendations, et cetera, et cetera. But Chromium's gotten a lot faster over the years. Generally speaking, Electron's performance has also improved a fair amount over the years. And I think that it will continue to. I think that it's important we continue to maintain, as a team, good relationships with our human dependencies to make sure that we are capitalizing on those to deliver a really good experience to people using Electron. 

[0:40:17] JG: One last call back to the community pains. For a while, Slack in particular was called out as a slow Electron app, which then some folks would assume just means that Electron apps are slow. I haven't heard that much griping about Slack performance recently. Do you know why that is? I remember there was some big architectural shift they did about performance. 

[0:40:37] SV: I think one of the reasons that Slack performance and perceived performance has improved a lot over the years is that representatives from Slack and engineers from Slack have contributed to and invested in Electron fairly heavily over the years. A lot of features that exist in Electron only exist because of really good hard work from people who work for Slack enabling use cases for the Slack app itself and also helping improve Electron's architecture to make Slack performance and sell faster. Which is, generally speaking, I think a pretty good example of how Electron - if you as a company are kind of sitting there going, "Hmm, I really wish that Electron did so and so, but like it doesn't," and you have an idea of what it would take for that to get there, come on in. Electron is a table that you can come and sit at. You can talk to us about what it is you need. You can show up with a PR. We'll talk to you about it. We'll review it. We want your company, your use case to succeed. 

[0:41:30] JG: Let's use that analogy or metaphor since you've mentioned liking them. A lot of people see software as either a traditional restaurant or a to-go situation where you come, you pay, you get what you want. Other folks see it as a buffet where there's some provider, some service that you can just take as much as you want whenever you want it. But in open source land, it sometimes can act a little more like a potluck dinner where the host provides some baseline amount. But if you really want to improve things, you have to bring your own food. Is that an accurate metaphor or analogy here? 

[0:41:59] SV: Yeah. I think, really, the difficulty for different open source projects is less is it an open table or not? Versus I think a lot of people have difficulty figuring out what the manner expectations are of that table, of that "restaurant". Sorry, this metaphor might get wild. But generally speaking, I think there's kind of two ways to practice inclusion as a project. There's active inclusion and there's passive inclusion. And I think that both have a place in terms of the culture that you want to cultivate around your project. But you do need to be cognizant of what that does mean for its contribution base and what contributions you're going to allow in versus kind of implicitly stave off depending on which one you choose. 

I think Electron, the barrier to being able to communicate is a bit high. We've tried to do a fair amount of work to mitigate that over the years. There's a repository called Build Tools that's spun out of essentially most of the Electron core team having a different absolutely wild set of scripts and aliases that we all built with until we all kind of put our heads together and we're like, "Okay, we can actually just make this its own separate toolkit that enables people to interact with building and managing Electron more easily," which we've done. And also, it's been fairly effective, I would say, as a result of the fact that it's what we all use. And so we have a very high stake in making sure it worked well. 

But okay, before I lose the plot on that a little bit, I would say, generally speaking, that as a project open source, I think what kind of scares people is knowing how to participate. And I think, ultimately, for a lot of projects, you just kind of got to get in there, look at what it is that other people are doing with the project that may have more context. And ultimately, probably the most effective thing to do is just to figure out what issues it's in solving and bust through the wall, like the Kool-Aid man with your PRs. 

More often than not, that's kind of what gets you there. I think having worked at open source, that has become over time much easier for me. Really, just at this point only have - you're probably like, "Hey, it's me. Here's my PR. Here's what it fixes. Here's why you should merge it. Thank you. Ta-ta." 

[0:44:00] JG: Great. You're the one busting through the wall yelling, "Oh, yeah," and providing people with Kool-Aid.

[0:44:05] SV: Honestly, yes. 

[0:44:07] JG: Excellent. In our last few minutes of the interview, I want to talk about something completely esoteric and different, because that's a great word. What is a conlang, Shelley? 

[0:44:17] SV: I have always kind of been interested in, I don't know, linguistics, languages, the way they work. And that is actually not to say, which I think is another misconception, that I speak a lot of languages. I don't. I speak decent German, because I live in Germany. And I don't know, decent English. But my interest in linguistics is a lot more kind of rooted in my interest in, I don't know, software engineering, is like why do things work the way they do? What function follows form for different words in different languages? Which form follows function? Which is all a very long way to say that a conlang is a constructed language. It's essentially a language that you kind of write out of not thin air, but that like you kind of construct itself. That doesn't really emerge naturally as a result of a community of people communicating with each other and evolving the language as it's used in practice. A classic example of a conlang would be klingon, something like that. 

Basically, it is one of my hopes to eventually write one. I do find the practice of that interesting the same way that I do, I don't know, solving interesting puzzles within software engineering. I think it's like a really kind of interesting application of being able to understand the way that languages work, the way that they don't, the ways that we can kind of conceptualize the world around us by the language that we speak. 

[0:45:40] JG: See? That's fascinating. Because there's so many parallels between how we write tools for developers or build depth tools and languages versus how things develop that serve non-programming utilities in real life. There's a great quote from Anders Hejlsberg over from the C#, TypeScript areas of things. "Show me a perfect programming language and I'll show you a language with no users. Those are the only ones that can actually be perfect." 

Yes, it sounds awesome that we might be able to make a constructed language like Esperanto or some perfect thing. But then at the end of the day, as you said, form and function follow each other. They're actual real-world considerations. English evolved because people kept using it in certain ways. Do you ever feel frustrated that all the tools we're building, Electron, Tauri, TypeScript, C++, all these things are kind of bound to be imperfect because they have to serve real world use cases and have legacy support scenarios? 

[0:46:28] SV: Honestly, no. I think I see that as much more positive than a downside, because I think I don't really want to build the perfect thing with no users. I think it's really interesting to - well, actually, to wind back a tiny bit, I think a difficulty that sometimes people on the Electron team, the core team run into is that the languages that we're writing Electron in are different a lot of the times than the language of the end users, like what they're writing the app in. And so I think a lot of times, we do rely on users to bring considerations to us and to present issues to us that we hadn't considered because it's a different lens that we're looking through as we're writing the framework. 

Yeah, I do see that as more of a positive because I think that, ultimately, no one person, no one team is able to possibly have all the context that they need in order to write something that people really use. Eventually, you're just going to hit a wall of how good "you can make it" without the external input of people that are breaking it, essentially. 

[0:47:22] JG: That sounds like one of the core skills you have to develop in open source, being able to have empathy and invite people to bring their own opinions. 

[0:47:28] SV: Yeah. I definitely got yelled at online a lot over the years. But ultimately, I don't - I mean, I don't know, maybe this is a hot take or something, but I don't really mind. I mean, obviously, I mind if they're really rude. But as a concept, if you're like, "Oh, you did this thing and it totally screwed me over," that's useful for me. I'm not going to sit there and be like, "I'm really insulted by this." I'm going to be like, "Ah, okay, now what do I do?" New problem, new thing to solve, new use case to consider. 

[0:47:53] JG: That's a very positive outlook about and yelled at online by programmers. 

[0:47:57] SV: I mean, to be fair, it helps. A lot of people who yell online just have a lot of misconceptions about the way that Electron works. It's very easy not to take certain things personally. I don't know. 

[0:48:11] JG: Yeah, no, I feel that. Over in TypeScript ESLint, we got called, and I'm quoting here, "a war crime" because of a change that was released in ESLint. Not our project. Not particularly you're emotionally relevant to us. Are there any particular criticisms you or Electron have received that you find to be most amusing or poignance to you that you want to share before we end? 

[0:48:30] SV: Yeah. I went accidentally viral on Reddit four years ago because someone on Twitter got really mad online about the fact that Electron was broken for this use case on mobile. And I was like, "Electron doesn't work on mobile." And he was like, "Yes, it does." And I was like - I kind of ultimately had to be like, "Look who I am." Yeah, somebody screenshot it and put it on Reddit and then it ended up going kind of viral. And then like a bunch of people mailed it and texted it to me and then I had no idea. But it was fascinating. It was a wild ride of just like a really good example of someone being super loud and super wrong online. 

[0:49:05] JG: Never before has this been observed. 

[0:49:07] SV: Yes. 

[0:49:07] JG: But great. Speaking of who you are, Shelley, we're at a time, are there any particular places you'd suggest people go to find out more about you, or the Electron project, or the folks around it? 

[0:49:16] SV: I'm Codebytere everywhere online, C-O-D-E-B-Y-T-E-R-E. Most people think that's Codebytere or something like that. It was originally that C-O-D-E-B-Y-T-E-R was taken when I tried to make a GitHub account when I was like 13, and so I added an E to the end, but then it works, and now I'm stuck with it forever. It is Codebytere. But I am Codebytere everywhere online, Twitter, Bluesky, what have you. Yeah. 

[0:49:45] JG: Great. Well, for Software Engineering Daily, this has been Shelley Vohr and Josh Goldberg. Thank you very much for listening, everyone. Cheers. 

[END]