 All right, I think we might as well get started. It's 11.20, we have 30 minutes, which is not a lot of time, so we're gonna get started. My name is Felix. I work at Slack as a senior staffer on Slack's runtime team, which is responsible for co-maintaining Electron. I mostly focus on outreach and education. The actual engineers are sitting down here. But I'm gonna talk a little bit about what Electron is, why it is, and we'll show a little bit of how you would build your first teeny tiny app. I'm gonna build a tiny code editor. It's not gonna be anything advanced, but just so you get a feeling for how someone would build something with Electron. And before we get into this talk, I usually want to motivate the whole thing a little bit, because one of the biggest concerns I have today is that there is this notion of JavaScript being inherently slow, or Electron apps being inherently slow. And I have this feeling that JavaScript today works a little bit like CGI, in the sense that it's bad when people notice it, but I'm convinced that most people don't notice in how many places JavaScript can actually be found. And I've brought just a few of my favorite examples. This one is the one that surprises people the most, but the user interface in Battlefield 1 is a TypeScript and React application. The little ammunition counter, that whole thing, it's all React. It's actually backed by MobX with about 1,000 observables. And the thing that I always like to point out here is that as someone who comes from native development, I've been beating this, we should do web technologies from for about 10, 15 years now. Obviously we're at a JavaScript conference, but there's this understanding that JavaScript is supposedly easier and maybe not as good as native technologies. I can assure you that the people working at DICE do know a thing or two about native development. They're quite good at building complex native applications. But there's a reason why they chose TypeScript and React to build a user interface, and that is that the web really is one of the best technologies we have today for building user interfaces that contain information. It's just really, really good at it, right? That's a very important point. And the other example I have is from a similar point of view, it's the NVIDIA GeForce Experience. If you have a Windows device that has an NVIDIA graphics card, you have this application installed. It comes with the drivers. And the NVIDIA GeForce Experience comes with not only web components, but also Node.js. Every single NVIDIA driver contains a version of Node.js. And it's used for communication between the GPU and applications and NVIDIA tools. So things like the NVIDIA in-game experience, where you can record things, all of that is handled via Node.js. And this is an interesting use case for me because we often talk about Node.js as being cross-platform or JavaScript being cross-platform. NVIDIA doesn't really necessarily care about all of that. It's just a really convenient way to write this kind of stuff. And again, I love this NVIDIA example because the NVIDIA people, too, have a whole plethora of coding languages to choose from. And it's not that there's a bunch of people sitting in NVIDIA and going, oh, we sadly only know JavaScript. If only there was anything else we could use. They've chosen this tool because it is really the best one for the application. And then lastly, the Adobe Creative Suite, which is sort of in the way that they designed their cross-platform solutions a little bit like the grandfather of Electron. Because the Adobe Creative Suite was one of the first applications that shipped with the Chrome content module and Node.js embedded. So every single time you open up Photoshop, Lightroom, Premiere Pro, any of those creative Adobe applications, you're opening up Node.js and Chrome. It's not the whole application, but they do power the plugin experience with those two tools. And the reason they did that is to allow plugin developers, including Adobe itself, to build cross-platform experience that can hook into the native experience. That was the idea, right? We didn't really have a solution for building semi-native code that could hook into the operating system and also build some kind of user interface for plugin developers. So they chose those two technologies. And then lastly, a few latest, a few latest came all the electron applications. There's a few famous examples that you may have heard of. Visual Studio Code is sort of our poster child. Slack is the one that I work on. But there's also ones that I find personally more interesting as an ex-Microsoft person. The install of a Visual Studio itself, the big Visual Studio is written in an electron application, which is one of my favorite stories. But there's so many other ones, right? WhatsApp, I personally built a little Windows 95 emulator in electron. There's dozens of applications out there. And chances that you're running an electron application on your notebook are actually pretty high. I just want to do this real quick. How many of you are running either Visual Studio Code, Slack, Microsoft Teams, Discord, or Adam on your device? Nice, cool. See, that makes us very happy. Isn't that exciting? So whenever you give this talk, and it's gotten better over the years, but it's certainly at the beginning, did I just lose the display? All right, that's gonna be difficult. What do we do? Any ideas? Do we have any AV people here? Yeah, yeah, they're coming. Yeah? There they are. Howdy. We just lost our presentation. Okay, cool enough, that was easy. Literally just press one button. Thank you. Okay, so whenever I give this presentation, the reaction isn't great. And it wasn't great before we started working on this electron thing. Before that it was Windows JS, this notion of running Windows applications and web technologies. But there's a real reason for why we're doing it, right? And the primary reason that I wanna point out is that most of the people working on electron and even the people using electron today would gladly choose something else. On electron itself, we have a bunch of native developers. The Slack runtime team is made up entirely by native developers who then learn JavaScript. We chose this tool, not because we didn't have anything else available, but because we tried everything else and everything else is terrible. There's really no other way to say that, which pains me, but especially if you wanna build a cross-platform application that is supposed to run on Windows 7 and up, which is a big one, Windows 7 was released the same year as the iPhone 3, which by the way had the headline feature of copy and paste and sending pictures via text messages. That's how all this operating system is. So if you wanna support that operating system together with the modern Windows systems and Mac OS and Linux, there really isn't much. And there certainly isn't much that doesn't require for you to build a bunch of native applications for each platform. So with that being said, what is Electron? Electron is a combination of three major components. The first one being the Chrome content module. This is in your head basically in an analog to Chromium, right? It's the anything Chrome deems necessary to build a browser minus everything that is Google specific. So no Google profiles, but everything you need to turn JavaScript, HTML and CSS into pixels. And then we have Node.js, the V8 runtime we all love dearly, right? And then we have a very thick layer of C++ around it. And this layer of C++ implements a bunch of APIs you might need to build a native application. Those are things like interacting with a native window object or sending native notifications or interacting with a touch bar, whatever you might need. There's a pretty thick layer of C++ that Electron comes with that allows you to do that cross platform. So how do you actually use all of that, right? That's the demo part. We're gonna do this little little Electron thing. And because Visual Studio Code is essentially a poster child, what I wanna do is I wanna tell you about Monaco Editor, which you might already know. It's very possible, but Monaco Editor is a thing implemented in Microsoft a bunch of years ago as Visual Studio Online, which didn't really work out and eventually became a part of Azure websites. And it was sort of this notion that in Azure you had a little pen and when you hit it, you could edit your website. Azure website itself wasn't the biggest success, but this little text editor was pretty damn good. And at that time, someone made this joke of, oh, if you put that in a window and give it to people, they're gonna use it. Which was a funny joke, but then they did it. So that's how we have Visual Studio Code today. So we're gonna do the same thing, right? This is how many electronic applications begin. They start as a website or a web application that is extremely powerful. And then eventually someone goes, oh, this could be an amazing desktop application if only it could do X, right? And X could be whatever you want because Node.js allows you to write in whatever you want. If you wanna write C or C++ or anything else, we have a lot of objective scenes like desktop applications. You can do that. You have native Node add-ons. But that's usually how it begins. In the case of Visual Studio Code, the most obvious thing that happened was this would be a great text editor if only it could read and save files, which is one of the basic features of a text editor, which in 2019 you can actually do with a browser, but certainly when Visual Studio Code started, you couldn't. Right? And if you think about the editor today, it has a native debugger, right? All kinds of features that you can't really do in a website. So let's actually do that and go through the motion. What I have here is the most simple of, the most simple of index files in index.js. And we're gonna start by turning that into a Node package. There we go. So now we have a package JSON. And in this package JSON, what we would normally do if we were to build a Node application is that we define the start script, right? And for most applications, that would be Node. Node is sort of the runtime that runs our JavaScript. Right? So when we execute this application with an NPM start, what happens is that Node reads our index.js, which right now only has a console log, and then eventually executes it. So to turn this into an electron application, the first step we take is extremely simple. We NPM install electron, which will install electron as a dependency. It's a fairly straightforward process. We download electron for your current platform. And then in the package.json, we replace our Node with electron. When we execute this application, with that correct writing on start, what happens now is that more or less the same thing happens. When you boot up electron, we start something called the main process, which to you might look and feel a lot like a normal Node process. There's one important difference. The first one is that you can now see electron down here. We are an actual application. And the other one is that the script doesn't immediately exit. But otherwise, this is basically Node. If you want to require Fs, you can do that. And you can use this, any given Node script will basically run here, right? You have everything else that you have normally available. And this is our main process. Once we've started this main process, we also boot up everything we need for Chrome. So those are typical things like the GPU process. And then eventually we can start additional renderer processes, which for us are Windows. So when you want to build a desktop application, one of the most important pieces of primitives you have is the user interface, the window that you're going to start painting things in. And the way electron solves that is that it should feel very familiar to anyone who's used to Node applications in that you already know the Fs module, you know the Utah module. We have one additional one that is called electron, right? So you can do this. And electron itself contains a bunch of modules. The first one being the app module and the second one being the browser window module. And those are the ones we're going to use for a second. So the application object allows us to interact with the application's lifecycle on your operating system. What I mean by that is when you start an electron application, this main process never has any user interface. It's always invisible on Windows. You don't even have anything in your task bar. But we also boot up a GPU process and various services and eventually those services are going to be ready and ready for you to start doing UI stuff. So we're going to say application on ready. We're going to do things now. And what we're going to do is we're going to make a window just like so. And now when we start this application, we get an empty window. Nothing super exciting here. In fact, if you open the developer tools, they crash immediately because they do expect some kind of content which is currently not present. But that's fundamentally how we open up a browser window. And we're going to start doing user interfaces here. But one cool thing about Electron is that we can combine the powers of node with the power of Chromium. So as specification, I can say web preferences don't integration true. And now it's the next step. I'm going to make an HTML file. Something small prepared here, right? It's a little HTML file that contains some very bare bones content. And then my index.js, I'm going to load set file. So that brings us one step closer to an actual application in that we now have a window. We have a dock icon and in the window we have actual content. But the thing that makes this very quickly, very interesting is if I zoom in here is that we have all of node available here including native modules if you want to. So if I want to read anything, this works. This is here in my window. So that allows you to combine the powers that you know from the DOM, CSS, with everything you know from node, right? So if you have a piece of native code, say SQLite or something, you can load that here. That actually works and you can combine those two things together. And what I'm going to do is I'm going to install monocle loader and monocle editor. These are modules that are normally consumed with Webpack or some other common.js and port turn into web stuff kind of tools. But I'm going to go ahead and add a renderer.js. And because in here, I already explained that we have node available. Speaking about Miles Universal JavaScript, I can just do common.js in my browser. That works because it's just node, right? I'm just doing node things here. So in here, if I do a quick console, console.lock.hello, we run this again. If we open up the console, you will see my little hello right there. So taking that one step further, let's actually start building our editor. Few things I'm going to do. I'm going to start by actually including the loader itself. And this is not electron specific. This could be any Node.js code. It's just that this is fairly simple and straightforward code. Therefore, good for demonstration. And now I'm going to get my diff. Constiff, document, get element by a D, container. And this is cool. You know how you sometimes need to do some canvas stuff in Node? And then you install 50,000 modules because implementing a canvas in raw JavaScript is kind of difficult. We have the full DOM available here. All of it. Whatever you need. So now that we have our diff, I'm going to create a little editor. And this is Monaco specific code. But what I'm doing is I'm saying, hey, dear Monaco editor, please create a new editor in the diff. Language I want JavaScript. And as theme, I want VS dark. When we start this, it's going to look terrible. But I'm going to do it anyway just so you see how terrible it looks. Looks like this. Little fin. Not a worry though, you know, like a good chef. I prepared some CSS. It's not overly complicated. What I'm doing is I'm saying no margins, no padding, no overflow. Make sure the editor itself has a 100% width and height. And then I'm using, I'm giving the container also full width and height of the viewport, which is an interesting point for me because depending on which browser that is a variable you couldn't use on your CSS. Viewport height and width is not crazy new, but if you consider supporting something as far back as IE 8 or IE 9 because you have an enterprise communication tool like Slack and you need to support enterprise environments, those values would not be okay. But since I'm shipping on browser engine, I don't really have to worry about that. And getting a new browser engine into an enterprise environment is a lot easier than convincing some super secure environment to install an entirely new browser. So we've done that and we can start this application again. And now we get something that looks a little bit like Visual Studio Code itself. Let's move this over here and this over here. And if I wanted to, I can now load my actual app in here. You can't zoom in yet. We didn't build the whole zoom thing yet. I can but I don't think it's actually gonna work. Oh no, it does. Just a keyboard. There we go. And believe it or not, this is pretty much the bare bones version of Visual Studio Code, right? Like most of the things we use in Visual Studio Code every single day are not available in this teeny tiny application. There isn't really that much more that people did. The first version added local loading and saving using the FS module, right? Just read it in, save it out. And more or less, that's everything that happened here. Which is an interesting point to talk a little bit about the challenges, right? I promised in the abstract that we would talk a little bit about what makes this difficult. And there's one very common pitfall that many applications fall into right after realizing all these powers. So what Electron essentially does is that it takes web developers and gives them all the powers of node or it takes node developers and gives them all the powers of user interfaces. Sooner or later, someone is going to have the really clever idea of doing all of that and then loading something from the internet, right? That would be a very straightforward process. It would be like, why do we even ship all our HTML? We could just load it from the internet. And that is probably the biggest challenge because that is a terrible, terrible idea. And that's a terrible idea because again, you have all of node available which has the same rights as you and it has a child process. And if you want to spawn things, you can do that. So the way Electron is used today by modern applications is one of two ways. The first one is the Visual Studio Codeway where you do actually ship all of the application code and you trust that code and you have node code that you trust, right? And then the alternative is a model that Slack is currently following where we do load web content but we don't really trust that web content. And we say, okay, this web content might have a write on two more than the actual, than in a browser but we control very neatly and very narrowly what kind of features are available there. And the way that is usually managed is that the renderer process and the main process can communicate via something called the inter-process communication module which is a little advanced and sometimes new for node developers and also web developers because most of us aren't actually used to multi-process coding, let alone multi-thread coding. But fundamentally, the idea here is that you sort of choose your poison, right? You either don't trust where you're loading and then you need to control what kind of things that application can do or you ship everything with your application and that is probably the biggest challenge. And now that we've built this application, the next typical step for people would be that you go ahead and try to turn that into an actual binary, right? And there's various solutions available for that. One of the things that is great about Electron is that tons of applications depend on it because tons of applications depend on it, the ecosystem is extremely rich. To date, there's more than 1,500 modules available to NPM that do something electron-specific and usually that thing is turn Electron into a certain application package, right? If you wanna ship your Electron application to the Snobcraft store that is available, if you wanna notarize it with Mac OS, that is available. And one of the tools that does it extremely well is Electron Forge as built by Sam who's sitting right there. So if you don't like it, please annoy him immediately. But what Electron Forge does is that it allows you to take your application and immediately turn that into a binary without having to worry about anything too much. It's very straightforward and very quick. So if you wanna see that in action, one of the applications I would recommend to look at is Electron's own little application called Fiddle, which also lets you play with Electron itself. Fiddle is sort of the thing that we just built except that we kept going. Fiddle is a little code editor that allows you to build little teeny tiny Electron experiments and play with them and you can check out various tools in there. So if you wanna see something like the desktop capture, which is a tool that lets you, just install Catalina, shouldn't have done that. There we go. Yes, fine, okay. Nothing is allowed anymore. Gotta ask for everything. So anyway, as I was saying, if you wanna see something like the desktop capture in action, you can run this little application and the desktop capture is broken, which we will debug later. But it's a little application that's not only open source. It's also using Electron Forge so you can sort of see how we turn this application into actual binaries. We do all of that in CI. Building a complete new version of this doesn't really require for me anything else in a little iPad. And it's also a little tighter and neater than Visual Studio Code itself, which is also open source, but might be a bit of a mouthful if you start there, right? Because obviously that application has been in the works for a while. All right, we have about five minutes for Q&A. If anyone has any questions, while we do that, I'm gonna leave this open. If any of you wanna get started with it and haven't yet, recommend Fiddle, recommend Electron.js. Fiddle also allows you to export your little experiments as a Forge project. So you can build something tiny, just export it as a desktop app. Send it to your parents, right? Which is honestly one of the big benefits if any of you write NPM modules, you can send your little NPM modules to your grandma and she can run it, which might be more difficult than NPM install instructions. All right, if there are no questions, you can find me on Twitter. You can find Electron on Twitter. You can also find many of us here today. So if any of any questions that you don't wanna ask here, just find us later. Thanks to you all for coming by. Thank you.