 All right, OK. I guess it's time to jump into things. Hello, everyone. Before we start, I want to say that I put a link to the slides here. You can scan the QR code up there. And also, I thought this would actually be a little more fun if there's an interactive component, because you've got the tables out, you've got the laptops out, you're probably looking at stuff. Something comes across your mind. I put a Google Doc up, a link to a Google Doc. You can just drop in there. And if you have a question asked, I could even go in after the fact, and we could fill stuff in. Just keep in mind, this is still part of the conference. The code of conduct applies. Don't be weird or anything if you go into the Google Doc. But feel free to ask any questions. My name's Jacob Groundwater. I'm the engineering lead for the part of the whole electron community. There's one particular, I'll explain it, but I run the, I manage the electron team under Microsoft. We were formally at GitHub. And we literally got rebased into developer division at Microsoft at one point. So I've worked in the Node.js space a long time. I like putting JavaScript everywhere. I've worked on all sorts of projects. I used to do performance tooling in Node.js. And when the opportunity came on to transition to electron, I jumped on it. Like many of you, I'm a web developer. Here's my personal web page. It's pretty tight. But it does get a perfect lighthouse score. So it's a PWA. You can install it, perfect performance, everything, load time, impeccable. So I really would love to talk to you about web performance. But I think today you'd maybe want to hear more about electron. So what I wanted to talk about was kind of what's the latest on how to do electron right? And I am not, I'm like the generalist in this category is. And I've actually gone out and talked to a lot of companies. I've heard how they're working with electron, what they're doing right, what they're doing wrong. I'm not the expert in any of these particular categories because there's wonderful, brilliant people on my team, speaking of which, that are actually the ones putting in all the hard work. So I want to credit them with doing much of the heavy lifting. And in fact, there's a much broader community than just my team. The reason I stumbled before on the part of electron I manage is we're open source. There's a governance that anyone in here could join if you put the time and effort in. And this is a slide from an online, one of the online meetups that we had during like COVID when no one was going anywhere. So we met on mirror, this is a mirror board, and we just did the conference online. So these people and more are actually the ones putting the work into electron. Here's a photo from our latest meetup in Vancouver. And you can see it kind of spans beyond my team. And this is multiple companies here. Like I'm at Microsoft. This is in the Salesforce building. We've got some people from a couple other places. Like we're all over the place. So anyone in here, you should feel welcome to join the community if you want to participate. And you participate like just as if you're part of the team. A long time ago, we just started opening up all our meetings to anyone who wanted to get involved. So the way electron works is very different from maybe another software project that you might have experienced. We're very open sourcey. Like everyone does a different flavor. We're very open sourcey. I wasn't sure what the familiarity with electron was for people coming into this room. And I'm going to kind of do a speed past the intro. There'll be a lot of things I neglect. I'm going to focus on the things that I think are worth pointing out. And the number one thing is that we are actually taking Google Chrome's project and building as if we're another target within Chrome. So instead of Chrome, when you hit compile, generating Chrome, it's going to generate electron. And electron, instead of just running web pages, like starts a little earlier in the process and gives you more control. You can set the menus. You can set the desktop icon. You can set everything. It's giving you the whole app. So and I think an important distinction is you're not just limited to the web. You have Node.js integration. You can do native Node modules. You could call native UI if you really wanted to. You could load other libraries. You could run Python if you want to go crazy. It's up to you what you want to do here. It's leveraging web technology. But a lot of people who use electron end up extending far beyond just the web components of it. And people who just walked in, there's a link down at the bottom to the slides. And you can ask questions in an attached Google Doc. Please do so. Let's go through the Chrome thing quickly. This is just Google Chrome. If you go to look up Google Chrome, this is their code online. I want to focus on all of these folders on the top. These are the folders that make Chrome. You go into them, it's like 10,000, so many files. And ours is on the bottom. And I don't know if you can see it, but this is our change right there. So we're just adding another folder in beside Chrome and presenting a new build target. So we're really almost a piece of Chrome in many ways. They won't let us put this into the Chrome tree, so we're kind of downstream of them. If you couldn't see it, it's right there. But this is how electron is built. So the people on my team, they're C++ engineers. They're working in the Chrome source all the time. They like JavaScript as well, but this is kind of the nuts and bolts of the electron pieces. It's really deep in there. OK, that's the overview. If you have no idea what electron is, this is my fault. There's probably a much better talk about that online. But I wanted to get to the important stuff, which is probably why you're here. And the number one thing when I go and start to talk to people about electron is they ask questions about security. So first, I'll say, yes, you should think about security, but you should read our security docs. They're really good. They're very comprehensive. And if you're wondering about any questions there, it's in those docs. And we have learned the hard way. So believe me, the docs are pretty comprehensive. A few things I do want to point out is, so sandboxing is a big topic. In electron, when you load a web page, Chrome actually uses the OS to sandbox it. And what that means is if there were a exploit. So every few months, it seems like there's some kind of exploit in the web, like an image format. And you get full control over the process that was loading that image. It could be just a website out in the wild. You don't want that website to have access to your system. So Chrome actually uses the OS to sandbox all these processes. We give you that as well. In fact, we've switched them on by default. You can turn them off if you know what you're doing. And many people do. But the sandboxing is the first thing I'll mention. And then there's other stuff too here that you can do to kind of layer and create a defense in depth when you're building your electron app. The one I want to maybe point out is really interesting. To me, I thought was this concept of fuses. So a fuse is actually a bunch of bits in the electron binary that we build. Because the build is not easy to do, we don't want you to have to do a custom build to enable or disable certain features because they might not be used in your app. So the fuse is a bit that gets flipped in the binary. It will disable that feature permanently. And then when the OS code signs it, it's off. And if you were to flip the bit back to turn it back on, the code signature will fail. The OS won't start the app. So I think that's super cool. That probably applies in, I don't know, finance environments or something where you might want to turn off what can get arbitrarily executed. So there's a lot of interesting stuff in fuses. But to be honest, if you're thinking about security, the best thing you could do for your app, whether you're shipping your app to customers, it's internal or whatever, is just stay as close to Chrome stable as possible. So this gets to, like, electron. Why is it electron at version 22? Why does it come out every 12 weeks? We follow the Chrome release schedule. And they have so many engineers. It's like 600 engineers working on Chrome. They ship a new major version every six weeks. That's a lot. That's a lot of code to ingest. And every week, our team actually takes the tip of tree on Chrome. So their master branch pulls those changes in and starts updating electron to work with it. And let me tell you, while the web has a nice stable API, the internals of Chrome have no stable API at all, like anything to break in any time. In fact, I'd say most of our user-related bugs come from this upgrade process. And we try to stabilize it as much as possible. And this is a big chunk of our work, my team's work, I would say, is just getting the latest Chrome to electron and to your apps. And the best thing you could possibly do for security features and everything else is just try to stay up to date. I'm going to be honest, this is the thorn. This is probably the worst part of using electron, because everything else, I think, works pretty well. But the upgrade process is a certain overhead. You just have to pay that cost. I'll just let you know. There's no way around it. I think you get so much back for paying that cost. But it's definitely worth putting the time in to just upgrade your app. There's a side benefit is the person who ends up upgrading the app often gets curious about open source. And then they want to contribute to electron, and then suddenly they're adding features for you. So you might think electron would be great if it just had this one extra feature, and then they're adding that feature for you. So I do think it's worth it. I think we have a pretty welcoming community. We have a lot of onboarding processes. There's a special slack for maintainers, and they will get the help they need. So I don't know, my pitch for the project. And then, like I said, by upgrading, you get performance-related benefits that just come naturally from the wonderful Chrome engineers. But another thing that's sometimes like a hot topic in the news is electron performance. And there's a lot to talk about. I think the reason why we make a lot of decisions, like electron always ships the whole binary with you. It's not a shared library. It turns out that that's actually what most people building off electron want. They want the code that runs to be the code they QAID. They don't want another version on the system that's kind of updated that they haven't tested. So this is the choice that electron makes, and I think it's going to stay that choice. But when I have gotten a lot of like CTO type emails saying, hey, we love electron. It's great, but, and then something's slow. So I'll meet with them, and then they'll be like, I want to connect you with our engineering team. So I meet up with their engineering team on a call or something. And like, honestly, I'm like, OK, tell me where it's broken, and then we can go fix it. And I get to the engineering team, and the first thing the engineering team tells me is, oh, it's some architectural decision we made like a year back, and we haven't had time to re-fix it. Honestly, a lot of the performance issues that people end up hitting are like, you have like 50,000 items in your React render tree, or some architectural decision you made a long time ago that because you want a new feature, you haven't had time to go back, or electron does have the functionality. I've literally had someone ask for a feature that we have, but they'd have to re-engineer part of their app to use it. So the request was like, can you just make it work with their decision from the past? I guess the point is, just follow like performant web app, like a standards measure, do perf tracing. You saw my wonderful website at the beginning. I can always give you some tips there. And this will probably get you far enough that you will now start caring about other stuff. However, there is one architectural decision I do want to go into. And I've seen this a number of times, and I want to steer you off that course. These are just dramatic pauses. So electrons multi-processed by design. When you start it, there's a browser process that begins. And then that does not show the UI. You have to start another process called the render process. And then as your app scales, components, serviceification, whatever, you might have multiple processes. So a really common pattern that I see in IPC is having these three processes, the main process. And you don't really want to do too much there, because it's driving a lot of the UI. If the render process that's running your DOM code, your React code and whatnot. And then people, because of security concerns, often want to sandbox that process, especially if they're embedding other content. There might be an iframe that links to some external stuff. So they want to sandbox it. And then what they do is they'll set up a utility process, and then they'll have things communicate. So the utility process might talk to your servers. Get the latest bank data or a video stream or anything like that, and then shuffle it over to the main process. And if you know about IPC, each of these processes has separate memory. So you have to basically copy data back and forth between them. So a pattern I see is right here, where we hit the render process and the utility process. And even if this utility process is written in the rustiest, fastest code, it's super snappy. At the end of the day, you still have to do this JSON serialization. And then shove it through this pipe to the browser process. And then that thing, in turn, shoves it over to the render process. And there are sinners in this room, and there are sinners out there that are doing this. And this ends up being a major bottleneck in a lot of performance designs that I've seen. So I want to introduce you to this one thing called message ports. This is actually part of the web API. And message ports are wonderful because they give you an IPC mechanism between these processes. But two things. Number one, instead of JSON serialization, they can actually send the objects across the wire using something called structured clone, just faster JSON. I don't know. That's all you really need to know there. And it's going to be way better than using JSON. Second is that message ports can be forwarded between processes, just like a file descriptor, if you've ever tried to forward a file descriptor between processes. So you don't have to do that extra hop to the browser process. You can just use this utility process, structured clone it across with a message port to the render process. And you can even pass things like array buffer data. So an example, if you did have that native code. So you had some native code that was going to do something and put like a video frame in an array buffer in a buffer in memory somewhere. And you want to get that to the render process. So write a native node module. Grab a pointer to the JavaScript array. Have your native code write to that JavaScript array. And then pass that buffer object to message port. That is going to be the fastest way to get that data over to your render process. And oh, I have. OK. So I'm going to quickly read this question. So I had a question, which is, is there any incentive in electron maintenance to reduce the latency of IPC communication? I would love to know. I think this is my motivation here. This is going to maybe solve your question. Another problem that I've seen in the past, however, is there are some IPC mechanisms in electron, like the no more mentioned remote module. The remote module at the time was a proxy object that represented an object in another process. And it was wonderful, because you could be like, requireElectron.this and do methods. And it would forward all of these calls over to the other process. And it was synchronous. And it was a nightmare. And it was terrible for performance. Never touch it. Don't use it. Pretend it didn't exist. That was a mistake. So this is like my one pattern that I just want to emphasize. OK, that's enough about IPC. Because I wasn't sure about the audience, I'm going to kind of move topics a little bit and mention Electron Fiddle. Because you're probably writing your electron app and then you do hit a bug, or you hit a regression. Actually, to be honest, there's going to be bugs. But regressions are really the ones that cost people money. Like, it used to work. Electron get updated, and now it doesn't work. Like, that's money on the table. Those we care about a lot. And the beauty about a regression is you can usually write a test. So Fiddle is an app that you can download from electron.js.org slash fiddle. It's kind of like JS Fiddle and all that. I hope it's not copyrighted. But it's a good way to learn Electron. And furthermore, you can upload the Fiddle that you create as a gist to GitHub and then paste that link in the issue tracker for us. And that's like, if you really want your issue solved, not only should you do that, but Fiddle has a built-in bisection tool. Fiddle can pick the version of Electron you want to run your test against. You just pick it in the drop-down menu on the top. And then you press play, and it'll run whatever you just had here as an electron app. So if you write your regression test and you use this bisection tool, you could even narrow down to which version of Electron this was and was not working. And if you post that to our issue tracker, that's like the front of line path. Have you had that front of line path at Disneyland? You're just walking past everyone else. They're all looking at you. You're going to go right to the front of the line. This is the easiest bug for us to fix. We get stack traces and things that it's like, OK, this reproduces, but it has to be a virtual desktop environment. And there's a proxy, like things we just can't reproduce. If you can give us one of these, you're just going to get your issue fixed. I'd almost guarantee it. So Fiddle is wonderful. There's also ways to learn Electron in there, examples. My advice to you would be tell your developers to check out Fiddle. So going back to the issue tracker, it is just the best effort environment. If you're just showing up to give us a bug or a request, we see it. Patience is appreciated on your side. But between upgrade duties and fixing the people who gave us bisected regression tests, we might run out of time. But feel free to reach out to me or someone else directly. But I just want to emphasize that the issue tracker is not treated as a Zendesk. It's just a place where we're recording stuff. So we do appreciate putting your issues up there. But if you there's no guarantees is the first thing I want to say. But yeah, if you can do a bisected regression, you'll be my best friend. So another thing that I've seen happen a lot, especially in corporate environments where they want a lot of control, is they fork electron. And there's a number of reasons why they do it. And you just shouldn't. OK, that's a lie. It's just a lot of work. And honestly, it's pretty costly, I think, at the end of the day. My recommendation is if you can, just talk to us. Like, you want to build but disable a certain component. And maybe we can add another fuse to the Fuze's API I talked about before. Or maybe you want to add a patch to Chromium. Well, maybe you could just upstream it to us. But honestly, it's kind of better if you use our electron. But I totally understand if you are forking. I would say, though, don't fork electron because you want to back port security patches to an outdated version of electron because you want to keep it on version from a year ago. It's probably more effort to do that than to put that same person on updating electron to the latest version. And then you get so much more. If you do go the route of hacking on electron yourself or you want to submit a pull request and add a feature, use build tools. Build tools is kind of our wrapper around Chrome's wrapper, around someone else's wrapper, around ninja files. But there's a lot of orchestration in checking things out, syncing things up, in environment variables, et cetera. But build tools is used by our maintainers every day. If there's bugs, they'll fix it. But use build tools as your starting place. Before you even check out electron-electron, this is the way to go. This is an added benefit. We have a distributed build system. And if you're just driving by, we're not going to give you right access to that because you're just going to mind Bitcoin or something on it. But we, oh wait, this is the finance conference. Yeah, whatever. But we will give you access to the read cache. So if you're building a latest electron, probably someone else has built the same version of that and you're going to start pulling in lots of those files. Because remember, we're doing the whole Chrome build with electrons. So it's just big. It's a big build. Some other cool stuff that I just want to point out is some upcoming stuff. So the views API, if you use this feature called a browser view, a browser view was getting more into native window widgets. So instead of everything being in one web contents, we're actually allowing you to put two web cons next to each other. If you squint your eyes, every chat app looks like a bar on the left and then something to its right. And before, that would have to be a React render or an iframe or something. This would give you the option of having two separate web contents there. And that would create more separation. And in some cases, make them a little snappier because the one on the left can load in an instant. So the views API is reaching more into Chrome's UI toolkit and giving you more direct access to native UI management. There's also a utility process API which simplifies that whole message port business that I was just talking about. So check that out. It's brand new. And that will give you those message ports set up. So in creating a demo for the message ports, I realize it was like a little clunky. And that's probably why some people don't use it. This should simplify a lot of that. Another item is we have, if you've ever used Node, they have an NAPI header that when you're writing a native Node module simplifies a lot of the complexities with trying to integrate with a version of V8 and Node. We have a proposed similar set of headers. That would give you access to electron internals and chromium internals. And the idea would be things that are commonly used. We want to expose in JavaScript. But people do all sorts of stuff. This is one of the reasons why people fork electron is they wanted access to something we haven't exposed in JavaScript. So the idea here would be, we will give you a header so you can write a native Node module to reach into electron. Then you don't have to fork. Then you don't have to build your own electron. So this should simplify this. This is new. This is proposed. If this is like lighting a bulb in your head, then you should definitely come talk to me after. Other things, Google has a project called Fugu, which is trying to take desktop features and bring them to the web. And I think they called it Fugu because that's the fish where if you cut it the wrong way, you die. So I guess the idea is that if you make this feature wrong, your desktop dies or something like that. But Webhid, Web Bluetooth, Web Serial, Web USB, these are all coming out of that project. And we are doing our best to maintain compatibility with all of that. So if you write against these device access APIs, they should work in electron as well. The other thing I'll mention is Forge. So Forge is kind of our build orchestration tool. To write an app, build tools which you already heard about is to maintain electron. Forge is when you write your app. And there's a lot of stuff that goes into writing an app beyond just like pressing Run and seeing the icon. You've got to build, bundle, sign, create installers. And then you want a different set of a different mode for development version than you do for production. So Forge 6 was completely revamped. And we're saying this is the one that's used by the maintainers. You should check it out. So Forge, Fiddle, just start there. That's it. That's the whole talk. I had one question going back to IPC. So I'm just going to read. Oh, sorry. So that's the main part of the talk. And I do have two minutes for questions. So if you want to ask questions, you have the link in there. I'm going to run back to IPC. So the question was about this. If I could go into more detail. And I would love to. I made four slides about this. I definitely want to go into detail about it. So if you have data in C++ and you want to get it into the DOM, there's only so many things you can do. If this is just like array of data that would be a video stream or audio or something like that that can be transferred as an array buffer, you allocate the array buffer in Electron like in JavaScript. You have to do it in JavaScript. You can't do it the other way. So you allocate an array buffer of however big you need in JavaScript. In your node native extension using NAPI, you grab the pointer to that array buffer in memory and then hand it to your C++ code and say, write the data right here. So it'll write it there. That data is now accessible in JavaScript. Pass that array buffer in JavaScript to the message port API, and it will just send it over as quick as it knows how. Under the hood, there's an IP library called Mojo that Chromium is using. And it's going to use that to send it the best way. I have no idea, but it's the best way to send it. And then you'll receive that as an array buffer on the other side. And you can pass that to whatever needs it. That could go directly to like a WebGL renderer or something like that or anything you need. If the data in C++ is structured, then you need to turn that into a V8 object before you can send it. So there are a bunch of tools here. I think the project in Chromium is called GIN. And that's a whole talk on its own. But if you look into GIN, that would be the way to go from a C++ object to whatever V8 object you're going to send. And you get the V8 object, you send it. It'll structure clone it over to the other side. So OK, let's go back to the end. And I'll say, thank you for coming. Pause. And if you have any questions, you want to chat. The links were all there. I'll be outside for a bit. But yeah, thanks, everyone.