Write once, run everywhere is not a myth
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Krishnan, Mahesh
Prieto, Cristian
Web, mobile, and cross platform desktop applications have generally required writing the same application more than once. Up until now, that is... In this session, Mahesh Krishnan and Cristian Prieto, Microsoft MVPs from Australia show how you can write a web application, and use the same code to run as a native desktop application - all with just a few tweaks. They will start with a simple web application using HTML/ReactJS and then using Electron native, will run it as cross platform desktop application that can run in Mac, Windows and Linux. In case you wondering, this is how Visual Studio Code and GitHub's Atom were written.
 I think we've come to the last day of NDCN. I think we've all got a little bit of brain overload and you got a good lunch as well. So I think we've both in an undeniable position of trying to keep you guys awake for the next hour or so. So good luck to us. How many of you, before we get started, how many of you have actually are writing web applications right now? Okay, it's probably about 80% of the audience, right? How many of you write desktop applications right now? Okay, not a lot. Okay. Now wouldn't it be cool, right? And wouldn't it be cool if you could actually write a desktop application and then use the, you know, leverage the power of the desktop, access system menus, use the system tray, and access files from the file system, and, you know, even do low-level things like accessing a serial port, for instance. And while doing so, you just use your existing web skills that you already have, but the 80% of the audience are already doing, they've already got web skills. Wouldn't it be wonderful to do that? And that's what this talk is all about. We're going to talk about how you could actually write a desktop application using your web skills. We actually write it once and hopefully you can actually run it as a desktop application. So the title of our talk is Write Once, Run Everywhere, is not a myth. And we're going to talk about this wonderful technology called Electron that we're going to be using to show you how to do it. My name is Mahesh Krishnan. I work for, as a CTO in a company that writes software for the health industry down in Australia. That's right. I'm here from Australia down, all the way down from there. And this is my co-presenter, Christian Prieto. He works as a technical lead. Now I'm going to let you know a secret. Now Christian actually hates being called an architect. So at every opportunity I get, I introduce him as an architect to people. No, no, no. So I'm actually being nice today. So introduce my technical lead, Christian. Yeah, yeah. Without any offense. But in Australia, most architects don't quote and I quote. That's the difference. Right. So if you really want to know him, right, call him an enterprise architect and I'll set him off. Anyway, so what we want to talk about today is we want to talk about, but electron. More importantly, I want to talk about, I want to talk about why, why electron? Why do you want to use electron? What is the use case for it, right? And then we want to give you a bit of introduction on what electron is and then we'll show you some of the existing code that have been written using electron. And then we'll move in and talk about, maybe we'll give you some of the design considerations. You know, in our journey, what are the things that we actually found out and hopefully some of the steps can actually help you when you decide to make the move to electron itself. So first thing, of course, is what is the problem that we're trying to solve? I mean, a lot of cases, what actually happens is that, you know, you find this new shiny tool and then you say, oh, this is awesome. This is really cool. I need to use this for everything. And it almost seems like a hammer, right? This new tool is your hammer and every problem that you actually see seems like a nail and you just want to hit with the hammer. So we want to, I want to do things in a different perspective and try to say, hey, what is the problem that we're actually trying to solve? What is the business problem you're trying to solve? And what is the solution from a technological point of view that we can actually offer? What are the right tools for it? As I said earlier, I work for a company that writes software for the health industry. One of the software that we already have is an application that is used by doctors, general practitioners, nurses, and so on. And the thing is, you know, it's about 20 years old. The people who actually use it love this application. However, we've got a couple of problems. First thing is it's actually written in Delphi or Delphi. How many of you actually write Delphi nowadays? Anyone? There's one person, right? One person. So you can actually imagine if we want to go and fix things in the Delphi application, we can't find anyone to actually do it for us. So, I mean, we've got to have a technology refresh just for that alone so that we don't have any technical debt. The second thing, of course, is this application has been written 20 years ago. So, it is pretty old. And although some of the users love it, we need to come up with a much better modern user interface and things like that as well. So, we need to change this application. So, what do we do? Well, we'll rewrite this application. And of course, you know, what do we do these days? We'll put it up on the cloud. We will sell it as a software, as a service application. And so, what do we do? We write it as a web application. It sounds great. However, there are a lot of constraints that we already have. First and foremost, like I said, we are all from Australia. Anyone been to Australia over here? It's a few people. I mean, if you guys didn't know Australia's bloody big country, right? It's huge. And doctors, some of these doctors actually go to some of these remote areas to service people. And, you know, sometimes they actually take a couple of days to get there. Yeah, there are areas that it takes three days driving without anything around, things like that, just to see 9,000 patients. Yeah. And in fact, we have the royal flying doctors who effectively fly over to actually get to some place to actually see patients. And when you go to some of these remote areas, the biggest problem that we have is we don't have network coverage. So, all this grand idea of you're going to host this up in the cloud is all gone because there is no network coverage, right? So, we want to have almost like an offline application that you can actually take and wherever you're going. But we want only to write it once. We want to write a web application and then half as well at the desktop application. Yeah. That's the bigger challenge. Yeah. And the other thing that we want to have is we almost also work in what we actually call as a LAN party mode, right? So, it's not like one doctor that goes there. A number of people with medical practitioner will go and then we want to connect to a single server and then do things on that single server through multiple desktops connecting. And we want to make it discoverable and so on and so forth. So, we need to discover where the services and so on. So, we have that requirement as well. And what else do we have, Christian? What are the other constraints that we have? Any other testing now? Oh, yeah. Yeah. A run out of batteries. Yeah. There's no electron or offline things for this. Yeah. We have other problems and the biggest was I have to go and interview the developers doing this application. And the first thing what I asked them is what is your background? All of them, their background was web development. Yeah. So, they was the first struggle. I'm struggling coding in Delphi that I have to learn Delphi and all this stuff. Yeah. But the thing though is we really needed a desktop application, right? And some of these doctors also said, hey, we would like to run it on a Windows machine as well as a Mac. And so, which effectively meant we needed a cross-platform development. You know, web skills or not, we really wanted a cross application that is a cross-platform. And just going into cross-platform development, you know, if you start looking at how we've done it historically, if you go back into the 80s or pre-80s, people used to write applications in C and C++. They would write the application once in CRC++ and then compile it on a different platform and you could actually, you know, you could run it on the various platforms. But you know, when a lot of the windowing environments actually came into core, like when you had Windows and a lot of GUI platforms that you had to write to, a lot of this didn't work well. It worked really well in the console application, but didn't have the right graphics libraries. And so, I mean, they are still available and people still do it, but it's a lot more complex and a lot more difficult to do. And then of course, in the 90s, we had Java, right? Java was going to fix all our problems. It's going to be completely cross-platform. You could write Java and then you had this wonderful world of AWT and applets and so on. Did anyone write applets over here or any of that stuff back in those days, right? And that died pretty quickly, I think. I mean, we still use Java now, but more on the server side, but not on the client side at all. I really like to know how many applications are being written in Java on the client side now. Probably not a lot. Of course, then we moved on to the last decade and of course, we had this, you know, pretty much a lot of people wanted to write applications in web, write it on a browser, it's cross-platform kind of, but it didn't have that rich interactiveness. So, we had this new set of applications called RIA applications, or rich internet applications, and which effectively was all flash and cellulite. Anyone write cellulite applications over here? Like, well, a few people. Okay. Well, I actually wrote a book to actually help people learn cellulite, right? And that book, I'm sure, is, you know, those books are probably lying in some dumpster somewhere because that technology died pretty quickly. And the reason why it actually died was because HTML5 came about and it could do a lot of things that you couldn't previously do on browsers. And of course, you know, you had the mobile phones revolution. I think when Steve Jobs introduced the iPhone, and that was the first nail in a scoffing, right? That was the beginning of the end for a lot of the flash and cellulite and so on. But, you know, moving on to this decade itself, you know, smartphones, everybody wanted to write applications for smartphones. And again, you kind of like wanted to write, like, you wanted to write cross-platform applications for the smartphones. So, you wanted to run it for Android, you wanted to write it for iOS, and you also wanted to write it for the one or two Windows phones that are still around. But, and you used things like a phone gap and Xamarin and all that. But all these are more focused on the mobile phone. If you come back to our use case, we want to write a desktop application. So, how do we actually go about doing this? And so, you know, of course, I turned up to Christian and said, hey, Christian, what can we actually do? And what does the answer you gave me, Christian? And what I said to Mahesh is, let's write it in an electron. Let's do it in an electron. Which kind of like brings up the question, like, what is electron? Well, electron is an open source project. It was created by GitHub and was just to solve a very simple issue. They wanted to create an editor to be able to give to, you know, edit code and things like that. But an editor, think about that, is has to run in a machine and has to have, like, all the native integrations with the computer, with the desktop itself, not a computer, with the desktop. So, it's basically what you do is that you host a web application inside a shell app. Right. So, that sounds like, you know, that's effectively like a web control. And we always had web controls before. I mean, you could host a web browser control in a WinForms application or a WPF application. I could actually understand that. It just works quite easily. But we really wanted a cross-platform application. So, if you wanted to run it on a Mac, that would still be a problem. But of course, you know, you had Xamarin. You could run it on a Xamarin application and you could host a web browser control in it. But so, what's the problem with that? I mean, you could just do that right. Yeah. There's like plenty of problems with that. And that was the first approach because it was, oh, so basically it's just a browser, you know, in a browser control. All of us are used that. In fact, a very, like, funny story. One of the other projects that we work on, when I was looking at the UI that the developers did, it's like, oh, these controls are really nice, which we WinForm because it's a WinForm application, which WinForm provider, like control provider, are using. And it's like, oh, no, what we did is that we put a UI, a web view and write everything and generate HTML and that is the UI. It's like, well, perfect. But the difference is that when you do that, you are just basically constrained. You are in a sandbox. You cannot do a lot of things, right? And it's still the problem that is very difficult interaction between what you have inside that web view with outside the web view. For example, adding menus and things like that. You can do that, but that will be the code in your C sharp application. It's not going to be the code written in your JavaScript application. Right. So we have two problems, right? One is, you're writing two applications. One is the web application that you're hosting within that browser control, right? And then you're another application that you're writing that actually hosts the container, if I can call it the shell. That's all got all the menu items. And then there's no seamless integration between these two applications. If you wanted the web application to do something on the desktop, it's really hard to do it. Right. And from the desktop application, you can maybe trigger changes to web pages and things like that. But you don't have a very refresh, but you will have that. It's just basically putting a web browser there. Electron is not like that. Right. So, but why electron? I mean, there have been other applications that have actually come and gone, right? I mean, for example, Microsoft have something recently that is the web apps or something like that. Yeah. Yeah. Yeah. Yeah. The web host applications. Yeah. The web host applications. Yeah. It's exactly the same mechanism. Right. But what about running JavaScript applications or rather, you know, something similar to electron where the shell, you know, there was a product called, was it Node web host or something like that? NWS. Yes. Yes. Or something like that. Yeah. Yeah. They basically the same. Yeah. They have difference and things like, they have, they have difference, but it's like compare, react with Angular. I don't want to go into that world. Okay. So, we've actually gone, there have been other technologies that actually do the same. And, but tell me a little bit more about, about this itself. Well, the first is that electron is cross-platform. Right. It started as just a Mac platform stuff, but it's now cross-platform. It has native bindings for many operating systems. Well, the three major operating systems, Linux, Windows and Mac. Right. But it's feature-rich. The integration with the desktop itself is very, very good. You can integrate with things like the menu bar, the icons that you see, create batches for those icons in stuff that you have in, in, and you can write your own stuff to, for example, do more integrations with the desktop. For example, the progress bar in Mac when you are downloading something can be easily writing. It's web technology. It's not like the web control that we were talking before because here you write your application in JavaScript. It's just basically your JavaScript application with HTML stuff. You can use all the libraries that you used to, to use. You can use all the Node.js packages that you have over there, all that rich set. That is a lot. That opens a lot of possibilities. Right. And one of the nice things is that it actually already comes packaged with the Chromium web browser. So, you don't have to worry about. You don't have to worry about that. It's another problem that you have with the web build controls. You cannot control that. In Mac, it's going to be just the web kit that they use for Safari and in Windows, it's going to be Internet Explorer. Right. So, yes, we still have that problem. Here is a web browser that you already know. Okay. And of course, you have access to a whole set of NPMs. Everything that is in NPM you can use here. Okay. So, you don't have to deal with other type of libraries or recreate things like that. Okay. So, you already have a rich set of NPMs that you can actually use. What if I want to connect to, I don't know, like one of the medical equipments, hook it up on the desktop and you don't have any NPMs for that? It depends. It depends. If you need USB and things like that, believe it or not, they are native NPM modules to do things like USB connections. Okay. So, at the same point, serial ports and things like that. Or Bluetooth or whatever. In the case of the medical industry, it's more Bluetooth. Okay. So, there are still no modules for that. Okay. Native modules. Okay. So, enough talking. I think we should just go in and show some electron applications. Now, what we would like to do is show some existing applications that have already been written. Any of you, how many of you have actually seen an electron application before? Okay. A few hands. Okay. So, let's go in. One of the things that a lot of people don't know is, as Christian actually mentioned, Atom is an editor that GitHub actually put out. And that was the source from which electron was, they effectively extracted out the electron. The shell. Yeah. And so that you can write any application using electron itself. And so, let's not show in the, you want to jump in? Another editor that is very well known as well. Well, probably in your machine. Jump in your code. Okay. There you go. How many of you have seen Visual Studio Code? Okay. Now, did you know that Visual Studio Code is also written in electron? Right. And so, you know, this is something that a lot of people find fascinating. Well, it's written by Microsoft and yet they've used something, you know, like open sourcing from GitHub. And it surprises a lot of people to know that. Probably a lot of people use Slack. Right? Yeah. See, a lot of users who use Slack. Slack is again written in electron. Yeah. This is one of my favorite examples. It looks like a desktop application. In fact, it has the Chrome and everything from a desktop application. It's an application called N1 by the company named Nylas. And it's an email client. So, basically, just download email, synchronize email. It has tied integration. It actually even supports blogging and things like that. But it's one of my favorite. And if you see this, you don't think that it's a web application. You think that it's native. Yeah. Can we jump in and show Visual Studio Code as well? Yeah, you can. You can. Of course you can. Have you got Visual Studio Code in your machine? No. Neither do I. I think I've got, I've got Atom. You have Atom? Yeah. I use Vi, man. You have Visual Studio Code or not? Not on this machine. Well, interesting thing that people said who use Electron. Again, as we said, the people from Microsoft, they have Visual Studio Code. It's a whole IDE or editor, they call it, like a smart editor, made an Electron. Internally, Microsoft as well has many tools using Electron. So, it's used by big companies, not only Slack or, I think, Facebook as well, right? Yeah. So, WhatsApp also have an application that, so it's hard to actually look at it and go, hang on a second, this is actually a web application. And similarly, WhatsApp, how many people use WhatsApp? A few people here? No, not a lot. Now, it's very popular. I mean, if you, if there are certain countries where like you go to India and so on, like everyone is on WhatsApp, right? This is a desktop application that it looks very similar to the web application that they have, but you'll notice that it's got a lot more integration with the desktop. You know, you will have, it's got a whole bunch of things. That's going over to the Atom thing over here now. You can add a new chat window and so on. If I go into Atom, notice that it's got a lot of file menus and things like that. I can have access to the right click button and the menu pops up. So, it's very different to, it's still, it's a web application, yet it's very, you know, it works as a desktop application with a lot of integration with the desktop components itself. It's interesting, but I remember many years ago when I was doing a lot of web development, right? One of the things that every customer asked me was, can we make it look like a desktop application? Like the desktop application that they are using, that when they do right click to all of that. And we have to use a lot of external controls and things like that and invest a lot of money trying to get that native look and feeling a web application. And now we are trying to do exactly the same. But now being really native. So, I want to quickly show a couple of other applications that we've actually written. I mean, first one is this proof of concept that we actually put together for, before we actually set on this desktop application that we actually wrote, that we are rewriting, it's actually called Communicare. So, this proof of concept was put together a few months earlier. I'm unfortunately, I can't see the new application that we are writing right now, but the proof of concept I can actually show you. It's a very simple application. And I'll also talk about some of the problems that we actually found in it as we were doing the proof of concept itself, right? So, if I did a quick search and find a patient. That's a very common Australian name. So, you know, I can actually go in and look at the clinical records and so on and so forth. It's a very simple application. I just don't want you to look at the application itself, what it does. But more importantly, some of the things that we actually found out was, when we started this proof of concept experiment, we were still thinking like a web application. We basically took a web application and checked it up on an electron shell. And, you know, how do you go back to the homepage, right? It was like, you know, we didn't have the whole navigation worked out and so on. So, we'll talk a little bit about more about when we actually get, you know, when we talk about how to actually get going and so on. But it's interesting to find that when you are actually moving from a web application to start writing a desktop application, there's a bit of paradigm shift going on. You no longer think about, hey, I've got a homepage over here and I need to go back to the homepage or click on these links and I need to refresh your page and things like that. We'll talk a little bit about that. Maybe it's a good time to actually start talking about what people need to do to get started. Christian? Yeah. And this is based in the experience that we have when developing the POC for this application. All of that was done in one week. Yeah. And we use the web application and things like that. And it was just me because, yeah. So, we, I think the current application that we've written, it all runs on React and HTML, but it could effectively be any JavaScript framework, right? It could be Angular. It could be anything that you want to use. Right. So, this is based in what we are start trying to do first. The first thing that we did was just putting the application directly, the URL, in an electron shell. So, just create the electron shell and then serve the page. Believe it or not, that took like 10 minutes. Yeah. Right? So, it was just like, was really simple, really easy. And if you want to try that, do it, please. With most of the applications, the web applications that you are running right now, that will be the first step. Yeah. But what are the problems with it, right? The problem we did is that first, obviously, you cannot work offline. Yeah. Right? Because you are just serving directly in the page that you have. And second is the security itself. Yeah. You can be like very nervous to cross the scripting and things like that. Yeah. And you will have problems as well with cross-various. So, because one of the things is when you are running on a browser, you do have the sandbox environment. Whereas when you are writing it on the electron shell, you do not have the sandbox environment. Right? No. So, by default, there are certain things that it allows you to, you know, you can run those external content on a web view. But if you actually show it, check it up on the browser control itself, you are opening yourself up to some security issues. Exactly. So, the second thing that we did, now that took 10 minutes. Yeah. That was a little more complex. Yeah. And we did this in two parts. The first is because the original version was, then the prototype was a Node.js application. Right. What we did is that, you know what, let's make the electron application run the core server. It was not an express, it was a core server. And put everything in the same package. So, in that way, it's just in the same installer, you have the server and you have the frontend. Right? Yeah. With the database and we just like were running a local database in that case. Right. So, effectively, what we did was we took all the content, effectively, what was running on the server and we checked it all up into the into the browser. And in our case, we had both the client and the server components and the database and everything packages up into a single electron file. Exactly. Everything is what's in the same place. In fact, one of the other second things that we did is that there was another backend that we had that was reading in Web API. We just put that in a self host. Yeah. And include together with the package. So, when the electron application runs, because it's a Node.js app, what it does is that it just run that external application. Right. And it serves locally everything. Right. So, the third thing that we actually did was to effectively exploit the power of the desktop. You know, when we did the proof of concept, what we actually found was, hey, how do we actually go back to the home screen? We've done a search in the previous, you know, if you're running it off of a web browser, you could just hit the back button or hit the home button and go back to where you want it. But it didn't seem like it actually worked well in a desktop application. So, the next thing we actually started doing was writing all the menu items and then changing the way some of the... Exploding MDI and things like that as the way that you see documents. Because now it's not like an SBA. It's not just a web page. So, now when you're just clicking in a patient, what you do is to basically open another window with the patient data. That is a very common experience for Mac users, for example. Yeah. Yeah. It actually becomes a little bit easier when you start an application from scratch, though. And so, when you start an application from scratch, you know, you could actually work really well with the UI and so on and so forth. So, first thing, as you said, Christian, you know, you got to start thinking more like an SBA, right? Exactly. You have to start thinking like an SBA. In this case, and it's perfectly okay. Cases and errors are different. In all cases, a web application that will continue being a cloud application, but it needs to be, let's call it desktop... Yes. Yeah. Desktop mode. Yeah. Yeah. Desktop like. Yeah. But if you actually are a web developer, and the only thing that you want to do is do a desktop application, don't even think about the web page. Think more like a web app. Sorry, like a desktop app. I want to just look at this. I will use the menu. You don't need the home buttons and things like that. Yeah. And you don't have to worry about making this application responsive when, you know, it needs to be smaller. Yeah. You don't have to think about that. Like, that's the thing that's interesting in the web, that you have to run in a mobile. It has to look in the mobile, and it has to look well on the browser. Yeah. Or it has to, you know what? And it has to be seen by Internet Explorer. You don't have to care about those things anymore. Yeah. And of course, there are some readymade templates that you can actually use to get started. Photon and React desktop are a couple of them. So you want to talk a little bit about that? Yeah. Photon and React desktop. Photon is basically, because it's a web application, what you do is that you use CSS to style your application to look like a desktop application. Right? So based on that, other people, Photon is from GitHub, what they did is that they create a ready-made set of styles to make it look like a Mac application. And it has all those elements that you are familiar with, like for example, savans and, you know, the Chrome for the search, the buttons and things like that. React desktop is still in alpha. Okay. One problem with Photon is that it's macOS. It is very, right? Or it's like, the look and feel is macOS. And if you want to reach Windows users, you are going to look like iTunes. Right? That doesn't belong to that place. So React desktop is different. It has a style for Windows and a style for Mac. So one of the things that you can do is when you package your application, you just package your application with the correct style. Yeah. It's still in alpha, but it's very promising. Okay. And I mean, like, just like a web application, right? I mean, you got to start thinking about, you know, what your primary navigation is, what your secondary navigation is, where your content panel is going to be and so on. If you look at a lot of applications that are being written in Electron, you will notice that rather than actually set all of these things horizontally, they're doing all of these things vertically, you have like a primary navigation on the left-hand side, and then you have a secondary navigation right after that in the second column, row, vertically, right? And then you'll have your content panel right next to it. But again, you know, you don't have to stick to it. It's a desktop application. You know, however you want to write it, you can actually do it. Exactly. And the 13 just reach the desktop. Maybe you as well need that traybar. Correct. You need like notifications. Notifications are very, very useful. Right. All right. To just say like, you get a message, you know what? Remember, this patient has to do this or that, you know, your blood pressure is high. Yeah. I think that's the key thing, right? I mean, you got to go back and say, why are you actually designing this for the desktop? It's not a web application. So you need to leverage on, you know, those things, whether you want to use a system tray or you only talk to the serial port or whatever it may be. Yeah. Yeah. Yeah. And so let's talk about the structure of an electron app itself, Christian. Yeah. Basically, it's the most simple thing ever, right? It's in the same thing as a web page. You have your entry point that is always a JavaScript file. Yeah. Right. Not an HTML file. Yeah. So effectively, you know, to start with, you can just do with three files, right? Yeah. Yeah. Yeah. The other thing that you need is a package JSON that is specified the entry point, the name of the application, the version of the application, the dependencies that you will use, basically like your package JSON for MPM. Yeah. Yeah. And the code that is pretty simple, you can, we can see many things here. Yeah. But actually, you create the window with the size that you need and things like that and pass the HTML file that you are going to load. Yeah. And that's effectively a very simple HTML file. And so once you do it, you know, you basically go and if you already got your electron installed on your machine, you basically go into the directory and say electron dot and that's it, right? Yeah. That's all. That's all. One important thing here is regarding the JavaScript files and things like that. If you have used things like Angular 2 so far, the size of the bundle that you generate with Angular 2 is really big. Yeah. Right? But that's okay. Here, the big difference is that you are serving your files locally. It's exactly the same. You don't have to download anything. The biggest mistake that at the beginning that we did when creating this application is that we reused the whole index page again. So we were used the CDM versions. Just remember, just have like another index page with the correct versions that are locally that will be in your electron installation. Yeah. Because that is what is... Yeah. And so this file, I mean, obviously, is a very simple hello world application. It's just normally got three files in it. But as you, as your application gets bigger and bigger, you will have, you'll obviously have directories and lots of JS files and a lot of CSS files and so on and so forth. And what Christian is saying was, like, rather than actually serve some of this content from CDN, it's better to actually download all of them and package it along with your application itself. It's there. All of that is there. You don't have to worry because users are going to install that application. Yeah. So, you know what? In the worst case scenarios, give them a DVD. Yeah. A DVD. Right. And, you know, of course, you can, like I said, you can run electron dot on your, from your, from the, you know, command prompt and run it. But you really want to package this and then send it across to people. Yeah. And... Because, again, as we said, for testing or for development, what you do is that you run electron dot just to run your application, or electron index to run your specific application. What was that? I don't know. I was going to die. Stages I'm going to fall down, I hope. But... But when you are going to deliver this to your users, don't expect that they will have electron installed. You have to give them a package with your application. In Windows, the common package is a setup dot exe or an MSI file that is an installer. In the case of Mac, it's going to be a DMG. Deviant users use an apt, you can create RPMs as well. But you have to deliver this to the users in an installable format. Electron supports as well Windows Store and the Apple Store applications. So, that is still a format to deliver that. One of the lessons that we learned during making the application was around the build pipeline. I don't know. Many people don't take this that seriously because it's a web application and things like that. But remember that now you want to reach desktop. The first thing that you have to ask yourself is which operating systems I'm going to reach. I'm going to be, like, able to deliver this application in Mac or I want as well Windows users things like that. So, based on that, one of the first things that we learned is that you should use the operating system that you want to reach to build your application. It's not entirely true because interestingly, you can't build Windows executables in Mac but no Mac executables in Windows. Right? But, you know, you can't build Windows. But, when we see testing that we'll see later, that will make things much easier, especially if you have to deal with binary node modules that happen. The easy way is just use a cloud provider. You can use Trevi CI for Mac OS applications or you can use Appi YOR to build and package your Electron Windows applications. To do the package, you use another node NPM module named Electron Package that just take care of all of that and generates all of that for you. Generate the MSI, generate the DMG, generate everything. You basically give an entry point, put it as your part of your build pipeline and you end up at the end with an MSI or a DMG as artifacts. Another lesson is separate your package JSON files. This has to do with two things. First, the type of release that you are typed to do. And second is even when I say that we are trying to reuse as much as possible between the web and the Electron application, we have serious problems with certain dependencies between the web application and the desktop application. So, we found that it was much easier if we actually have a package JSON for the Electron application itself with their own dependencies and things like that and another one for the web application. So, we just changed one to the other. We used that first to generate all the web part and after that, we just draw the new package JSON with the Electron requirements and let it go. And another is using Electron Rebuild. You will actually need this more than you think. Electron Rebuild will happen and this is very interesting, Mahesh, because one of the things that happens that I told you or what's you probably, somebody told us, right? Then Electron, basically, you have a Node.js core, right? And a WebKit front end, right? Just overall, something like that. So, you install packages and you solve the packages. That works pretty well with Java packages, JavaScript packages, right? But sooner or later, you will have to use something like SQLite or PouchDB or LevelDB or the serial port or the Bluetooth or something like that. Those are binary packages. Those are binary, native Node packages, right? Some of those packages, I already pre-built. A good example is SQLite for Mac. I already pre-built, so just download the binary package and it's there. But it's not going to work with Electron because even when Electron is a Node core, it's Node Node. So, what you have to do is rebuild that binary module for Electron. It sounds complicated. You can do it by yourself if you want to have fun. But the good thing is that Electron Rebuild does that for you. One of the things that we do is starting the posting style in that Electron package.js file, we put that Electron Rebuild to after install all the dependencies of Electron, we just rebuild all the binary packages needed that we use too. We use SQLite and we use PouchDB. PouchDB as well, yeah. And of course, the next thing is testing. I mean, we do a lot of unit testing for our web applications. And so, how do we actually go about doing testing for this environment, Christian? It depends. First, obviously, you are doing unit testing. And unit testing continue exactly the same as you do JavaScript testing. So, if you're using Mocha or you are using Jaspin or whatever and you use Karmas, the runner, continue using it. What it changed is that when you have an Electron application, you have to test Node integrations with the test of system. You need to test two things, right? You need to test the shell. Yeah, yeah. You need to test the shell. Because what you want to test first, you know what? I want to test that if, when I click this button, right, the menu bar or the tray icon that I have, just start, I don't know, blinking. Or that when I click this, I get a new message. I will get a batch in my icon telling me that I have a new message. Those are the things that you want to test that you cannot test naturally in something like Jaspin because that works for web. Okay. Well, what about Selenium? I don't know if we use a lot of Selenium. You continue using Selenium because you are testing the UI itself but Node integration. For the integration, the test you have to use something in a spectrum. Okay. Okay. And what about headless testing? Yeah. Right. You need that only if you are using testing in Linux or Mac. That is just the server version. There is something named virtual frame buffer. Okay. You just have to install it. What it does is just, it's a fake X server that just like display the stuff and you say, oh, is this in this place and this place? And it's a yes. Okay. And Windows in there because Windows have it. Okay. Yeah. But yours use Windows. So it works. Yeah. So why don't we actually finish off with some tips and tricks? I mean, some of the things that we actually learned while we are rewriting this application. So the first thing, of course, we've got is packaging the dependencies and so on. Right? Yeah. Sorry. You have to patch those dependencies. Everything, as I said, don't try to serve things from the CDN because you don't have that. You probably won't have connection. And there is no point. It's going to make all the application laggish anyway when it's like the first startup. So just put all those dependencies locally. Right? But it's just not those dependencies, right? No, no. In this is like the case of the Web API stuff. What you do is that those, that XE file is part of your electron. You include that as resource, let's call it. And what electron actually does is that it puts that in a resource folder. So when the applications is installed and they compress, it's there. Right. So you want to go, do you know what? There's like, there's another electron, good electron app. Can't remember the name. It was not real audio, but it's a SQL database browser. What they do, they have the part that does all the query is written in Haskell. So they include Haskell and the Haskell part together with the electron package. Right. So because it's self-contained. So when you install that, you just can put that. Visual Studio Code does that as well. Okay. All the things that you use like NPN, you see like the task manager, you will see that it has a lot of child, the children running with the application. Just put those things. How do you connect with them? IPC. IPC, yeah. That note is pretty good with it. Okay. I mean, you can do it, right? I mean, you can effectively, you can spawn off other applications to actually do some of the additional work and so on. Yeah. And then if you want to trigger it, you trigger it through IPC. Yeah. I mean, particularly because JavaScript is notorious for running. One of the problems that you will find, right, is multi-threading. Yeah. Or number crunching. Because what happens that you're wrong only in one thread. Yeah. All the studies are running in one thread. So what happened? This is the same consideration for any other desktop application. All of them are seen like the UI runs in one thread. So if you want to crunch number, do something that it will take time. Yeah. Don't do it there. Right. What you do is that you use web workers. Offload it. Yeah. Yeah. Offload the operations there. Yeah. Just do whatever it has to do. Yeah. Connect through IPC back to you with the results. Yeah. Problem solved. Yeah. And you got this include DB with the application. Yeah. I mean, a lot of, you don't have to include a database. I mean, a lot of people probably prefer to have a server running centrally and then you have your client application and all the databases served out of the, out of the server. So you connect through to an API and you do it. But in our case, because we wanted to do it in a disconnected mode, we wanted to have a local database as well. And although our original proof of concept was done using SQL server and SQL light, the one that we're actually currently doing uses MongoDB. And so we had to package up a version of Mongo along with our application. Yeah. But that case is actually very simple as well because at the end you have an MSI. Again, as I said, it's there. It's self-contained. Yeah. So we package the, we, in our case, we package pouch, don't we? Yeah. Yeah. Yeah. One of the things, yeah, yeah. In that case, because it's compatible with the MongoDB API. Yeah. One of the things that many people don't, because you mentioned grunching numbers and things like that. Yeah. Don't be scared if by any weird reason, you really need to do something very native or there's an integration that you need to have with the desktop that is not there yet. Just write C++ code. Yeah. And just create that electron plugin. It's actually really simple. I did one and it's really simple to do. Okay. Just don't be scared of that. And of course, the last one is when you're writing a web application, one of the nice things about the web application is you actually deploy it centrally to a server and then pretty much everyone gets it at the same time. Now, you know, when, with something like an electron application, you need to, you kind of link to have an auto of data, right? So you want to talk a little bit about that, Christian? Yeah. There are like two ways that you can do this. And it has an auto data as well. In fact, there are like many ways to do it. Yeah. Right? But again, the secret here is thinking as a desktop application. It's not thinking as a web application or something like that. So you can have an auto of data. There is one, there's electron of data. That what you do is that you use an npm fit with your application. Yeah. So it notifies that. And the other is made by GitHub as well, name a squirrel. Okay. And a squirrel, what you do is that it works the same. But what you do is that you put a new, it has a new get fit instead of npm fit. Okay. You can use both of them. Okay. Right? Right. All of them are fine. Right. And that's one of the things for us to consider when you are writing this application itself is now that it's out in the wild, how do we actually keep updating it? That's something that we need to think about. Now, hopefully, you know, that's kind of like giving you a bit of an insight into creating an application using electron. This was by no means a, you know, our aim wasn't to give you a bit of a technical showdown on how to do each and every one of those things, but to give you a bit of an overview and give you an introduction to electron itself. In fact, I wouldn't interrupt there because in fact, the secret of this talk, and that was the subtitle, which I realized that is how to sell electron to your CTO because that was actually what I did. Right? Yeah. I have, he was reluctant. He was like, no. And at the end, it worked. Yeah. So, you know, I think we set out to show you why, you know, what our use case was and why we want to use electron, just give you a little bit of introduction, how to create the application, and so on. And just, you know, we wanted to wrap it up with a few considerations and things like that that we actually learned in our own journey. And if you've got any questions, please feel free to ask those questions. Now, I know, like in past experience with Oslo, you know, people have generally been very reluctant to ask questions. So, you know, you, if more than welcome to actually send us contact us via Twitter, those are Twitter handles over here. Any questions, by the way? Yeah? Yeah. Can you package your application as a mobile application for Android? At this stage, it's more focused on the desktop application. So, the short answer is no. Right? I think there have been a few questions that have been asked in the forums on whether, hey, can I actually ship it for Android and iOS and so on? But I think one of the problems is going to be, even if we are able to do it, is to get the Apple Store to approve your application. Right? Remember that one of the things that happens here is that one of the advantages of Electron is that you have only one API to talk to the desktop. So, in cases like that, the mobile phone doesn't have, it's not a desktop system. So, there's no point. You will have to remove many things from it. One thing that I'll actually mention though is you can actually deploy, there are ways in which you can actually package it up for store. So, if you want to, so that's part of the, you know, it allows you to go look up the GitHub site for Electron. It's got a whole bunch of guidance on how to do it. Yeah. You can pack for Windows Store and pack as well for the Apple Store. There are just a few considerations about the things that you should not do, for example, certain authorizations and things like that. Yeah. Any other questions? Yeah? Yeah. That was a good one. Yeah. What we use is a queuing system. Yeah. We use an internal queue because we have that in the cloud system we use, what we use in the cloud for the queue. We use a queue. Yeah. And locally we have a local queue and small database in level DV as well with all the messaging. And then what we do is just replay that. Yeah. Did you have to open the program to make sync or do you sync? We just like, we just imperatively, we say like sync now. Yeah. Many, many times we just have to do a right click sync. It's a little bit complicated. I mean, like, I think one way is like, oh, you know, as soon as you get your network connection, let's actually do a sync and so on. But I think we went against that approach, you know, you go in and pick when you want to sync and then you sync it up. You can detect, in Electron, you can detect when you have an internet connection or not. Yeah. But the problem that we have with the detection is what they call the LAN party, the LAN party mode, because it's not just a desktop that the doctor takes. We usually insert them, for example, the flying doctors, they just go in groups. So what they have is a small server and then the doctors just connect to them. So one of the things that we add there is auto discovery by Pio. Yeah. That this is an integration. You cannot do that in web. So it discovered this and said, like, oh, this is actually the server right now. Yeah. Just bear in mind that, you know, this is still a work in progress. And maybe, you know, in a few months time, and it's all completely ready to be shown, we'll be able to show it. Yeah. We hope that will be soon. How do you handle the installation of updates? Right. MSIs. Yeah. In the case of Windows and DMGs. And in this case, we use actually, we are right now, I started using a squirrel, but we still like testing. Yeah. So it's not, it hasn't been fully deployed yet. Yeah. Yeah. But right now, what we're doing, the Windows customers that is, we're start deploying Windows customers is MSIs. So that is actually pretty simple because updates and things like that. In fact, for some people, we actually just send them zip files for a lot of those things. Yeah. Yes? We saw the studio calls users as squirrel. Atom uses squirrel as well. If you, a way, a simple way to see that and why, I don't even know if it's called a squirrel anymore, but I call it like that because when you see Atom, you will see a small squirrel in the corner that is blue. That means that you need updates. If you just want to update some HTML and JavaScript, is that possible? I was, that is, yeah. It can be done. In fact, one of the things that this lack client does is that it just connect for first time because it's like you have to be connected, right? When it's the tech connection, you just go to the CDN to see if there is new version of HTML, of the HTML or files that it needs and download and keep it locally. Right? But it makes sense in that case because it's a chat program. You need to go in connection to chat, right? But yeah, you can do that as well. You can just, because you control the moment that you start. So you can just do those requests and ask, there's a new version and things like that. Download, keeping in the folder where you want to just get that content and then serve it. Yeah, there's one other question over there. Yeah. What about debugging and profiling? They are tooling as well. The guys from GitHub, they actually, in the web page, you can see, they deliver like a testing tool for it. In fact, in the old time, what you can do is that you have the whole Chrome debugging experience as well. Yeah. Sorry. Got that. So you just put open DevTools and it will just show the DevTools. That is the same that you have in Chrome. So you have as well those plugins and things like that. So notice this is actually running, there's another application that's running. And I just hit control shift high and brought down the debugger, the Chrome developer toolkit, whatever you call it. Yeah. Yeah, there's like no MP, it's actually an MPM package to do that. They are like... So what are the questions? If they have packages for USB, Bluetooth, and things like that, yeah, those are like native MPM packages that you can use. Do you will only, in that, remember the consideration that to use it with Electron, you will need to use Electron Rebuild. Any other question, guys? So do I understand correctly that there are native Windows building tools for that? Or do I have to use the cloud service? I mean, in this scenario? Oh, no, no. You just use TeamCity or TFS or whatever it is. We use that because we are just trying to put everything in the cloud. You don't have to. You're going to have to. You can just build it in your machine and things like that. But I think one of the key things, if you're building for a Mac, you do need a Mac. Yeah. So that's the one thing that you need to think about. Right? Oh, sorry. Yeah. Yeah, yeah, yeah. You can. Yeah. Yeah, yeah, yeah. I was waiting somebody to ask me. Yeah, you don't package it. Yeah. Are there any performance? So it's like you look at the Google, you don't get the things like that. Like 300 normal C, click delays, like that. The question is, do you have any performance delays? Right? No. Well, the same thing that is going to happen with the web, right? You are not going to just put JavaScript to crunch numbers. Yeah. So here's the thing, right? So there's the problem of network latency. So if you're actually hosting all your content from the web, which is what a lot of phone gap applications do, you will have the same amount of latency that you have, like a typical web application. But if you are caching a lot of those HTML and JavaScript and so on locally, it's going to be pretty snappy. It's going to be quite performant. Yeah. One of the outcomes that I want you to take here is that it's really simple to start. Yeah. So go and try it. Yeah. And maybe who knows, maybe the next desktop application is going to be a Charlie and Java as a group application. Yeah. Yeah. Version one has been released. It's advanced very fast. We would expect that to have more desktop integration, more teams interacting with the desktop, because that's the secret at the end. You can't integrate with the operating system. So who knows, maybe soon we will have preview handlers written in Electrum. Things like that. All right. Thanks for attending, guys. And thank you very much. I hope you guys enjoyed the NDC and have safe travels back. Yeah. Thanks.
 I think we've come to the last day of NDCN. I think we've all got a little bit of brain  overload and you got a good lunch as well. So I think we've both in an undeniable position  of trying to keep you guys awake for the next hour or so. So good luck to us. How many of you,  before we get started, how many of you have actually are writing web applications right now?  Okay, it's probably about 80% of the audience, right? How many of you write desktop applications  right now? Okay, not a lot. Okay. Now wouldn't it be cool, right? And wouldn't it be cool if you  could actually write a desktop application and then use the, you know, leverage the power of the  desktop, access system menus, use the system tray, and access files from the file system,  and, you know, even do low-level things like accessing a serial port, for instance. And while  doing so, you just use your existing web skills that you already have, but the 80% of the audience  are already doing, they've already got web skills. Wouldn't it be wonderful to do that? And that's  what this talk is all about. We're going to talk about how you could actually write a desktop  application using your web skills. We actually write it once and hopefully you can actually  run it as a desktop application. So the title of our talk is Write Once, Run Everywhere,  is not a myth. And we're going to talk about this wonderful technology called Electron that  we're going to be using to show you how to do it. My name is Mahesh Krishnan. I work for, as a CTO in  a company that writes software for the health industry down in Australia. That's right. I'm  here from Australia down, all the way down from there. And this is my co-presenter, Christian  Prieto. He works as a technical lead. Now I'm going to let you know a secret. Now Christian  actually hates being called an architect. So at every opportunity I get, I introduce him as an  architect to people. No, no, no. So I'm actually being nice today. So introduce my technical  lead, Christian. Yeah, yeah. Without any offense. But in Australia, most architects don't quote and  I quote. That's the difference. Right. So if you really want to know him, right, call him an  enterprise architect and I'll set him off. Anyway, so what we want to talk about today is we want to  talk about, but electron. More importantly, I want to talk about, I want to talk about why,  why electron? Why do you want to use electron? What is the use case for it, right? And then we want  to give you a bit of introduction on what electron is and then we'll show you some of the existing  code that have been written using electron. And then we'll move in and talk about, maybe we'll  give you some of the design considerations. You know, in our journey, what are the things that  we actually found out and hopefully some of the steps can actually help you when you decide to  make the move to electron itself. So first thing, of course, is what is the problem that we're  trying to solve? I mean, a lot of cases, what actually happens is that, you know, you find this  new shiny tool and then you say, oh, this is awesome. This is really cool. I need to use this for  everything. And it almost seems like a hammer, right? This new tool is your hammer and every  problem that you actually see seems like a nail and you just want to hit with the hammer. So we  want to, I want to do things in a different perspective and try to say, hey, what is the  problem that we're actually trying to solve? What is the business problem you're trying to solve?  And what is the solution from a technological point of view that we can actually offer? What are  the right tools for it? As I said earlier, I work for a company that writes software for the  health industry. One of the software that we already have is an application that is used by  doctors, general practitioners, nurses, and so on. And the thing is, you know, it's about 20 years  old. The people who actually use it love this application. However, we've got a couple of  problems. First thing is it's actually written in Delphi or Delphi. How many of you actually write  Delphi nowadays? Anyone? There's one person, right? One person. So you can actually imagine if we  want to go and fix things in the Delphi application, we can't find anyone to actually do it for us.  So, I mean, we've got to have a technology refresh just for that alone so that we don't have any  technical debt. The second thing, of course, is this application has been written 20 years ago. So,  it is pretty old. And although some of the users love it, we need to come up with a much better  modern user interface and things like that as well. So, we need to change this application. So,  what do we do? Well, we'll rewrite this application. And of course, you know, what do we do these  days? We'll put it up on the cloud. We will sell it as a software, as a service application. And so,  what do we do? We write it as a web application. It sounds great. However, there are a lot of  constraints that we already have. First and foremost, like I said, we are all from Australia.  Anyone been to Australia over here? It's a few people. I mean, if you guys didn't know Australia's  bloody big country, right? It's huge. And doctors, some of these doctors actually go to some of these  remote areas to service people. And, you know, sometimes they actually take a couple of days  to get there. Yeah, there are areas that it takes three days driving without anything around,  things like that, just to see 9,000 patients. Yeah. And in fact, we have the royal flying doctors  who effectively fly over to actually get to some place to actually see patients. And when you go  to some of these remote areas, the biggest problem that we have is we don't have network coverage.  So, all this grand idea of you're going to host this up in the cloud is all gone because there is  no network coverage, right? So, we want to have almost like an offline application that you can  actually take and wherever you're going. But we want only to write it once. We want to write a  web application and then half as well at the desktop application. Yeah. That's the bigger  challenge. Yeah. And the other thing that we want to have is we almost also work in what we  actually call as a LAN party mode, right? So, it's not like one doctor that goes there. A number  of people with medical practitioner will go and then we want to connect to a single server and  then do things on that single server through multiple desktops connecting. And we want to make  it discoverable and so on and so forth. So, we need to discover where the services and so on. So,  we have that requirement as well. And what else do we have, Christian? What are the other  constraints that we have? Any other testing now? Oh, yeah. Yeah. A run out of batteries. Yeah.  There's no electron or offline things for this. Yeah. We have other problems and the biggest  was I have to go and interview the developers doing this application. And the first thing what I  asked them is what is your background? All of them, their background was web development. Yeah.  So, they was the first struggle. I'm struggling coding in Delphi that I have to learn Delphi and  all this stuff. Yeah. But the thing though is we really needed a desktop application, right? And  some of these doctors also said, hey, we would like to run it on a Windows machine as well as a Mac.  And so, which effectively meant we needed a cross-platform development. You know,  web skills or not, we really wanted a cross application that is a cross-platform. And just  going into cross-platform development, you know, if you start looking at how we've done it historically,  if you go back into the 80s or pre-80s, people used to write applications in C and C++. They  would write the application once in CRC++ and then compile it on a different platform and you  could actually, you know, you could run it on the various platforms. But you know, when a lot of  the windowing environments actually came into core, like when you had Windows and a lot of GUI  platforms that you had to write to, a lot of this didn't work well. It worked really well in the  console application, but didn't have the right graphics libraries. And so, I mean, they are still  available and people still do it, but it's a lot more complex and a lot more difficult to do. And  then of course, in the 90s, we had Java, right? Java was going to fix all our problems. It's going  to be completely cross-platform. You could write Java and then you had this wonderful world of  AWT and applets and so on. Did anyone write applets over here or any of that stuff back in  those days, right? And that died pretty quickly, I think. I mean, we still use Java now, but more  on the server side, but not on the client side at all. I really like to know how many applications  are being written in Java on the client side now. Probably not a lot. Of course, then we moved on  to the last decade and of course, we had this, you know, pretty much a lot of people wanted to  write applications in web, write it on a browser, it's cross-platform kind of, but it didn't have  that rich interactiveness. So, we had this new set of applications called RIA applications,  or rich internet applications, and which effectively was all flash and cellulite. Anyone  write cellulite applications over here? Like, well, a few people. Okay. Well, I actually wrote a  book to actually help people learn cellulite, right? And that book, I'm sure, is, you know,  those books are probably lying in some dumpster somewhere because that technology died pretty  quickly. And the reason why it actually died was because HTML5 came about and it could do a lot  of things that you couldn't previously do on browsers. And of course, you know, you had the  mobile phones revolution. I think when Steve Jobs introduced the iPhone, and that was the first  nail in a scoffing, right? That was the beginning of the end for a lot of the flash and cellulite  and so on. But, you know, moving on to this decade itself, you know, smartphones, everybody  wanted to write applications for smartphones. And again, you kind of like wanted to write,  like, you wanted to write cross-platform applications for the smartphones. So,  you wanted to run it for Android, you wanted to write it for iOS, and you also wanted to write  it for the one or two Windows phones that are still around. But, and you used things like a  phone gap and Xamarin and all that. But all these are more focused on the mobile phone. If you  come back to our use case, we want to write a desktop application. So, how do we actually go  about doing this? And so, you know, of course, I turned up to Christian and said,  hey, Christian, what can we actually do? And what does the answer you gave me, Christian?  And what I said to Mahesh is, let's write it in an electron. Let's do it in an electron.  Which kind of like brings up the question, like, what is electron?  Well, electron is an open source project. It was created by GitHub and was just to solve a very  simple issue. They wanted to create an editor to be able to give to, you know, edit code and  things like that. But an editor, think about that, is has to run in a machine and has to have,  like, all the native integrations with the computer, with the desktop itself, not a computer,  with the desktop. So, it's basically what you do is that you host a web application inside a shell app.  Right. So, that sounds like, you know, that's effectively like a web control. And we always  had web controls before. I mean, you could host a web browser control in a WinForms application  or a WPF application. I could actually understand that. It just works quite easily. But we really  wanted a cross-platform application. So, if you wanted to run it on a Mac, that would still be a  problem. But of course, you know, you had Xamarin. You could run it on a Xamarin application and  you could host a web browser control in it. But so, what's the problem with that? I mean,  you could just do that right. Yeah. There's like plenty of problems with that. And that was the  first approach because it was, oh, so basically it's just a browser, you know, in a browser control.  All of us are used that. In fact, a very, like, funny story. One of the other projects that we  work on, when I was looking at the UI that the developers did, it's like, oh, these controls  are really nice, which we WinForm because it's a WinForm application, which WinForm provider,  like control provider, are using. And it's like, oh, no, what we did is that we put a UI, a web view  and write everything and generate HTML and that is the UI. It's like, well, perfect. But the  difference is that when you do that, you are just basically constrained. You are in a sandbox. You  cannot do a lot of things, right? And it's still the problem that is very difficult interaction  between what you have inside that web view with outside the web view. For example, adding menus  and things like that. You can do that, but that will be the code in your C sharp application. It's  not going to be the code written in your JavaScript application. Right. So we have two problems,  right? One is, you're writing two applications. One is the web application that you're hosting  within that browser control, right? And then you're another application that you're writing that  actually hosts the container, if I can call it the shell. That's all got all the menu items.  And then there's no seamless integration between these two applications. If you wanted the web  application to do something on the desktop, it's really hard to do it. Right. And from the desktop  application, you can maybe trigger changes to web pages and things like that. But you don't have a  very refresh, but you will have that. It's just basically putting a web browser there. Electron  is not like that. Right. So, but why electron? I mean, there have been other applications that  have actually come and gone, right? I mean, for example, Microsoft have something recently that  is the web apps or something like that. Yeah. Yeah. Yeah. Yeah. The web host applications. Yeah. The  web host applications. Yeah. It's exactly the same mechanism. Right. But what about running  JavaScript applications or rather, you know, something similar to electron where the shell,  you know, there was a product called, was it Node web host or something like that?  NWS. Yes. Yes. Or something like that. Yeah. Yeah. They basically the same. Yeah. They have  difference and things like, they have, they have difference, but it's like compare, react with  Angular. I don't want to go into that world. Okay. So, we've actually gone, there have been other  technologies that actually do the same. And, but tell me a little bit more about, about this itself.  Well, the first is that electron is cross-platform. Right. It started as just a Mac platform  stuff, but it's now cross-platform. It has native bindings for many operating systems. Well,  the three major operating systems, Linux, Windows and Mac. Right. But it's feature-rich. The  integration with the desktop itself is very, very good. You can integrate with things like the menu  bar, the icons that you see, create batches for those icons in stuff that you have in, in, and  you can write your own stuff to, for example, do more integrations with the desktop. For example,  the progress bar in Mac when you are downloading something can be easily writing. It's web  technology. It's not like the web control that we were talking before because here you write your  application in JavaScript. It's just basically your JavaScript application with HTML stuff.  You can use all the libraries that you used to, to use. You can use all the Node.js packages that  you have over there, all that rich set. That is a lot. That opens a lot of possibilities.  Right. And one of the nice things is that it actually already comes packaged with the Chromium  web browser. So, you don't have to worry about. You don't have to worry about that. It's another  problem that you have with the web build controls. You cannot control that. In Mac, it's going to be  just the web kit that they use for Safari and in Windows, it's going to be Internet Explorer.  Right. So, yes, we still have that problem. Here is a web browser that you already know.  Okay. And of course, you have access to a whole set of NPMs.  Everything that is in NPM you can use here. Okay. So, you don't have to deal with other  type of libraries or recreate things like that. Okay. So, you already have a rich set of NPMs  that you can actually use. What if I want to connect to, I don't know, like one of the medical  equipments, hook it up on the desktop and you don't have any NPMs for that? It depends. It depends.  If you need USB and things like that, believe it or not, they are native NPM modules to do  things like USB connections. Okay. So, at the same point, serial ports and things like that.  Or Bluetooth or whatever. In the case of the medical industry, it's more Bluetooth. Okay.  So, there are still no modules for that. Okay. Native modules. Okay. So, enough talking.  I think we should just go in and show some electron applications. Now, what we would like to do is  show some existing applications that have already been written. Any of you,  how many of you have actually seen an electron application before? Okay. A few hands. Okay.  So, let's go in. One of the things that a lot of people don't know is, as Christian actually  mentioned, Atom is an editor that GitHub actually put out. And that was the source from which  electron was, they effectively extracted out the electron. The shell. Yeah.  And so that you can write any application using electron itself. And so, let's not show in the,  you want to jump in? Another editor that is very well known as well.  Well, probably in your machine. Jump in your code. Okay.  There you go. How many of you have seen Visual Studio Code? Okay. Now, did you know that Visual  Studio Code is also written in electron? Right. And so, you know, this is something that a lot  of people find fascinating. Well, it's written by Microsoft and yet they've used something, you  know, like open sourcing from GitHub. And it surprises a lot of people to know that.  Probably a lot of people use Slack. Right? Yeah. See, a lot of users who use Slack. Slack is again  written in electron. Yeah. This is one of my favorite examples. It looks like a desktop application.  In fact, it has the Chrome and everything from a desktop application. It's an application called  N1 by the company named Nylas. And it's an email client. So, basically, just download email,  synchronize email. It has tied integration. It actually even supports blogging and things like that.  But it's one of my favorite. And if you see this, you don't think that it's a web application.  You think that it's native. Yeah. Can we jump in and show Visual Studio Code as well?  Yeah, you can. You can. Of course you can. Have you got Visual Studio Code in your machine?  No. Neither do I. I think I've got, I've got Atom.  You have Atom? Yeah. I use Vi, man.  You have Visual Studio Code or not?  Not on this machine. Well, interesting thing that people said who use Electron. Again, as we said,  the people from Microsoft, they have Visual Studio Code. It's a whole IDE or editor, they call it,  like a smart editor, made an Electron. Internally, Microsoft as well has many tools using Electron.  So, it's used by big companies, not only Slack or, I think, Facebook as well, right?  Yeah. So, WhatsApp also have an application that, so it's hard to actually look at it and go,  hang on a second, this is actually a web application. And similarly, WhatsApp, how many  people use WhatsApp? A few people here? No, not a lot. Now, it's very popular. I mean, if you,  if there are certain countries where like you go to India and so on, like everyone is on WhatsApp,  right? This is a desktop application that it looks very similar to the web application that  they have, but you'll notice that it's got a lot more integration with the desktop. You know, you  will have, it's got a whole bunch of things. That's going over to the Atom thing over here now.  You can add a new chat window and so on. If I go into Atom, notice that it's got a lot of  file menus and things like that. I can have access to the right click button and the menu pops up.  So, it's very different to, it's still, it's a web application, yet it's very, you know,  it works as a desktop application with a lot of integration with the desktop components itself.  It's interesting, but I remember many years ago when I was doing a lot of web development,  right? One of the things that every customer asked me was, can we make it look like a desktop  application? Like the desktop application that they are using, that when they do right click to  all of that. And we have to use a lot of external controls and things like that and invest a lot  of money trying to get that native look and feeling a web application. And now we are trying to do  exactly the same. But now being really native. So, I want to quickly show a couple of other  applications that we've actually written. I mean, first one is this proof of concept that we actually  put together for, before we actually set on this desktop application that we actually wrote,  that we are rewriting, it's actually called Communicare. So, this proof of concept was put  together a few months earlier. I'm unfortunately, I can't see the new application that we are writing  right now, but the proof of concept I can actually show you. It's a very simple application. And  I'll also talk about some of the problems that we actually found in it as we were doing the proof  of concept itself, right? So, if I did a quick search and find a patient.  That's a very common Australian name. So, you know, I can actually go in and  look at the clinical records and so on and so forth. It's a very simple application. I just don't  want you to look at the application itself, what it does. But more importantly, some of the things  that we actually found out was, when we started this proof of concept experiment, we were still  thinking like a web application. We basically took a web application and checked it up on an electron  shell. And, you know, how do you go back to the homepage, right? It was like, you know, we didn't  have the whole navigation worked out and so on. So, we'll talk a little bit about more about when  we actually get, you know, when we talk about how to actually get going and so on. But it's  interesting to find that when you are actually moving from a web application to start writing a  desktop application, there's a bit of paradigm shift going on. You no longer think about, hey,  I've got a homepage over here and I need to go back to the homepage or click on these links and I  need to refresh your page and things like that. We'll talk a little bit about that. Maybe it's  a good time to actually start talking about what people need to do to get started. Christian?  Yeah. And this is based in the experience that we have when developing the POC for this application.  All of that was done in one week. Yeah. And we use the web application and things like that.  And it was just me because, yeah. So, we, I think the current application that we've written,  it all runs on React and HTML, but it could effectively be any JavaScript framework, right?  It could be Angular. It could be anything that you want to use. Right. So, this is based in  what we are start trying to do first. The first thing that we did was just putting the application  directly, the URL, in an electron shell. So, just create the electron shell and then serve the page.  Believe it or not, that took like 10 minutes. Yeah. Right? So, it was just like, was really  simple, really easy. And if you want to try that, do it, please. With most of the applications,  the web applications that you are running right now, that will be the first step.  Yeah. But what are the problems with it, right? The problem we did is that first,  obviously, you cannot work offline. Yeah. Right? Because you are just serving directly in the page  that you have. And second is the security itself. Yeah. You can be like very nervous to cross  the scripting and things like that. Yeah. And you will have problems as well with cross-various.  So, because one of the things is when you are running on a browser, you do have the sandbox  environment. Whereas when you are writing it on the electron shell, you do not have the sandbox  environment. Right? No. So, by default, there are certain things that it allows you to, you know,  you can run those external content on a web view. But if you actually show it,  check it up on the browser control itself, you are opening yourself up to some security issues.  Exactly. So, the second thing that we did, now that took 10 minutes. Yeah. That was a little  more complex. Yeah. And we did this in two parts. The first is because the original version was,  then the prototype was a Node.js application. Right. What we did is that, you know what,  let's make the electron application run the core server. It was not an express, it was a core server.  And put everything in the same package. So, in that way, it's just in the same installer,  you have the server and you have the frontend. Right? Yeah. With the database and we just like  were running a local database in that case. Right. So, effectively, what we did was we took all the  content, effectively, what was running on the server and we checked it all up into the into the  browser. And in our case, we had both the client and the server components and the database and  everything packages up into a single electron file. Exactly. Everything is what's in the same place.  In fact, one of the other second things that we did is that there was another backend that we had  that was reading in Web API. We just put that in a self host. Yeah. And include together with the  package. So, when the electron application runs, because it's a Node.js app, what it does is that  it just run that external application. Right. And it serves locally everything. Right. So,  the third thing that we actually did was to effectively exploit the power of the desktop.  You know, when we did the proof of concept, what we actually found was, hey, how do we actually  go back to the home screen? We've done a search in the previous, you know, if you're running it  off of a web browser, you could just hit the back button or hit the home button and go back to where  you want it. But it didn't seem like it actually worked well in a desktop application. So, the next  thing we actually started doing was writing all the menu items and then changing the way some  of the... Exploding MDI and things like that as the way that you see documents. Because now it's not  like an SBA. It's not just a web page. So, now when you're just clicking in a patient, what you do  is to basically open another window with the patient data. That is a very common experience  for Mac users, for example. Yeah. Yeah. It actually becomes a little bit easier when you start an  application from scratch, though. And so, when you start an application from scratch, you know,  you could actually work really well with the UI and so on and so forth. So, first thing, as you  said, Christian, you know, you got to start thinking more like an SBA, right? Exactly. You have to  start thinking like an SBA. In this case, and it's perfectly okay. Cases and errors are different. In  all cases, a web application that will continue being a cloud application, but it needs to be,  let's call it desktop... Yes. Yeah. Desktop mode. Yeah. Yeah. Desktop like. Yeah. But if you actually  are a web developer, and the only thing that you want to do is do a desktop application, don't even  think about the web page. Think more like a web app. Sorry, like a desktop app. I want to just  look at this. I will use the menu. You don't need the home buttons and things like that. Yeah. And  you don't have to worry about making this application responsive when, you know, it needs to  be smaller. Yeah. You don't have to think about that. Like, that's the thing that's interesting  in the web, that you have to run in a mobile. It has to look in the mobile, and it has to  look well on the browser. Yeah. Or it has to, you know what? And it has to be seen by Internet  Explorer. You don't have to care about those things anymore. Yeah. And of course, there are  some readymade templates that you can actually use to get started. Photon and React desktop are a  couple of them. So you want to talk a little bit about that? Yeah. Photon and React desktop.  Photon is basically, because it's a web application, what you do is that you use CSS to style your  application to look like a desktop application. Right? So based on that, other people,  Photon is from GitHub, what they did is that they create a ready-made set of styles to make  it look like a Mac application. And it has all those elements that you are familiar with,  like for example, savans and, you know, the Chrome for the search, the buttons and things like that.  React desktop is still in alpha. Okay. One problem with Photon is that it's macOS. It is very,  right? Or it's like, the look and feel is macOS. And if you want to reach Windows users,  you are going to look like iTunes. Right? That doesn't belong to that place. So React desktop is  different. It has a style for Windows and a style for Mac. So one of the things that you can do is  when you package your application, you just package your application with the correct style.  Yeah. It's still in alpha, but it's very promising. Okay. And I mean, like, just like a web  application, right? I mean, you got to start thinking about, you know, what your primary  navigation is, what your secondary navigation is, where your content panel is going to be and so  on. If you look at a lot of applications that are being written in Electron, you will notice that  rather than actually set all of these things horizontally, they're doing all of these things  vertically, you have like a primary navigation on the left-hand side, and then you have a secondary  navigation right after that in the second column, row, vertically, right? And then you'll have your  content panel right next to it. But again, you know, you don't have to stick to it. It's a desktop  application. You know, however you want to write it, you can actually do it. Exactly. And the 13  just reach the desktop. Maybe you as well need that traybar. Correct. You need like notifications.  Notifications are very, very useful. Right. All right. To just say like, you get a message,  you know what? Remember, this patient has to do this or that, you know, your blood pressure is high.  Yeah. I think that's the key thing, right? I mean, you got to go back and say, why are you actually  designing this for the desktop? It's not a web application. So you need to leverage on, you  know, those things, whether you want to use a system tray or you only talk to the serial  port or whatever it may be. Yeah. Yeah. Yeah. And so let's talk about the structure of an  electron app itself, Christian. Yeah. Basically, it's the most simple thing ever, right? It's in  the same thing as a web page. You have your entry point that is always a JavaScript file. Yeah.  Right. Not an HTML file. Yeah. So effectively, you know, to start with, you can just do  with three files, right? Yeah. Yeah. Yeah. The other thing that you need is a package JSON  that is specified the entry point, the name of the application, the version of the application,  the dependencies that you will use, basically like your package JSON for MPM. Yeah. Yeah.  And the code that is pretty simple, you can, we can see many things here. Yeah.  But actually, you create the window with the size that you need and things like that and pass  the HTML file that you are going to load. Yeah. And that's effectively a very simple HTML file.  And so once you do it, you know, you basically go and if you already got your electron installed  on your machine, you basically go into the directory and say electron dot and that's it, right?  Yeah. That's all. That's all. One important thing here is regarding the JavaScript files and things  like that. If you have used things like Angular 2 so far, the size of the bundle that you generate  with Angular 2 is really big. Yeah. Right? But that's okay. Here, the big difference is that you  are serving your files locally. It's exactly the same. You don't have to download anything.  The biggest mistake that at the beginning that we did when creating this application is that we  reused the whole index page again. So we were used the CDM versions. Just remember,  just have like another index page with the correct versions that are locally that will  be in your electron installation. Yeah. Because that is what is... Yeah. And so this file, I mean,  obviously, is a very simple hello world application. It's just normally got three files in it. But as  you, as your application gets bigger and bigger, you will have, you'll obviously have directories and  lots of JS files and a lot of CSS files and so on and so forth. And what Christian is saying was,  like, rather than actually serve some of this content from CDN, it's better to actually download  all of them and package it along with your application itself. It's there. All of that is there.  You don't have to worry because users are going to install that application. Yeah. So,  you know what? In the worst case scenarios, give them a DVD. Yeah. A DVD. Right. And, you know,  of course, you can, like I said, you can run electron dot on your, from your, from the, you  know, command prompt and run it. But you really want to package this and then send it across to  people. Yeah. And... Because, again, as we said, for testing or for development, what you do is  that you run electron dot just to run your application, or electron index to run your  specific application. What was that? I don't know. I was going to die. Stages I'm going to fall down,  I hope. But...  But when you are going to deliver this to your users, don't expect that they will have  electron installed. You have to give them a package with your application. In Windows,  the common package is a setup dot exe or an MSI file that is an installer. In the case of Mac,  it's going to be a DMG. Deviant users use an apt, you can create RPMs as well. But you have to  deliver this to the users in an installable format. Electron supports as well Windows Store  and the Apple Store applications. So, that is still a format to deliver that.  One of the lessons that we learned during making the application was around the build pipeline.  I don't know. Many people don't take this that seriously because it's a web application and  things like that. But remember that now you want to reach desktop. The first thing that you have to  ask yourself is which operating systems I'm going to reach. I'm going to be, like, able to deliver  this application in Mac or I want as well Windows users things like that. So, based on that, one  of the first things that we learned is that you should use the operating system that you want to  reach to build your application. It's not entirely true because interestingly, you can't build Windows  executables in Mac but no Mac executables in Windows. Right? But, you know, you can't build  Windows. But, when we see testing that we'll see later, that will make things much easier,  especially if you have to deal with binary node modules that happen. The easy way is just use  a cloud provider. You can use Trevi CI for Mac OS applications or you can use Appi YOR to build  and package your Electron Windows applications. To do the package, you use another node NPM module  named Electron Package that just take care of all of that and generates all of that for you.  Generate the MSI, generate the DMG, generate everything. You basically give an entry point,  put it as your part of your build pipeline and you end up at the end with an MSI or a DMG as artifacts.  Another lesson is separate your package JSON files. This has to do with two things. First,  the type of release that you are typed to do. And second is even when I say that we are trying to  reuse as much as possible between the web and the Electron application, we have serious problems  with certain dependencies between the web application and the desktop application. So,  we found that it was much easier if we actually have a package JSON for the Electron application  itself with their own dependencies and things like that and another one for the web application.  So, we just changed one to the other. We used that first to generate all the web part and after  that, we just draw the new package JSON with the Electron requirements and let it go.  And another is using Electron Rebuild. You will actually need this more than you think.  Electron Rebuild will happen and this is very interesting, Mahesh, because one of the things  that happens that I told you or what's you probably, somebody told us, right? Then Electron,  basically, you have a Node.js core, right? And a WebKit front end, right? Just overall,  something like that. So, you install packages and you solve the packages. That works pretty well  with Java packages, JavaScript packages, right? But sooner or later, you will have to use something  like SQLite or PouchDB or LevelDB or the serial port or the Bluetooth or something like that.  Those are binary packages. Those are binary, native Node packages, right? Some of those packages,  I already pre-built. A good example is SQLite for Mac. I already pre-built, so just download  the binary package and it's there. But it's not going to work with Electron because even when  Electron is a Node core, it's Node Node. So, what you have to do is rebuild  that binary module for Electron. It sounds complicated. You can do it by yourself if you  want to have fun. But the good thing is that Electron Rebuild does that for you. One of the  things that we do is starting the posting style in that Electron package.js file, we put that  Electron Rebuild to after install all the dependencies of Electron, we just rebuild  all the binary packages needed that we use too. We use SQLite and we use PouchDB.  PouchDB as well, yeah. And of course, the next thing is testing. I mean, we do a lot of unit  testing for our web applications. And so, how do we actually go about doing testing for this  environment, Christian? It depends. First, obviously, you are doing unit testing. And unit testing  continue exactly the same as you do JavaScript testing. So, if you're using Mocha or you are  using Jaspin or whatever and you use Karmas, the runner, continue using it. What it changed  is that when you have an Electron application, you have to test Node integrations with the  test of system. You need to test two things, right? You need to test the shell. Yeah, yeah. You need  to test the shell. Because what you want to test first, you know what? I want to test that if,  when I click this button, right, the menu bar or the tray icon that I have, just start, I don't  know, blinking. Or that when I click this, I get a new message. I will get a batch in my icon telling  me that I have a new message. Those are the things that you want to test that you cannot test  naturally in something like Jaspin because that works for web. Okay. Well, what about Selenium?  I don't know if we use a lot of Selenium. You continue using Selenium because you are testing  the UI itself but Node integration. For the integration, the test you have to use something  in a spectrum. Okay. Okay. And what about headless testing? Yeah. Right. You need that only if you  are using testing in Linux or Mac. That is just the server version. There is something named  virtual frame buffer. Okay. You just have to install it. What it does is just, it's a fake X server  that just like display the stuff and you say, oh, is this in this place and this place? And it's a  yes. Okay. And Windows in there because Windows have it. Okay. Yeah. But yours use Windows. So it  works. Yeah. So why don't we actually finish off with some tips and tricks? I mean, some of the  things that we actually learned while we are rewriting this application. So the first thing,  of course, we've got is packaging the dependencies and so on. Right? Yeah. Sorry. You have to patch  those dependencies. Everything, as I said, don't try to serve things from the CDN because you don't  have that. You probably won't have connection. And there is no point. It's going to make all the  application laggish anyway when it's like the first startup. So just put all those dependencies  locally. Right? But it's just not those dependencies, right? No, no. In this is like the case of the  Web API stuff. What you do is that those, that XE file is part of your electron. You include that  as resource, let's call it. And what electron actually does is that it puts that in a resource  folder. So when the applications is installed and they compress, it's there. Right. So you want to go,  do you know what? There's like, there's another electron, good electron app. Can't remember the  name. It was not real audio, but it's a SQL database browser. What they do, they have the part that  does all the query is written in Haskell. So they include Haskell and the Haskell part together  with the electron package. Right. So because it's self-contained. So when you install that, you just  can put that. Visual Studio Code does that as well. Okay. All the things that you use like NPN,  you see like the task manager, you will see that it has a lot of child, the children running with  the application. Just put those things. How do you connect with them? IPC. IPC, yeah. That note  is pretty good with it. Okay. I mean, you can do it, right? I mean, you can effectively, you can  spawn off other applications to actually do some of the additional work and so on. Yeah. And then  if you want to trigger it, you trigger it through IPC. Yeah. I mean, particularly because JavaScript  is notorious for running. One of the problems that you will find, right, is multi-threading.  Yeah. Or number crunching. Because what happens that you're wrong only in one thread. Yeah.  All the studies are running in one thread. So what happened? This is the same consideration for any  other desktop application. All of them are seen like the UI runs in one thread. So if you want to  crunch number, do something that it will take time. Yeah. Don't do it there. Right. What you do is that  you use web workers. Offload it. Yeah. Yeah. Offload the operations there. Yeah. Just do whatever  it has to do. Yeah. Connect through IPC back to you with the results. Yeah. Problem solved. Yeah.  And you got this include DB with the application. Yeah. I mean, a lot of, you don't have to include  a database. I mean, a lot of people probably prefer to have a server running centrally and then  you have your client application and all the databases served out of the, out of the server.  So you connect through to an API and you do it. But in our case, because we wanted to do it in a  disconnected mode, we wanted to have a local database as well. And although our original proof  of concept was done using SQL server and SQL light, the one that we're actually currently doing uses  MongoDB. And so we had to package up a version of Mongo along with our application. Yeah. But  that case is actually very simple as well because at the end you have an MSI. Again,  as I said, it's there. It's self-contained. Yeah. So we package the, we, in our case, we package  pouch, don't we? Yeah. Yeah. Yeah. One of the things, yeah, yeah. In that case, because it's  compatible with the MongoDB API. Yeah. One of the things that many people don't, because you  mentioned grunching numbers and things like that. Yeah. Don't be scared if by any weird reason,  you really need to do something very native or there's an integration that you need to have  with the desktop that is not there yet. Just write C++ code. Yeah. And just create that  electron plugin. It's actually really simple. I did one and it's really simple to do. Okay.  Just don't be scared of that. And of course, the last one is when you're writing a web  application, one of the nice things about the web application is you actually deploy it centrally  to a server and then pretty much everyone gets it at the same time. Now, you know, when,  with something like an electron application, you need to, you kind of link to have an auto  of data, right? So you want to talk a little bit about that, Christian? Yeah. There are like two  ways that you can do this. And it has an auto data as well. In fact, there are like many ways to do  it. Yeah. Right? But again, the secret here is thinking as a desktop application. It's not thinking  as a web application or something like that. So you can have an auto of data. There is one,  there's electron of data. That what you do is that you use an npm fit with your application.  Yeah. So it notifies that. And the other is made by GitHub as well, name a squirrel. Okay.  And a squirrel, what you do is that it works the same. But what you do is that you put a new,  it has a new get fit instead of npm fit. Okay. You can use both of them. Okay. Right? Right. All  of them are fine. Right. And that's one of the things for us to consider when you are writing  this application itself is now that it's out in the wild, how do we actually keep updating it?  That's something that we need to think about. Now, hopefully, you know, that's kind of like  giving you a bit of an insight into creating an application using electron. This was by no means  a, you know, our aim wasn't to give you a bit of a technical showdown on how to do each and every  one of those things, but to give you a bit of an overview and give you an introduction to electron  itself. In fact, I wouldn't interrupt there because in fact, the secret of this talk, and that was  the subtitle, which I realized that is how to sell electron to your CTO because that was actually  what I did. Right? Yeah. I have, he was reluctant. He was like, no. And at the end, it worked. Yeah.  So, you know, I think we set out to show you why, you know, what our use case was and why we want  to use electron, just give you a little bit of introduction, how to create the application,  and so on. And just, you know, we wanted to wrap it up with a few considerations and things  like that that we actually learned in our own journey. And if you've got any questions, please  feel free to ask those questions. Now, I know, like in past experience with Oslo, you know,  people have generally been very reluctant to ask questions. So, you know, you, if more than welcome  to actually send us contact us via Twitter, those are Twitter handles over here. Any questions, by  the way? Yeah?  Yeah.  Can you package your application as a mobile application for Android?  At this stage, it's more focused on the desktop application. So, the short answer is no. Right?  I think there have been a few questions that have been asked in the forums on whether, hey,  can I actually ship it for Android and iOS and so on? But I think one of the problems is going to  be, even if we are able to do it, is to get the Apple Store to approve your application. Right?  Remember that one of the things that happens here is that one of the advantages of Electron  is that you have only one API to talk to the desktop. So, in cases like that, the mobile phone  doesn't have, it's not a desktop system. So, there's no point. You will have to remove many things  from it. One thing that I'll actually mention though is you can actually deploy, there are ways  in which you can actually package it up for store. So, if you want to, so that's part of the, you  know, it allows you to go look up the GitHub site for Electron. It's got a whole bunch of  guidance on how to do it. Yeah. You can pack for Windows Store and pack as well for the Apple Store.  There are just a few considerations about the things that you should not do, for example,  certain authorizations and things like that. Yeah. Any other questions? Yeah?  Yeah. That was a good one. Yeah. What we use is a queuing system. Yeah. We use an internal queue  because we have that in the cloud system we use, what we use in the cloud for the queue. We use a  queue. Yeah. And locally we have a local queue and small database in level DV as well with all the  messaging. And then what we do is just replay that. Yeah. Did you have to open the program to make  sync or do you sync? We just like, we just imperatively, we say like sync now. Yeah. Many,  many times we just have to do a right click sync. It's a little bit complicated. I mean, like,  I think one way is like, oh, you know, as soon as you get your network connection, let's actually  do a sync and so on. But I think we went against that approach, you know, you go in and pick when  you want to sync and then you sync it up. You can detect, in Electron, you can detect when you have  an internet connection or not. Yeah. But the problem that we have with the detection is what  they call the LAN party, the LAN party mode, because it's not just a desktop that the doctor takes.  We usually insert them, for example, the flying doctors, they just go in groups. So what they  have is a small server and then the doctors just connect to them. So one of the things that we  add there is auto discovery by Pio. Yeah. That this is an integration. You cannot do that  in web. So it discovered this and said, like, oh, this is actually the server right now.  Yeah. Just bear in mind that, you know, this is still a work in progress. And maybe, you know,  in a few months time, and it's all completely ready to be shown, we'll be able to show it.  Yeah. We hope that will be soon.  How do you handle the installation of updates? Right. MSIs. Yeah.  In the case of Windows and DMGs. And in this case, we use actually,  we are right now, I started using a squirrel, but we still like testing. Yeah. So it's not,  it hasn't been fully deployed yet. Yeah. Yeah. But right now, what we're doing,  the Windows customers that is, we're start deploying Windows customers is MSIs. So that is  actually pretty simple because updates and things like that. In fact, for some people,  we actually just send them zip files for a lot of those things. Yeah. Yes?  We saw the studio calls users as squirrel. Atom uses squirrel as well. If you, a way,  a simple way to see that and why, I don't even know if it's called a squirrel anymore,  but I call it like that because when you see Atom, you will see a small squirrel in the corner  that is blue. That means that you need updates.  If you just want to update some HTML and JavaScript, is that possible?  I was, that is, yeah. It can be done. In fact, one of the things that this lack client does  is that it just connect for first time because it's like you have to be connected, right?  When it's the tech connection, you just go to the CDN to see if there is new version of HTML,  of the HTML or files that it needs and download and keep it locally.  Right? But it makes sense in that case because it's a chat program. You need to go in connection  to chat, right? But yeah, you can do that as well. You can just, because you control the moment  that you start. So you can just do those requests and ask, there's a new version and things like that.  Download, keeping in the folder where you want to just get that content and then serve it.  Yeah, there's one other question over there. Yeah.  What about debugging and profiling?  They are tooling as well. The guys from GitHub, they actually, in the web page, you can see,  they deliver like a testing tool for it. In fact, in the old time, what you can do is that you have  the whole Chrome debugging experience as well. Yeah. Sorry. Got that. So you just put open DevTools  and it will just show the DevTools. That is the same that you have in Chrome. So you have as  well those plugins and things like that. So notice this is actually running, there's another  application that's running. And I just hit control shift high and brought down the debugger, the  Chrome developer toolkit, whatever you call it. Yeah.  Yeah, there's like no MP, it's actually an MPM package to do that. They are like...  So what are the questions?  If they have packages for USB, Bluetooth, and things like that, yeah, those are like native  MPM packages that you can use. Do you will only, in that, remember the consideration that to use  it with Electron, you will need to use Electron Rebuild. Any other question, guys?  So do I understand correctly that there are native Windows building tools for that? Or do I have to  use the cloud service? I mean, in this scenario? Oh, no, no. You just use TeamCity or TFS or whatever  it is. We use that because we are just trying to put everything in the cloud. You don't have to.  You're going to have to. You can just build it in your machine and things like that.  But I think one of the key things, if you're building for a Mac, you do need a Mac.  Yeah. So that's the one thing that you need to think about.  Right? Oh, sorry.  Yeah. Yeah, yeah, yeah. You can.  Yeah. Yeah, yeah, yeah. I was waiting somebody to ask me.  Yeah, you don't package it. Yeah.  Are there any performance? So it's like you look at the Google, you don't get the things like that.  Like 300 normal C, click delays, like that.  The question is, do you have any performance delays? Right?  No. Well, the same thing that is going to happen with the web, right? You are not going to just  put JavaScript to crunch numbers. Yeah. So here's the thing, right? So there's the problem of network  latency. So if you're actually hosting all your content from the web, which is what a lot of  phone gap applications do, you will have the same amount of latency that you have, like a typical  web application. But if you are caching a lot of those HTML and JavaScript and so on locally,  it's going to be pretty snappy. It's going to be quite performant.  Yeah. One of the outcomes that I want you to take here is that it's really simple to start.  Yeah. So go and try it. Yeah.  And maybe who knows, maybe the next desktop application is going to be a Charlie and Java  as a group application. Yeah. Yeah. Version one has been released. It's advanced very fast.  We would expect that to have more desktop integration, more teams interacting with the  desktop, because that's the secret at the end. You can't integrate with the operating system.  So who knows, maybe soon we will have preview handlers written in Electrum.  Things like that. All right. Thanks for attending, guys.  And thank you very much. I hope you guys enjoyed the NDC and have safe travels back. Yeah. Thanks.
Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_0_59.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_60_4187.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_4188_4235.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_4236_4943.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_4944_11519.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_11520_11747.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_11748_16367.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_16368_16415.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_16416_16487.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_16488_20855.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_20856_22235.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_22236_25811.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_25812_25859.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_25860_27071.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_27072_27395.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_27396_28127.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_28128_28175.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_28176_28811.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_28812_28895.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_28896_29291.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_29292_29567.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_29568_29615.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_29616_29663.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_29664_29711.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_29712_29807.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_29808_29855.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_29856_29963.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_29964_30047.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_30048_30155.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_30156_30239.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_30240_30467.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_30468_30563.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_30564_30659.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_30660_30923.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_30924_31007.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_31008_31151.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_31152_31439.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_31440_31715.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_31716_31787.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_31788_31991.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_31992_32039.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_32040_32087.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_32088_32819.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_32820_33647.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_33648_34439.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_34440_36059.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_36060_36107.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_36108_36155.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_36156_36203.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_36204_36251.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_36252_36959.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_36960_42083.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_42084_42131.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_42132_42419.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_42420_47855.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_47856_47903.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_47904_47987.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_47988_48539.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_48540_48827.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_48828_49187.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_49188_49271.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_49272_51647.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_51648_52139.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_52140_60647.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_60648_60911.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_60912_63407.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_63408_63707.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_63708_71747.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_71748_71795.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_71796_81779.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_81780_82031.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_82032_82271.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_82272_82319.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_82320_84587.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_84588_87023.png Write_once__run_everywhere__is_not_a_myth_-_Mahesh_Krishnan_Cristian_Prieto_87024_87682.png