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, Mac OS, and Linux. Shelley Vor 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 Blue Sky, Mastodon, Twitter, Twitch, YouTube, and .com as Joshua K. Goldberg. Shelly, welcome to Software Engineering Daily. Hello, thank you for having me. Oh, well, thanks for coming on. We're really excited. You've been around on GitHub and in the web dev and C++ space for quite a while. Your name pops up on a lot of commits on GitHub. But before we get into all that intellectual, can you tell us who you are, how you got into coding? Yeah, absolutely. So I, as a kid, was always pretty interested in the way that stuff worked. So I really liked programming my calculator when I was in high school. And then when I got my first computer, I spent a fair amount of time trying to figure out how it worked, what I could get it to do, different ways that I could get it to not work. And then at a certain point, I realized that there was...
such a thing as programming languages that could interface with Mac. And basically, you know, felt like the horizons opened up as soon as I realized that I could make computers work in new and novel ways that I actually want to do beyond just how they worked. Could I make it like work within the bounds of what I thought existed? And then spent a bit of time doing that. I took a couple of computer science classes in high school and then realized pretty quickly that it was a career that I wanted. I basically see software engineering as, I don't know, basically just being able to solve fun, interesting puzzles that challenge the way that I see things, challenge my brain. And yeah.
That sounds great. Was it by any chance a TI-84 calculator that you were programming? It was indeed. Yes. It was a classic. Okay. So out of high school, you were taking software engineering as a career track. What was your first job experience? So after a freshman year of college, basically cold emailed a million companies, mostly in the Boston area, which is where my family is based to see if anyone would take me on, very little resume, a couple of computer science classes to show for it, and ended up getting lucky and got a really great internship with a small company called Embedly based out of North Boston. 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. And what did you end up doing post-college?
Actually, in retrospect, this is a little wild. So I interned at GitHub the summer before I graduated from college and I finished my software engineering internship actually about four to five weeks early. And then I had been interested in Atom and Electron for a while. And I asked the manager if it would be possible for me to basically like temp on his team just to see if I could, you know, make an impact last couple 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 straight around the team as soon as I graduated.
To recap, could you tell us what are Atom and Electron and how do those play into what is now called VS Code? Ah, yes. So Electron and Atom are both projects that came out of GitHub originally. A lot of people actually don't know this, but Atom came first. Electron was essentially made in order to enable Atom existing. Electron is a JavaScript framework that enables developers to use web technologies to write desktops on different operating systems and have them all work similarly across them. And Atom is an editor that built on that. That's one of the canonical examples of Electron now.
Yes, it has since been sunset, but it was basically the first major use case for Electron. Originally, they were part of the same team. And then later, Electron was split out into its own team once the team realized that there was quite a lot of interest in the use cases and the opportunities that Electron enabled. So you're not a JavaScript developer, nor are you a pure C++ developer. What are you? That's a great question that I've struggled to answer a lot over the years, actually. Probably the closest thing to the skill set of people that work in 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 or back end? I'm like, I don't know with that. I have no idea. Both? Neither? Secret third thing?
Yeah, a lot of people view there being a single linear access from front to back or back to front. But you and I, we work not really in that access. There's a separate access of dev tooling, you know, from the machine to what people actually interact with. So do you see yourself as even aligning on the front to back end? Are you some different spectrum? Yeah, I think I would agree with you that it's not really like my job doesn't really exist along that access. 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.
So before we get into what you do with Electron and how one becomes a principal engineer in that world, I want to talk a little bit about the how Electron works, because it's actually kind of fascinating. Is there a 30 second overview or one to two minute overview that you're comfortable giving of this giant project that you work on? I will do my best. So as I kind of originally said, Electron is a framework that essentially enables you to write desktop apps using web technologies. However, it is actually ultimately a fair amount more complicated than that. Electron's proposition is essentially to mix and match native and web as you see fit and as your use cases demand.
So for example, you could, you know, use Promium's UI capabilities to write a desktop app where, you know, everything you're kind of looking at is JavaScript, CSS, HTML, and then, you know, you have a bunch of native node add-ons that you farm out to different native libraries, capabilities that you wouldn't be able to access using either to enable really kind of a whole broad range of use cases that were pretty hard to access and 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. Yeah, a lot of folks, when they think of a JavaScript or TypeScript app development cycle for something like an editor, they, 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 on Chrome, right? Yeah, so a small example is Apple maintains a couple of APIs that are all in Swift. So if you were writing a web app or 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. OK. Let's say I have an app built in Electron, like a VS Code. How does that get built and distributed to users, given that you have to support Linux, Windows, Mac, and all sorts of other platforms?
So there's a fair amount of tooling that exists in the ecosystem for doing those things, depending on what it is that you need. But yeah, at its core, the general Electron team maintains a few of them. Electron Forge is one. That's typically the one that we've maintained more effectively. Although there's several other lovely libraries in the ecosystem that we try to support where we can. You touched on tooling. And then because this is audio openly, I want to say that there is this wry kind of joyous look on your face that came up. You work in tools day to day. So one must imagine that the tooling built around Electron, built around VS Code is rather impressive. How do you support your work? Are there any tools you want to shout out in particular?
This is a great question. As someone who has unfortunately spent so much time in Electron 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 a small enterprise-level tooling. So almost everything that we do, we have thought about what automation support we need, what number of developer hours that we can 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 2FA access to be able to approve the release by OTP. All of our backports are automated to release lines where possible. Failures are surface to engineers, you can then do manual backports. But on average, it's about a 10% shearer for every stable line going back one. We've also done a lot of those metrics over the years. So we do know, actually, to relative specificity, exactly how effective our automation is and how well it's serving its stated purpose. There's a joke about software engineers that we will spend.
10 hours of effort to automate a one hour task. If I was on a web platform team for a company and heard or felt gripes or pains about some tasks that could be automated, how would you advise I determine whether it's worthwhile to automate that task or to keep doing it manually? Great question, actually. So I think the thing that's interesting within the Electron project itself is that there aren't really like... I'm not really answering to someone who's telling me what features I need to implement or what bugs I need to fix in the same way that I think I would if I was on a closed source intro Microsoft team. 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 risk reward calculus, I suppose? Because ultimately, the only one that ends up kind of losing if I make a mistake is me.
Because, and like community in general, I'm automating something that doesn't really matter at the expense of fixing like 10 bugs and 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 it solving? Is what I'm doing actually solving that problem? Is it solving a symptom of that problem? Is it just up the wrong tree entirely? I don't know. But that is something that I think at least I can kind of sense now enough.
Developers are notoriously pretty bad at doing cost estimates or time estimates for tasks. But is there a one particular metric you think has worked well for you in developing that intuition? 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? I'm worried. No. Okay. So basically, it's extremely hard to tell the gender of chicks. And there's professionals that are trained for thousands and thousands and thousands of hours to be able to tell the gender of chicks when they're so young that you can't.
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. That's so fascinating. Yeah, sorry. It's kind of a curse metaphor, but I promise I was going somewhere with that. And ultimately, I think that like, to be honest, I don't really know that I could say because I think it's just been enough years and like I've had enough evidence to accumulate and form the patterns in my mind that I just kind of like know sort of without being able to necessarily describe in super deep detail, like how I can look at, for example, like a bug and electrons 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 days, putting off like basically short, medium, long term, mental task list. Okay, thank you. That's an interesting tidbit right there, chicken-saxing. But I want to take us back a little bit towards the technical side, because I'm sure a lot of listeners are fascinated, as am I, with how Electron works. So from the tech stack perspective, you mentioned there's Node in there, there's Chromium. Can you tell us, are you using Chromium directly, or even what is Chromium, and how is that playing into the whole system? So I mean, Chromium is fundamentally almost an operating system.
I think there is a misconception that every single Electron app ships with all of Chromium. 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. 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 API they 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. 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 Electron? No, you as the end user, unless you're using native Node add-ons, would really only ever be interfacing with the JavaScript layer that we expose as proper APS. Gotcha. 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 munch 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 than Node itself is actually using, whatever version that is being shipped in that version of Electron. So we actually often interact with ways in which V8 requires changes to Node before Node does, which has led to some fun afternoons of debugging. Has that ever benefited the Node project, taking learnings from you and shoving them into Node earlier than they would have happened? Yes, actually. I typically try to upstream anything that comes up. Although Node actually also does a lot of great work around that. 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 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. 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? 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 a wild crash or an error that looks innocent, but actually belies something far more interesting and records 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. Have people tried to change the code since you wrote that? Not really. Because I think that as soon as I say something like three Apple bugs in a trench coat, people are like, you can deal with that forever. Yeah.
I do a lot of macOS stuff in Electron. So usually if it's like frightening and macOS related, it becomes my problem. That sounds exciting indeed. But OK, 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? So it sounds like you're asking me essentially like how we communicate between.
the browser process, and then renderer processes. So essentially, Chromium is a multi-process architecture. There is one browser process, the main process, and then it's a one-to-many relationship, many renderer processes. There's also a concept of the utility process, which is a different thing. I could go into more detail about it 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. 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...
change you made in the renderer, then you'd use what's called IPC, Interprocess 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 preemptively, like I said. I think in my head, I've always kind of conceptualized Electron is it's really just like a big toolbox. You can bolt on whatever you want to it. And then whatever ultimately emerges from that that your team decides to write or create is a property of how you've architected your app, the decisions you've made.
what, you know, 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. So we've already mentioned Adam and VS Code editors, which are rather large and complex examples of what you can build with Electron. Is there a good just after the hello world example of an app that you would give as an example of something someone could build with Electron? Good question. I think it's hard because it really just like is so much.
I guess this app is not super simple, but there's a lot of apps that I use all the time that I don't necessarily know for Electron. 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 Getify. It's a GitHub notifications app that lives in your menu bar. And I think it's a pretty good example of a 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 and understandable and gives you a decent idea of what Electron lets you do. Sure.
Which brings up a good point that because it is air quotes here, just JavaScript or just the browser or Chromium, you can use things like React, right? Like there are plenty of, although VS Code itself isn't built with React, there are plenty of apps that are built on Electron or similar web technology where the code base is virtually the same or extremely similar to what you might find in a browser app, right? That's really interesting. That's a good cost-coding measure, right? For teams, if you want to build an app, if you want it to run, say, in the browser and on your desktop, Electron's part of what makes that possible, right? Yeah, which actually kind of leads me to, I think, another thing that a lot of people don't really recognize about Electron, which is that Electron is at its core, not something that like solves a use case for everyone.
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 may be better served 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 skill sets that a lot of your engineers probably already have because a lot of developers have world development skills. But at the same time, if there is a difficulty in, say, getting something to work on the web or a difficulty in getting something to work with JavaScript, that would impact your app no matter what you write in, whether it's Electron or the browser or other JavaScript environments, right? Yeah. Cool. Day to day, there are a lot of apps that folks use that are known to be an Electron, like VS Code. And you mentioned there are quite a few that aren't. Are there any particular apps that you use that a lot of folks know that are surprisingly written Electron, the way you mentioned Getify is? 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. It's written in Ceph, which is the Chromium embedded framework, which it's like a similar framework that lets you embed Chromium to make a desktop app, but it is not, in fact, Electron. Trying to think of a couple others that people might know and or use. I don't know.
Is Notion an Electron app? Yes, actually. Notion is also a great contributor to the Electron project. Oh, shout out Notion. Thank you for that. Do you find that a lot of the bigger companies that write apps in Electron end up contributing back to the project? 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 small scale, something we really appreciate is when companies who are, you know, having issues or whatever using Electron write really good bug reports, show up with really interesting information, do a little bit of research on their own. That's super helpful to us too. Sometimes you get issues and they've done like a little deep dive into, okay, this is the investigation we did.
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.
For the interest of 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? 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 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 want. But just to pick one, the releases working group is responsible for releases of Electron. So if you were 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. DRI. 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 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. 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?
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 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 I said, tiny enterprise. like a small team doing things for like a pretty surprisingly big scale. Do you have any idea how many different apps or is it thousands, hundreds, thousands, millions of users you have of Electron? It's 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 a hundred thousand. That's pretty great. Yeah. 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. There 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? Would you like to talk about how people have voiced concerns around Electron's performance? 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. It 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 a lot of people don't recognize is that our whole team, generally speaking, would 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. Yeah. There are a few bad words in open source, quote unquote, winning or competitors. Why are those bad words in this context? 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 use 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. Yeah. And I don't think anyone else on 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 performed 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. 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? I mean, fundamentally, I think the biggest difference is that Tari requires that you write Rust, which is a lesser had 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 type of company that would really benefit from writing their app in 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 it's supposed to either. Do you often get bug reports about how this wrench is not performing very well as a hammer? Sometimes.
We've done some real wildfire 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. One struggles to imagine what that use case is. Yeah.
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 EA, 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? So I'm going to actually shout 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 being able to have control over the distribution security and stability of the platform than it is that you're shipping.
So shipping with, for example, the system of use 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. 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 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 what potential vulnerabilities it might have, you take steps to mitigate them, et cetera. Where I think if you're using 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 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. I think one of my favorite use cases for something like Electron is when you have a performance critical thing, which isn't necessarily a game or rendering engine. 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. 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. 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 allows 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.
Most of the people who are really suffering in the idiosyncrasies of various operating systems and their foibles is us. Yes. I mean, there are some like, you know, various APIs within Electron that we exposed 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, 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. Are there directions or investment areas you're excited about for Electron for the next two, five years? Good question. Really kind of a...
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 like halfway done or like 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 coming 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 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 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 can find the most documentation and research for.
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? 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, our 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 it's important we continue to maintain as a team good relationships with our upstream dependencies to make sure that we are capitalizing on those to deliver a really good experience to be using Electron.
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. 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 barely 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, you know, if you as a company, you're 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.
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, 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 analogy here? 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 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 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've 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 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 you 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. Ta-ta.
Great. You're the one busting through the wall yelling, oh yeah, and providing people with Kool-Aid. Honestly, yes. 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, Shelly? 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 conline 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 community of people communicating with each other and, you know, evolving the language as it's used in practice. A classic example of a conline 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. See, that's fascinating because there's so many parallels between how we write tools for developers or build dev tools and languages versus how things develop that serve non-programming utilities in real life. There's a great quote from Andrews Halsberg over from the C Sharp 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. 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? Honestly, no. I think I see that as much more positive than a downside because I think like, I don't really want to build the perfect thing with no users. Like, I think it's really interesting to, you know, 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 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 haven't considered because it's a different lens that 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 like ultimately no one person, no one team is able to possibly have all the contacts 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. That sounds like one of the core skills you have to develop an open source, being able to have empathy and invite people to bring their own opinions. Yeah, I definitely got 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 might 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. That's a very positive outlook about getting yelled at online by programmers. 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.
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? 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 like 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, like 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. Never before has this been observed. But great. Speaking of who you are, Shelley, we're out of 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?
I'm Codebiter, everywhere online, C-O-D-E-B-Y-T-E-R-E. Most people think that's Codebiteri 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 a need 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, Blue Sky, what have you. Yeah. Great. Well, for Software Engineering Daily, this has been Shelley Boer and Josh Goldberg. Thank you very much for listening, everyone. Cheers.