← Software Engineering Daily
Software Engineering Daily
Electron and Desktop App Engineering with Shelley Vohr
00:50:59
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 Node.
Loading summary
Transcript119 lines
- [00:00]
Josh Goldberg
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 code base to run on Windows, macOS and Linux. Shelley Vohr is a principal software engineer at Microsoft where she works on electronics. 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 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 Bluesky, Mastodon, Twitter, Twitch, YouTube, and dot com as JoshUakGoldberg.
- [01:20]
Shelley, welcome to Software Engineering Daily.
- [01:22]
Shelley Vohr
Hello. Thank you for having me.
- [01:24]
Josh Goldberg
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?
- [01:37]
Shelley Vohr
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. And then at a certain point I realized that there was such a thing as programming languages that could interface with a 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 like work within the bounds of what I thought existed? And then spent a bit of time doing that. Took a couple 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.
- [02:42]
Josh Goldberg
Then yeah, that sounds great. Was it by any chance a TI84 calculator that you were programming?
- [02:47]
Shelley Vohr
It was indeed, yes.
- [02:49]
Josh Goldberg
Those were classic. Okay, so out of high school, you were taking software engineering as a career track. What was your first job experience?
- [02:58]
Shelley Vohr
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, 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 of North Boston. It 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. And ultimately, I think that really set me up well for what I ended up doing post college.
- [03:56]
Josh Goldberg
And what did you end up doing post college?
- [03:59]
Shelley Vohr
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 Adam 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 of 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 strutted on the team as soon as I graduated.
- [04:41]
Josh Goldberg
To recap, could you tell us what are Atom and Electron and how do those play into what is now called VS code?
- [04:46]
Shelley Vohr
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.
- [05:12]
Josh Goldberg
And Adam is an editor that built on that. That's like one of the canonical examples of an Electron app.
- [05:17]
Shelley Vohr
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 or once the team realized that there was quite a lot of interest in the use cases and the opportunities that Electron enabled.
- [05:34]
Josh Goldberg
So you're not a JavaScript developer, nor are you a pure C developer. What are you?
- [05:39]
Shelley Vohr
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. So 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? I'm like, I don't know what that I have no idea. Both. Neither. Secret third thing.
- [06:33]
Josh Goldberg
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 axis. There's a separate axis 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?
- [06:52]
Shelley Vohr
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.
- [07:13]
Josh Goldberg
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, how Electron works because it's actually kind of fascinating. Is there a 30 second overview or a 1 to 2 minute overview that you're comfortable giving of this giant project that you work on?
- [07:31]
Shelley Vohr
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 to like 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.
- [08:26]
Josh Goldberg
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 what you're describing, like file system access being a native app, that's a different style of use case than just open a new tab in Chrome, right?
- [08:45]
Shelley Vohr
Yeah. So a small example is Apple maintains a couple of APIs that are all on 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 and then using your app, call out to the swift only APIs and then leverage them within your app.
- [09:06]
Josh Goldberg
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.
- [09:16]
Shelley Vohr
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.
- [09:36]
Josh Goldberg
You touched on tooling and then because this is audio only, I want to say that there was 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?
- [09:53]
Shelley Vohr
This is a great question as someone who has unfortunately spent so much time in Electron Bodland 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 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 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 two FA 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. So like we do know actually to the relative specificity like exactly how effective our automation is and how well it's serving its stated purpose.
- [11:31]
Josh Goldberg
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?
- [11:49]
Shelley Vohr
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. So 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 the community in general. I'm automating something that doesn't really matter at the expensive fixing like 10 bugs, then I'm just getting yelled at 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? What 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 solving these. 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.
- [13:08]
Josh Goldberg
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?
- [13:20]
Shelley Vohr
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, 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?
- [13:34]
Josh Goldberg
I'm worried no.
- [13:35]
Shelley Vohr
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 are 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.
- [14:00]
Josh Goldberg
That's so fascinating.
- [14:01]
Shelley Vohr
Yeah, sorry, it's kind of a curse metaphor, but I promise I was going somewhere with that.
- [14:05]
Josh Goldberg
Yeah.
- [14:05]
Shelley Vohr
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 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 10 minutes, and then make like a snap decision on whether or not it's worth me doing then putting off till the next couple of days. Putting off like basically short, medium, long term mental task list.
- [14:42]
Josh Goldberg
Okay, thank you. That's an interesting tidbit right there. Chicken sexing. But all right. 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?
- [15:05]
Shelley Vohr
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. That 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 like sub directories, 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. We 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.
- [16:23]
Josh Goldberg
But you do ship multiple runtimes, right? You mentioned both JavaScript and C. Like if I have an app, am I writing both JavaScript and C when I'm writing stuff in electronics?
- [16:34]
Shelley Vohr
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.
- [16:41]
Josh Goldberg
Gotcha.
- [16:41]
Shelley Vohr
You can bolt 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, so we actually only ship one. And then we essentially have Node patched to use a more recent version of v8. The 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.
- [17:25]
Josh Goldberg
Has that ever benefited the Node project? Taking learnings from you and shoving them into Node earlier than they would have happened?
- [17:30]
Shelley Vohr
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. 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 onto the issue tracker for the fork and not notice it.
- [17:52]
Josh Goldberg
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. APIs 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.comsed to learn more. What is an example to you of an exciting crash in node or V8 or those areas?
- [18:43]
Shelley Vohr
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. Very simple example or not simple. The actual bug was awful. But like 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 3ish 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 Mac OS 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.
- [19:47]
Josh Goldberg
Have people tried to change the code since you wrote that?
- [19:50]
Shelley Vohr
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. Yeah, I do a lot of the macOS stuff in Electron, so usually if it's like frightening and macOS related, it becomes my problem.
- [20:06]
Josh Goldberg
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 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?
- [20:34]
Shelley Vohr
So it sounds like you're asking me essentially like how we communicate between the browser process and then render processes.
- [20:40]
Josh Goldberg
Sure.
- [20:41]
Shelley Vohr
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 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 specific. So 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'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. 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 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 as 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, you know, a property of how you've architected your app, the decisions you've made, what you know, security considerations you've taken in, like, 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.
- [22:29]
Josh Goldberg
So 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?
- [22:43]
Shelley Vohr
Good question. I think it's hard because there really just is so much. I guess this app is 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. But like one that I like a lot and have contributed to a little bit over the years is Yetify. 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.
- [23:28]
Josh Goldberg
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? Like, there are plenty. 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 cutting 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. Electron's part of what makes that possible, right?
- [23:58]
Shelley Vohr
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, like the type of team and the type of company that would really benefit from writing their app. And 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 web development skills.
- [24:40]
Josh Goldberg
But at the same time, if there is a difficulty in say getting something to work on the web or get 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:55]
Shelley Vohr
Yeah. Cool.
- [24:57]
Josh Goldberg
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 Electron, the way you mentioned Getify is.
- [25:11]
Shelley Vohr
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. It's probably not Electron, I don't know, but it does predate Electron and 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.
- [25:49]
Josh Goldberg
I don't know, is notion an Electron app.
- [25:52]
Shelley Vohr
Yes. Actually Notion is also a great contributor to the Electron project.
- [25:56]
Josh Goldberg
Oh, shout out Notion. Thank you for that.
- [25:58]
Shelley Vohr
Yeah.
- [25:59]
Josh Goldberg
Do you find that a lot of the bigger companies that write apps in Electron end up contributing back to the project?
- [26:04]
Shelley Vohr
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. So even like 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 their own. That's super helpful to us too. Sometimes you get issues and they've done 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 should you 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.
- [27:15]
Josh Goldberg
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?
- [27:21]
Shelley Vohr
Sure, yeah. So 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 we're working groups you are a part of. So 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 wants, but just to pick one. The Releases working group is responsible for releases of Electron. So if you are in that working group, then you are responsible for an issue triage rotation, that is a weekly rotation. You're responsible for all associated ecosystem apps around releases. So the release automation flow that I described earlier in this call, that would fall under release purview. Generally speaking, for every release there's a release captain. So one person is designated as the kind of DRI for that release, making sure that all direct, responsible individual. Oh, thank you for making sure that release gets out on time. Making sure that pull requests that should be in that release go out in that release, making sure that all other general bookkeeping is done, release notes are correct, the blog post is published, any other kind of, you know, related tasks that need to get done for every release. All of this information is also public. In case anyone's kind of 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.
- [28:46]
Josh Goldberg
I'm struck listening to this how in some and perhaps most ways it is kind of 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?
- [29:11]
Shelley Vohr
Yeah. I mean really? Yes and no. Like I said earlier, we do genuinely kind of operate like a tiny little enterprise in terms of just the scale of our tooling, the scale of a lot of what we've kind of built, the way that we've architected it for non community members. So 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. 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. So I do honestly think it really is a little bit more of like a, like I said, tiny enterprise, like a small team doing things for like a pretty surprisingly big scale.
- [30:09]
Josh Goldberg
This episode is sponsored by Mailtrap, an email platform developers love go for fast email delivery, high inboxing rates and live 24. 7 expert support. Get 20% off for all plans with our promo code sedaily.
- [30:26]
Do you have any idea how many different apps or is it thousands, hundreds, thousands, millions of users you have of Electron?
- [30:33]
Shelley Vohr
Really hard to say the exact number of like total apps that are written with it. But I do actually maintain or like help maintain within Electron just like 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.
- [30:50]
Josh Goldberg
That's pretty great.
- [30:51]
Shelley Vohr
Yeah. Cool.
- [30:53]
Josh Goldberg
For the rest of the interview, I'd like to 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 like 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 around Electron's performance?
- [31:21]
Shelley Vohr
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 like, wanting to maintain a position of quote unquote dominance, or like 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 COVID this in a bit more depth, the first of which is, is I. 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, will be 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. Like, I enjoy working on Electron because I think that it's like 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 like working on something just to work on it or for something to exist just so that I can say that it does.
- [32:59]
Josh Goldberg
Yeah, there are a few bad words in open source, quote unquote winning or competitors. Why are those bad words in this context?
- [33:06]
Shelley Vohr
I mean, I think a lot of people really see it as like a zero sum game. Like I've had some conversations with people over time where they're like, I used Tari and it was awesome. And my response is like, awesome. Cool. Like, what was it like? I have no interest in you using Electron if Electron does not solve your problem.
- [33:24]
Josh Goldberg
Yeah.
- [33:25]
Shelley Vohr
And I don't think anyone else in my team really does either. Like, it's really cool that you, like, used another framework that, I don't know, had potentially a smaller bundle size or perform faster along the happy paths of the app that you wrote. Like, that's cool. I have no issue with that. Like, I don't really see any of those things as, like, a competitor that I have to, like, I don't know, kill or whatever.
- [33:48]
Josh Goldberg
Yeah. Neighbors rather than. But that is a good point to bring up, actually. Thank you. Tari and other apps. What is different between, say, the way Electron does things versus, say, Tari or, like, other equivalent CEF in the area?
- [34:00]
Shelley Vohr
I mean, fundamentally, I think the biggest difference is that Tari requires that you write rust, which is a lesser hab skill set than web development primarily. So I think that the type of person that would really benefit from writing their app in Tari is very different than the type of 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, like, start, like, whacking away your nail with, like, a wrench. Like, I have no interest in that. I don't think any of the rest of us do either.
- [34:39]
Josh Goldberg
Do you often get bug reports about how this wrench is not performing very well as a hammer?
- [34:43]
Shelley Vohr
Sometimes we've gotten some real wild bug reports, just, like, over time about people that are like, it wouldn't work for my absolutely wild, esoteric use case. And, like, 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 submenus of my menu with itself 300 submenus, the performance is bad. And I was like, don't do that. Yeah, shouldn't be doing that. I have no interest in solving this use case.
- [35:14]
Josh Goldberg
One struggles to imagine what that use case is.
- [35:17]
Shelley Vohr
Yeah, cool.
- [35:19]
Josh Goldberg
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 quote unquote, just using these systems built in browser or JavaScript runtimes? Is that something that is doable in Electron or any of its equivalents?
- [35:43]
Shelley Vohr
So I'm going to actually shout out to Felix again here because this came up in the 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 being able to have control over the distribution, security and like stability of the platform that it is that you're shipping. So shipping with, for example, the system webviews removes actually quite a lot of agency and control from you as the app developer in what it is that you're shipping, what versions of it that it's relying on, et cetera, et cetera. So at least that I can kind of conceptualize it and have. 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 are able to make sure that like you have pulled in all relevant security backports, that your app is written in a way that like, you know, potential vulnerabilities it might have, you've taken steps to mitigate them, et cetera. Where I think if you're using, you know, a system webviews 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, 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.
- [37:10]
Josh Goldberg
I think one of my favorite use cases for something like Electron is when you have like a performance critical thing which isn't necessarily, you know, like a game or rendering engine, it's just, you know, 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 like 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, you know, perfect bundled performance concerns. Maybe you can just throw it up in a web page.
- [37:38]
Shelley Vohr
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 the skillset 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 like might not look perfectly native on every single operating system to having no app at all.
- [38:00]
Josh Goldberg
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. So in a sense, Electron 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.
- [38:21]
Shelley Vohr
Yeah, most of the people who are really suffering in the idiosyncrasies of various operating systems and their foibles is usually, yes, that's you. I mean, there are some like, you know, 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 are certain APIs and concepts and, you know, paradigms that just only exist on certain operating systems and you know, it is what it is. But no, yeah, generally speaking, if we are doing our jobs correctly, that shouldn't be your, as the developer, your problem.
- [38:56]
Josh Goldberg
Are there directions or investment areas you're excited about for Electron for the next two, five years?
- [39:02]
Shelley Vohr
Good question. Really kind of also 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 like halfway done or in development. It's something that a lot of big name companies have been using for many years. So I think ultimately one of the big 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, you know, we can reach out and figure that out kind of as we go. Generally speaking, you know, our general concerns are always the same, which are 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, you know, talked about a fair bit and actually made a lot of changes. About within electronics Electron in the last four or five years is to make the intuitive choice, the simple choice, the easiest choice. So it shouldn't really be the case that if you're developing a new app that you're like accidentally foot gunning on some security horror when like that is the easy thing to do, if that makes sense. So that's actually a big part of why we got rid of the remote module. It's now no longer bond 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 could find the most documentation and resources for.
- [40:29]
Josh Goldberg
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?
- [40:40]
Shelley Vohr
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, like what our security recommendations are, performance recommendations, et cetera, et cetera. But Chromium has 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 upstream dependencies to make sure that we are, you know, capitalizing on those to like to deliver a really good experience to people using electronics.
- [41:12]
Josh Goldberg
One last callback 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.
- [41:31]
Shelley Vohr
So 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 itself faster. Which is generally speaking, I think a pretty good example of how Electron, you know, if you as a company are kind of sitting there going like, 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. Like, 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.
- [42:25]
Josh Goldberg
Let's use that analogy or metaphor since you've mentioned liking them. A lot of people see software as either a traditional restaurants 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, right, where the host provides some baseline amount. But if you really want to improve things, you can have to bring your own food. Is that an accurate metaphor or analogy here?
- [42:54]
Shelley Vohr
Yeah, I think really the difficulty for different open source projects is less like, is it an open table or not? Versus I think a lot of people have difficulty figuring out what the like manner expectations are of that table of that restaurant, quote unquote. 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 like both have a place in terms of the culture that you want to, you know, 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 done, we tried to do a fair amount of work to mitigate that over the years. There's a repository called Build Tools that 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 has 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 works 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 gotta 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 need 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. Like, I really just, at this point, don't only have that much of a problem being like, hey, it's me, here's my pr, here's what it fixes, here's why you should merge it. Thank you, Tata.
- [44:54]
Josh Goldberg
Great. You're the one busting through the wall yelling, oh, yeah. And providing people with Kool Aid.
- [45:00]
Shelley Vohr
Honestly. Yes.
- [45:02]
Josh Goldberg
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?
- [45:11]
Shelley Vohr
So I have always kind of been interested in, like, 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, you know, 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, you know, a community of people communicating with each other and, you know, 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 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.
- [46:35]
Josh Goldberg
See, that's fascinating because there's so many parallels between how we write tools for developers or build dev tools and Langu versus how things develop that serve non programming utilities in real life. There's a great quote from Anders Halsberg 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. So 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, like English evolved because people kept using it in certain ways. Do you ever feel frustrated that all the tools we're building, Electron, Tori, 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?
- [47:23]
Shelley Vohr
Honestly, no. I think I see that as much more of a 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 than we're looking through as we're writing the framework. So 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. Like eventually you're just going to kind of hit a wall of like how good quote unquote, you can make it without the external input of people that are breaking it, essentially.
- [48:16]
Josh Goldberg
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.
- [48:23]
Shelley Vohr
Yeah, I definitely gotten yelled at online a lot over the years, but like, ultimately, like, I don't. I mean, I don't know, maybe this is a hot take or something, but like, I don't really mind. I mean, obviously I mind if they're like really rude. But like as a concept, if you're like, oh, you did this thing and it like totally screwed me over, that's useful for me. Like, 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? Like, new problem, new thing to solve, new use case to consider.
- [48:48]
Josh Goldberg
That's a very positive outlook about getting yelled at online by programmers.
- [48:52]
Shelley Vohr
I mean, to be fair, it helps. Like, a lot of people who yell online just have a lot of misconceptions about the way that Electron works. And so I don't really. It's very easy not to take certain things personally, you know, I don't know.
- [49:05]
Josh Goldberg
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 emotionally relevant to us. Are there any particular criticisms you or Electron have received that you find to be most amusing or poignant to you that you want to share before we get.
- [49:24]
Shelley Vohr
Yeah, I went accidentally viral on Reddit like 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 screenshotted it and put it on Reddit and then it ended up going kind of viral. And then like a bunch of people mailed it, like, next did 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.
- [50:00]
Josh Goldberg
Never before has this been observed.
- [50:02]
Shelley Vohr
Yes, but. Great.
- [50:02]
Josh Goldberg
Speaking of who you are, Shelly, we're out of time. Are there any particular places you'd suggest people go to find out more about you or the Eleshron project or the folks around it?
- [50:10]
Shelley Vohr
I'm codebiter everywhere online. C O D E B Y T E R E Most people think that's code codebytery 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. So it is Codebiter, but I am codebiter everywhere online. Twitter, bluesky, what have you. Yeah, great.
- [50:39]
Josh Goldberg
Well, for Software Engineering Daily, this has been Shelley Vore and Josh Goldberg. Thank you very much for listening, everyone. Cheers.