 It's usually where I put it, but is it? OK. OK. All right. Welcome to this talk. I've added this little disclaimer for desktop, because actually creating cross-platform applications is relatively easy if it's web or something like that. So I've added that little disclaimer. So I think looking through some of the other talks in this track, including the last one, the dream of kind of writing code once and then multi-using it, multi-purposing it in different applications is nothing new, nothing new at all. Yeah, the talk previously covered a language debt or a framework that you can use for that. This is kind of the first instance I've found of this quote, but I don't think it's new. And in fact, 1995 even seems too recent to me. But of course, I guess from the same company, one of the first sort of big attempts at this kind of right once run mostly everywhere with little adaption was Java and still is, really. And also, of course, languages like Python and many others. I mean, it's not a new concept. And then again frameworks. These are just one, there's also things like Xamarin, Flash, Flex, B4J, Zojo, many others, come and gone. But I guess kind of the thing with a lot of them is they always required you to learn something new. So maybe a new type of language, maybe some new variants on the language, some new paradigms. They were never completely easy to get started with. You had to sort of learn something first. But it's always been a dream to accomplish. Basically I guess because a lot of developers are kind of a bit lazy and we'd rather focus on something else. And kind of, I guess, where I sort of start this a little bit is electron to me. I'll explain what it is soon, but you probably know already. But to me, it seemed a little similar to Apache Cordova. I actually encountered Apache Cordova when it was still Nitroby phone gap, which ages me slightly. And it was the same principle. Write HTML, JavaScript, run it on multiple platforms in the same sort of way. Have like some native wrappers that fill in the missing pieces. And the code that you write once can run on multiple platforms. It still is a similar principle, although on mobile, starting to become less relevant actually. But it's kind of a similar principle. And I would probably argue it was an inspiration for Electron as well, I guess, because it does a very similar thing. So, enter Electron. What is Electron? I've alluded to already. It's a framework for writing JavaScript, CSS, HTML if you need it, to make cross-platform desktop applications. It has some other similar rivals in inverted commas like NJWS. But for some reason, Electron has just sort of become much more popular and much more widespread. It could be because it's created by GitHub and lots of people know GitHub. It could be the people who decided to use it. It could be that the level of integration with the native platforms is better. I'm not really sure. I'm not going to cast any kind of judgment on that. But I think we could argue that it is certainly much more popular than the other alternatives. So you've probably used it without even realizing. If you've used any of these applications, plus many others, you're using Electron. Slack is always controversial. Some people say it is. Some people say it isn't. They sometimes say it is. They sometimes say it isn't. But I'm pretty sure it is. It's hard to say exactly. I guess my first interaction with Electron was Atom. I really love Atom. I use it almost all the time. And to be honest with you, I probably know much more about Atom than I know about Electron, actually. This will be a moderately introductory talk to Electron. I think I actually know much more about Atom. So, it is from GitHub. JavaScript is a desktop application. Version 1.5 was released last week, and it is moving quite quickly. In fact, when I first did this talk, a version of this talk last August, it only just got to version one, I think. So in a few months, it's rating quite quickly at the moment, and improving quite a lot. We'll come back to that in a minute. So, as you would sort of expect, being a JavaScript framework, installing is pretty straightforward. NPM install, or if you're a Mac user, Castroom, which, I don't know, just a slightly different way of installing it to end up with pretty much the same thing. And you end up kind of with a command line tool, so you also end up with a binary here as well that you can actually drag and drop your code onto to run it whilst you're testing, mostly. You can also kind of use this to package your applications at the end as well. And much as it's a cross-platform tool, then actually most of the options are applicable to every platform that you develop on as well. So that's kind of what happens when you open it. The screenshot is slightly out of date. And then, if you're a CLI user, it's pretty much what you'd expect. Just run the command. I'll show you a demo application, then I'm going to kind of show what it does. So I have a very simple application here. This is running an atom. We're creating an electron application in atom. This is getting very matrix. So it comprises a couple of basic different things. A package JSON file with dependencies. Unsurprisingly, one of the main dependencies is this electron. A main JavaScript file that contains your code. And then kind of where all the magic happens in this app folder. So I'm just going to run this first and we'll see what it does. It's very, very interesting. A Wi-Fi allowing. There we go. It loads the Marvel Comics API, which is a terrible API to use, but really fun to demonstrate. And actually, if I didn't have do not disturb on, you'll also see that I got a notification as well. I got a system notification as well when everything loaded. This is a web application, but as far as we can see, actually I have left developer tools on. So you can see it is effectively just Chrome-ish application there. And that's pretty much it. Particularly interesting in this application. We also have the default icon. Can't quite see, but down here. So just to break down those files a little bit. The main JS file, which we'll have a quick look at in a minute, starts the application and creates the browser window to render the HTML and sets up kind of the basics of the native bindings. And the index.html is the web page that is rendered by default. So the main file is probably the most interesting one, requiring setting up the application window and the browser loading the default file. I haven't really changed anything from the default application that you create here. You can see there's a little bit of custom code for Mac OS because when you close the final window in a Mac application, you want to quit the application. I mean, you could actually uncomment that, but the whole point is making it feel as native as possible on each platform. But really, that's the only platform-specific thing there. And also in here is where you can add things like turning on the developer tools on and off or setting up actions that can happen in menus or the dock icon or start icon or I'm not sure what the launcher, whatever it's called in various Linux distributions, the kind of interactions you can make with the application from the operating system. And that's pretty much it. If you've done any JavaScript, it's all pretty simple so far. And this is kind of almost a disappointing thing with an electron talk. It's actually really simple. There's not actually much to it. It's just JavaScript once you get past that file. So, yeah, I forgot dumb thing there. There we go, yeah. We already had a look at that, sort of jumped straight into the code instead of the presentation. So, great. That's during development, but how do we get it to actually look like an application at the end of it all? This is called packaging it. There's a couple of different ways you can do it. The first step you do is create an Assar archive, which is actually basically making it not look like it's just JavaScript. And I'll show you how this works in a minute, but that's what I can't exactly remember what it stands for, but that's what you create first. It copies the files that are needed, rename and distribute it. And these are kind of the steps you can go through manually, or my preferred option is to use one of the third-party tools, and there's two of them that kind of do all this for you. And up now comes a pretty lengthy-looking command. So, this is another NPM module that it's not necessarily official from the electron team, but it's highly recommended. Now it's got worse. So here we set the location of the code, we give the application a name, we set the platforms and the architecture, and you can just do all, and it will package for 32 64-bit Linux, 32 64-bit Windows, 32 64-bit Mac, if there are any 32-bit Macs anymore, I'm not sure. Or you can do all. We can set whether we want the ASAR archive or not. We can prune some of the NPM dependencies where it goes. We're just saying overwrite it if it's there. Most importantly, an icon file, and this is probably where it gets the hardest for cross-platform because every desktop OS has a slightly different format for their icons. So this is specific to Mac, but you kind of have to have something for each one to make it look the most native thing. So I'm going to run this and show you what happens, and everything's vanished up the top there, but that's okay. So, fortunately I have auto-completing there. I don't have to type that all again. Hopefully this is going to be fine. It takes a little bit of time, not too long. In the older versions of this, you have to specify the electron version as well. You can still do that if you want, but you don't have to anymore. We'll now just find the most appropriate version as well for you. And here is the final output there. Looks pretty authentic. I am using copyrighted material here. And again, it will look kind of the same. There was a notification again, which you can't actually see because everything seems to have gone up the top. But you can't see my menu bar, but now all I have is a quit option. So maybe I'll just try that one out. It's a little bit cut off, but you can see I don't have the toggle developer tools or anything like that. And there's no way if I'm right-clicking, I'm control-clicking. I can't get anything there. Now it looks like a proper application as far as everyone is concerned. So, what are some of the things you can do? You can get notifications. We saw that it's using HTML5 notifications that get routed through to the notification system of the operating system. I have tested this on Mac, on Windows, and on three varieties of Linux. And they all go where you expect, which is actually quite cool, especially on Linux because notifications can be quite inconsistent. And they all let go in the right place, which is good. You can get things like recent documents on the Mac OS that can be right-clicking on the dock icon on Windows and Linux. I think the same. You can create your own custom menus. This includes, as I say, like a dock. And in Windows also you can add things like you can right-click on a folder in Windows and say Open in an application. So setting up those associations and things like that. Also presented file is something you can do in Mac OS where you click the top document icon and it will show you the folder structure of where the file is. That also works, things like that. You can create preferences and all sorts of things. And the one thing I will actually say since I kind of lasted this presentation and have been using Windows and Linux a bit more at work, as with a lot of JavaScript frameworks, often the Mac support was better than anything else and the Windows and Linux lagged behind a bit. And the recent updates have actually made that a lot better. Some of the slowness, some of the rendering issues that used to be in some earlier versions actually are a lot better now. So they've been focusing a lot more on making it truly cross-platform, not cross-platform but better on one. So that's quite nice. Negatives. Application size is one. Actually going to show you something interesting here. And you can do equivalent on every other operating system. You can see for a relatively simple application, 110 megabytes. If I crack that open, most of it is... There is it. I've lost it. Where is it? Most of it is that file. The Electron Framework. 107 megabytes of that. 110 is the helper. When I last did this presentation, it was 175 megabytes. So it's actually got a lot better. And these are desktop applications, not mobile. So it's a compromise. There's compromises everywhere. This is the thing that's doing a lot of that magic. And I don't have the actual numbers for other operating systems. But it will add a fair bit of overhead there. But it's not too bad. But yeah, like 95% of the application is one framework file. So that's one problem. CPU memory performance, again, used to be a lot worse. If you've used Slack, then Slack used to traditionally be pretty poor at, especially, network and CPU overhead. That, again, has got a lot better with recent Slack versions and recent Electron versions. I argue that a lot of the reasons that Slack, especially, is so unperformant is you have about 15 channels or with requests open. So that's, of course, going to cause quite a lot of overhead. But even with Atom, for example, on Windows and Linux, still opening takes a fair bit of time to open. I mean, if we think about how long it takes to open compared to applications from five years ago, really it's nothing. But it is still a little slow to get started. And I still get some rendering issues every now and then, things like that. But it's getting better. Of course, one of the main negatives is it's still not native. It does a pretty good job, but it isn't. So you do lose a lot of possibilities for optimization and APIs that are available in the kind of proper development frameworks that aren't available. But again, a lot of those are being patched up quite quickly. And there are some platform inconsistencies, as I already said. Again, getting better, but still there. I guess you offset that with the fact that JavaScript is relatively easy to get started with. A lot of people know how to write it. And you can effectively write some reasonably complicated applications, like, for example, Nihilas. The mail application is a fully-featured email client. Atom is a fully-featured text editor. Pretty good applications. Unless you're writing a new Office Suite or something, it will cover a lot of use cases that you might have. So you can offset some of those performance issues with the time saving. And I think the other thing is Electron has kind of become the victim of its own success. It has become so popular that every person and their dog is now writing applications that are basically just websites in wrappers. And you get a lot of bad applications. But that's kind of another issue, really. That's a little bit of a problem. I love things that lower the barrier to entry, but, of course, it allows more stuff to be made as well, which may be inconsistent. But I suggest you give it a go. Some of the Getting Started guides are a little hard to follow, I would say. I'm a documentation person, so it's kind of the thing I always keep an eye out for. But give it a go and you can make applications for everybody relatively easily. That's me. I'm actually slightly out of date. I'm actually a technical writer for a company in Berlin. And if you're interested in documentation, I'm doing another talk at 4.20 very soon on automating documentation. No one likes to write it. How can you get more of it to be written for you? And if you like my chinchillas, you can go to my website and buy t-shirts, or you can download the SVGs and do what you like with them. But thanks very much. Any questions? I have a few. OK. Does it support PHP in any way? The question was, can you use PHP, or I guess other languages behind the scenes to kind of generate? I mean, I would say, in theory, yes. But the main process is still a node process. And you would have to somehow figure out how to bundle those dependencies as well. That would probably be the main. So that one big file you were talking about would also then include the PHP part? Yeah. And I don't know how the user would end up having a lot of running processes that they're not necessarily aware of as well. Yeah. That's the only thing to bear in mind. It's an interesting idea. I kind of know why you'd want to do it. But yeah. It's like web development. Without PHP sounds kind of alien to me. Node does a lot. OK. I think the guy at the back was just there slightly earlier. It shows a framework file, which was quite big. Is there a possibility to use this in a generic way? So multiple applications may have the same framework file? So the question was, with the framework, can more than one application use it or can you customize it in some way? Multiple applications accessing it. I'm not 100% sure. It probably depends on the operating system. But for example, the Slack application, which is at least based around Electron, isn't as big. And it's reasonably complicated. So, oh. OK. It used to be smaller last time I looked. I don't know. It used to be smaller last time I looked. But still, that is smaller than it could be. So I think, and if you crack that open, it's slightly different inside. So they've done something to streamline it a bit. So yeah. Yeah. I think you could probably strip out the bits of the framework you're not using and things like that. Yeah. Yeah. Yeah. I've done a lot of work with ChromeGap. Yeah. One of the things about that is, generally when you run a ChromeGap app, you don't really make a web-deployable version of what your work model is, a phone-gap app, and that's what it is. Is Electron kind of like that in the same way, or can you say, like, your main.js? Yeah. Can you make Electron like a progressive enhancement? OK. So the code base is kind of... Yeah. I'm going to say yes and no, because based on examples I've seen. So for example, oh, sorry. So the question was around, like, progressive application development. Can I make a website version that is basically the same as a desktop version, et cetera? Whereas with PhoneGap, you couldn't really do that. So for example, if you look at Slack in the browser and Slack on the desktop, it looks pretty much the same. But I have hung around in... I wondered the same thing with Atom. I thought, hey, could you make Atom on the web? And the forum post there said no. So... So it depends what you're doing. Yeah. That's the point. It depends what you're doing. Yeah. We're doing a file system. Yeah. Browsers won't give you that. Yeah. So in theory, yes. Because I'm pretty sure Slack is basically the same. There's a few extra preferences you get in the desktop and they do vary per platform, like what you want to do and things like that. But I would pretty strongly say yes and that's kind of the point of it as well. Yeah, second question. Okay. And then over here, yeah. Size of the bundle. Yeah. Is that largely due to the fact that each time you... Every package, you have an electronic package you install to the second version, and so... Yeah. And is that a version number that you're like aware of? So this is one of the attractions for the company is that I can say, okay, I know exactly what the browser target is. Whereas on the web, I don't get that. I have no idea what it's going to get. Yeah. So the question was, can you specify the Chrome version? Because actually then effectively you have more control that you do on the web. Again, I haven't tried it, but I have seen discussions around that. And I don't see why you couldn't. I think it would be my encouraging answer to go and look. Yeah. Can you talk a bit about sort of the magic that Electron does maybe when it comes to file access? Maybe down things to add to something. I know one of the weird things we're trying to get around was sort of exposing files and sort of interfaces to the app from the native part. So we had different solutions, maybe like Electron can. Yeah. So the question was about file access. And so as far as I'm aware, because using Atom for example, I have not noticed any restrictions. I get recent documents system-wide. I can access all the things I would expect to have in my macOS that I can do with native applications. I can do. So for whatever magic is happening, it's giving me full access. How exactly that works. I'm not 100% sure. But you do get full access. Yeah. Say it again, sir? Rather than native models. Through not native models? Yes. Yeah. You can have access to native libraries. Ah. Okay. So you're saying certain system-wide libraries? Yeah. Okay. Maybe because you can, for example, services, which is a sort of mac-system library, you can access. So some you can, some you can't. And it's probably just because no one's written the bindings yet. Not because it's impossible. Oh, it has it, I guess. But, yeah. Any... Okay. Can you execute system commands from the application? Yeah. Oh, well. The question was, can you access... Can you execute system commands? I'm going to say yes, because in Atom you can. In Atom, you can actually edit the init script to execute system commands. So... I've done it. It's possible. Yeah. So I would say yes. And another question, yeah? Yes. Oh, yes. You said in the beginning that the code versions evolve quite quickly. Yeah. How does that affect your existing code? It's like, apart from 1.3 to 1.4, is that going to break your code by definition or is everything guaranteed to still work in the next version? So the question was about breaking changes between versions. I'm not 100% sure about breaking changes, but for example, I think 1.3, 1.4, for example, fixed a lot of problems with rendering on high-resolution screens. So it's often, there seem to be mostly introducing new features that you have to take advantage of as opposed to breaking old ones, probably because it's still quite new, but I'm sure at some point there will be... They will start breaking things. At the moment, I think it's mostly just improving, improving and probably not taking much out, but I'm sure at some point something will start breaking. But again, it's NPM, so you can specify the version. So maybe time for one more. I was wondering about any security issues that could be spoke. Did you, for example, in the web, would have always the danger of access to the tags injecting scripting in the web? Yeah. As of this library can access all the files in your system, do you think there is any measure to mitigate that? Yeah. So the question was about security. To be honest with you, I don't have an answer. I feel like that would be a very obvious question everyone would have had. So I feel like there's some kind of sandboxing going on. I'm not 100% sure. I would say check the documentation because it seems too obvious not to have thought about it. In some way, shape or form, although it's probably going to still be a little less secure than, well, badly coded applications are still going to be native or not. But yeah, I'm not 100% sure. But I mean, probably the most dangerous thing immediately is just taking over your system a bit from performance. But I would say check the documentation. I'm pretty sure there's going to be something covering that. Thanks very much. As I say, ElectronJS.com