 Okay. Hello everybody. So I'll be talking about Electron. So just wanted to see a raise of hands was like how many people have worked with Electron already? Anytime before? Okay. Anybody here worked with something like Electron say Node Webgate or Tint? Okay. So this will start from the basics and a little bit about what OS works. We can put into Electron and how we can build ship maintain cross platform projects in Electron. So just to start with I'll just tell about the architecture of Electron and what are the components in it. But before that, how about, let's say in five minutes, how you can make a simple Hello World desktop app using Node.js. So Electron has made it really very easy. So it's as easy as you go install the NPM module called Electron earlier. It was called Electron prebuilt, but from I think a couple of months before it's now you can just use the packaging of Electron. While you're installing that, if you want, for example, so since Electron is the native module, so since if you want to install the 32 bit version on S24 bit OS, for example, you might want to do that on Windows or on Linux. So you can also give the architecture name and download accordingly. You basically just like any Node.js project, you would need a package.json file and main.js, which is going to be our main script, which is going to run and an index.html file. So this is the one which will be our UI in our app. So one very important thing that we need to add in a Electron project is in our package.json. We add the key entry called main and this basically tells which script is going to start when you start the app for the first time, right? So you just point it to main.js. Let's just look at the script and we will understand it in detail. But you create a function called create window and we create a new browser window of given width and height and we load the URL of our file which has our UI, which is the index.html file and whenever the window is closed, we just nullify the intent. We require Electron into a browser window of an app and we have a simple event called ready. So whenever you open the app, we have the app becomes ready and at that point we can load the UI of it. And inside our index.html, we just have just a simple hello world and the version of Node, version of Chrome and version of Electron is running. So just about this much and you run it, you will get this on your desktop screen. So this will be just like any desktop app you open. It will have its own window. It will have its own menu and on it, you will be seeing whatever was there in your index.html file. So to understand basically, what is Electron? How it came about? So I guess everybody knows about Atom, right? Atom the text editor made by GitHub, a very good text editor for web development. So when GitHub was building Atom, they wanted to build Atom using web technologies. So they basically did was they forked the source code from the Chromium project, which is Google Chrome and they removed everything in the browser. For example, your history and URL bar and all of that and just made a simple shell inside which you can run a web app. So just if we try to understand what are the basic differences in Chrome and Electron. So here is how the way things work in Chrome, for example. So we all know that in Chrome, Chrome brought about multiprocessing. So basically each tab has its own process separately and there is one main browser for process. So if anybody of you have noticed when you open your task monitor on your operating system, first time you open Chrome, there will be two Chrome.exe processes and further on you keep on opening tabs. There will be like n tabs, there will be n Chrome.exe processes and one main one through which the worst level things are accessed. So your v8, which is the JavaScript rendering engine, the webkit, which is your HTML rendering engine, an instance of each of these are created inside your renderer process, which is there for each of your tabs. The APIs with which you are doing network communication or storage or your GPS, the location and the user interface of the browser where you have your everything your back button, your URL bar and all of that that runs in the browser process. In the internal API, basically at the C++ level, there is something called a resource message filter via which communication takes place between the renderer process and the window process. So this is the kind of architecture that Chrome uses for their browser. So what GitHub did when they were building Electron was they formed libchromium content. So libchromium content is the part of Chrome inside which your v8 and webkit part is rendered, like basically the document API and not the browser API. So they fork that and inside that we are able to run our HTML and our JavaScript and all of that stuff. And so this is how basically the architecture of Electron looks like. So instead of the browser process, now we basically run Node.js process inside which we have all our native APIs, everything that you can do inside Node.js without any restriction like you have on the browser side, you cannot access files which have not been put into the upload window. All of the restrictions are gone. The sandbox is not present anymore. It can have full access to the operating system. It can do network storage work. It can access GPS. Anything that's available to Node.js is available to the main process. Each window, so when we're using Electron, basically we are talking about windows instead of tabs because, for example, like using Mac sort of word, you can open up multiple windows for different documents. So like that we have different windows. So each window works very similar to how tabs work in Chrome. And instead of the resource message filter, there is a JavaScript level API here which is called IPC which stands for inter process communication. This is how basically the architecture is set up inside Electron. So how basically the processes are different. They are running on to this part, the top part that's running on a separate instance of V8 the way Node.js runs any JavaScript that you put like inside a script tag in your HTML, which is going to come on your browser. That is going to run on a separate V8 instance. So these two things cannot directly interact with each other as such. So for that, the IPC exists. And by the IPC, we have got basically there are certain things like the shell, the screen, the clipboard. These share a common context. Everything else we have to do very similar to how we use in Socket. How many of you have used Socket? Socket.io? Okay. So Socket, you have a basic idea of how you can send events from the client, get them on the server side, send events from the server side and get them on the client because it's the event emitter API. So here it's very similar in inter process communication inside Node, sorry, you create a channel, which is just like creating a Web socket and then you can subscribe to particular messages, which is like creating a on function and you can receive messages, which is using in socket. You have emit. Here we have got a send function. You send a message inside the message. You can send any kind of an object, any kind of data you can send. And via that, you can basically interact with any one of your renderer processes. Each of them will be different IPC clients and there'll be one main process which can interact with it. So for example, you want to drag a file into your app and it should save it somewhere. So you will have to send the object of the file from your renderer process into your main process to be able to save it to your file system because your rendered is just like any web app. It does not have access to your file system. Your main process has access to your file system. Similarly, you can also do asynchronous stuff via sending callbacks instead of sending objects directly. Both the things are available inside IPC. So everything that you can do in a web app, whatever you can do with HTML, JavaScript, CSS, that is possible beyond that when we are talking about desktop apps, there are certain more things we want to do. For example, creating menus, creating a notification tray icon and having our app run in the background. So all of these things, there are various APIs available inside Electron to access them. So first of all is menu. There are two kinds of menus. One is an application level menu, which is basically when you open an app and you see file, edit, view, all of those things. And then there is the context menu, which is available when we say in our browser, we right click on a word and we get spell check inside it. So creating menus is a very easy thing in Electron. You create a template of your menu, give a label to each root item, and then you can create a submenu, give labels to each item. And you can then assign any function inside that that will take place when you click on that thing. You can also assign radio buttons and selectors inside your menus. So there is a menu object inside Electron. Inside that we have got a set application menu function using which we can create application menus. Then for example, we want to create context menus. For example, the option shown here, this spell check by default, the render process does not have something like a spell check, but you want to add something like a spell check. Then here we have to, as you can see, create the menu from the remote. So the remote when we do require Electron, we are basically getting the reference from our main process because this code is inside our render process inside the JavaScript that will be running on the UI. So here we need to get the reference of menu from remote. Then we can create the menu and simply you can then add it to the context menu event which happens every time when you right click on any part of an HTML, the context menu event comes up. You can fire up that menu and show the options from it. Then comes trays. So a tray is basically like on the Mac, the top right part of notification tray windows, right bottom part notification tray. So if you want anything inside your app to keep running without a window, something like a background process. So then you can use trays. There is a tree API and mind it, this part again, it's HTML only because everything that we are doing here is going to be just like a chromium window. So it's just like a chromium window here. You're writing it in HTML. It's not a default native OS UI as such. Then we have got notifications here. So by notifications, notifications were very similar to we have in HTML5 apps. Just using your HTML5 notification API that will work because the front end part, anything that's available as part of HTML5 that's going to work here. The latest version of electron uses the same lip chromium content API as is available inside Chrome version 44 and above. Then we also have the recent API. So if your app is something like the atom app, which can open files, so you can have reasons which will work even if your app is accessed from the quick launcher in windows or from the dock in Mac. Then we have got launcher menus. Now this part is something when we are going to do cross platform, this differs for all the three platforms having launcher menus. Basically, if you have put say Firefox in your quick launch menu, you will see that you right click on it. You get two options. One is to open Firefox and another is to open it in private browsing mode. Similarly, you have Chrome in your dock. You will see there will be two options to open to Chrome directly and one in your incognito mode. So how to launch app in different modes? These things happen in different ways. So for windows, there is an API called the jump list API, which is very similar to Windows native development you are using in .NET. There is an API called jump list. Similarly, you create a jump list. Internally, the object of a jump list will be very similar to a menu object. You can create a label, an icon and a task, but you will have to add it to a jump list instead of adding to a menu and it will work like this. You will get options like this here. In OSX, it works entirely differently. So here we have to add a menu to the app itself instead of using jump list and those basically come up here in form of options. And finally, in Linux, there is no requirement to add anything inside your electron app as such. So in Linux, when we save our app, a shortcut in a .dextop file, there we can add different tasks to it. And like the three you can see previous change wallpaper, live wallpaper. So this is something that happens outside of electron as such. So how basically do you debug electron? So obviously in the renderer process, you open the developer tools in the window, but your main process that is not that straightforward to debug as such. But what you can do is when you are running the app, you can do electron and add a flag called debug or debug BRK. So using the debug, it is a simple debugging port is opened up using the debug BRK. It also adds a breakpoint on the very first line of your JavaScript execution so that when you open your debugger, your app is actually paused. Then you can add your own breakpoints and start working on it. So you do this and then you can simply create a script like this. You start your app, use the debug board, one, three, seven, for example, run node inspector. And then you can also do is you can use electron itself to open another window to debug it, or you can like here you can write electron, you can write Chrome, you can write Firefox, anything you can use, any web browser to debug it. But usually most apps use a script like this. So the app runs and another electron instance opens up to debug the main process. Coming to how you can actually distribute it. So at this particular state, you have got say your HTML files, your JavaScript files, your CSS files that is creating a UI. You have got your Node.js script to run your backend, but you are able to run it only after you have installed electron locally into your system. But when you are when you have to distribute it to your end users, then a lot of things come up. First of all, you need to rebrand it because the electron binary as such comes with an icon, the electron icon. It looks like the atom icon and the process and the application in your recent everywhere. It will be called electron, although it's your app. So that we need to change. Then we might need to package it. So like there's going to be a lot of source code files. You can package it in form of as our as our isn't just a it's just like a tar file, but it's an atom archive. Then we can package all of that together into always specific binaries, exe for windows, dot app folder for Mac and binary file for Linux. Then we can also create installers for it. And finally, we can also enable auto updates into it. So when we are enabling auto updates again, when you create your app for the first time, it's going to contain your source code. Plus it is also going to contain electron, the binary itself, the electron binary itself is going to be 40 MB in size. So when you want to program auto updates, you'd want to only update the change in your code and not update the whole app again, because the whole app will just the hello world app itself takes 40 MB in size. So the package structure looks somewhere like this when you basically build your electron project. So for example, the name of the project, if it is electron, this could be whatever name of your project is in Mac, it creates a dot app folder. There'll be contents resources app. And in that you will have your source code files. Or you can just package all of these things into an app.assar. Assar is just like said, it's just a TAR archive. It's not any proprietary format. It's not encrypted. Source code is easily visible inside this. So this does not provide any kind of source code protection. It is just a bundling thing for windows or Linux. There is no dot app concept here. You can just put it in a resources folder. So this resources folder basically becomes your distributable file at this point. Then you will need to rebrand the electron binary so that it does not you run your app. It does not show the electron icon and the electron name. So rebranding it is very easy in Windows, Mac, Linux and all three of them. You can just change the name of the binary from electron.exe. You can name it whatever you want it. And inside Windows, Windows apps have the icon file embedded into the EXE. So you can use any kind of a hex editing software for Windows and change that icon. There are a lot of tools available. You're going to just cover it, which does this automatically for you. So there is electron package and electron builder electron package. What it does is it creates the EXE app and disc folders for Windows, Mac and Linux respectively. Electron builder works alongside electron package and creates Microsoft installable or a DMG or PKG for Mac, or it can create a DBN or thing RPM package for Linux. Using squirrel, you can configure auto updates using school. You can configure auto updates such a manner that only the source code gets updated just your HTML JavaScript files get updated, not the electron binary all over again. Both of these pack, both of these npm modules are available in form of like a global install for a command line method. You can also install it locally and use them with grant or gull for whatever is your favorite CI tool. In the future of electron, there's just one very important issue being discussed these days is about that thing that the electron binary is for TMB in size. So the electron developers are thinking of making something like the Java runtime environment. We can have an electron runtime environment. People can have like my app works on electron minimum version one. So if there is electron version one or above available in with the user, so only the HTML JavaScript part gets downloaded and it gets run by the electron binary already present on the users setup, which had been the case with Chrome apps already, but they are now slowly getting shelved off and they have disabled the APS for new apps already. There are certain UI kits available like photon and react desktop. So just like CSS framework basically makes your whole app look like the Mac environment or the Windows environment react desktop has both. There is photon kit, which has a larger Mac framework library can create a whole Mac app kind of feel, but photon does not have windows or Linux shell, but they are developing it. So the thing that we discussed today, the API is you can get on github.com slash champion so much JS for electrons example. So I've created it step by step adding each component, the menus notifications, all of these things. There's a demo here. You can also check out a lot of tools and libraries available for electron at Cinderella sources repository called awesome electron. You can get about what components are available, what tools are available, what build packages are available, all of that stuff. So that's it for the presentation. If there are any questions from anybody, we have a lot of modules, right? And no, electron is one of them. Yeah. When would I use it? Like see a normal hello world example can be done. Yeah, so when would it when it is required? So first of all, is if you want to make something cross platform and don't want to deal with cocoa for Mac and dotnet for Windows and look at GTK for Linux and all of that stuff, you can just make your whole UI in web and we can ship it to all the three operating systems. Some very good examples are visual studio code is built with electron the slack desktop app is built with electron. There is also some unofficial messenger and WhatsApp desktop apps. So they just run WhatsApp.com web dot WhatsApp.com. But everything is cashed into your local folder. So you don't need to sign up all over again. Notifications come as native notifications. So that you can do with electron. You want to create something like atom that is also possible. Also, can I use any other library like Jake Mary with it? So on the renderer side, you can use anything that you can do with a web app, you can use any front end library that you want to what if I want that it should not it should basically disable the node environment if I'm writing it should disable the node part of it. Yeah. So that you can just distribute in it as form of a simple web app. Like this only so what electron as an extra is providing you is hooks into the operating system. Okay, Internet as a native app, you can put a train notification with it. It can keep running you can like have say like when you close the window, it hibernates and it come back comes back. So it is the status preserve. Hi. Hi. Can you hear me? Yeah, yeah. Right. Great. Great talk. Thank you. So I wanted to ask you about the whole file reading process. So when you're using the atom at this point, if I have a bigger file when I want to open on atom, yeah, it has a bit of a tendency of crashing. Yeah, so the performance part is that it is at the end of the day, the whole thing is going to be loaded into a V8 engine on the renderer process and any performance issues you have with V8. So that is going to come up here as well. Like if you cannot open a file inside say Chrome, you cannot open it inside electron either. So that is there. That problem is definitely there. I've got another question. Yeah. So the dream is to build one web application which can run on the browser as well as on the desktop. I didn't get you. Sorry. So the dream is to get one web application which you build which runs on both the things right? So I'll tell you what you can do. A very good example is you create the back end in Node.js as a web server separately and create the front end separately. Okay. You basically when you are deploying it as a web service, you're just creating say sockets or rest connections between the two. Right? So here in the electron app, your Node.js script can run its own server as well. Right? And just your saving your files on the server instead of that you use the file system API of the user save it in his documents folder or something like that. So there are a lot of examples. So recently I was making an event management system and it is available both via web service as well as an electron app. So inside the electron app, the server side script is also part of the electron process. Hello. Hi. Yeah. Thanks for the talk. Should I speak? So in order to port an existing web application, for example, right? Yeah. What kind of effort does it require in general? Let's say it's a medium sized web application and you want to port your existing application to a desktop. So the front end part is not going to take any effort because we are just loading our HTML file and it works right away. Right? And if it internally uses a server, a back end part of it. So if your back end is say written in Node.js, then I would recommend you port it to electron itself because it's going to require only a few changes in the files where you're saving and all of that where you're creating the server and the port and all of that. So instead of creating a rest server, you can use IPC to communicate between the back end and the front end when you're doing it for electron. But if it is not if your back end is not in node, then your desktop app can communicate over the internet. No issues with that. Yeah. So these are the things that you would do when you are starting your project, right? So for example, if you have an app, yeah, are there like very complicated things that you know, you are, do you reach a dead end where you cannot move forward in order to create a desktop application. So my experience with electron has been that mostly I face a limitation with performance issues because node can handle things at a certain speed and a certain size, of course. So for that case, you can always package some native libraries into it. For example, if you want to pack it, write some part of a code in C++ and compile that in forms of native modules for each of the three operating system version. So your node can just call the C++ program and run it. So you can have there are some libraries available which have go lang and node.js bindings. Okay, great. Thank you. So you said there are always specific groups, right? Like always specific API, which we can use. Yeah. Is it possible that I'm creating for two ways? Yeah, I write different modules for separate ways. Yeah, building I get the correct way. Yeah, you can just do process.os and it gives you Darwin or Linux or Windows and you can put an application for them. Module, I'd like to check. It's not like that. While building it will automatically take the module that you can put inside your grant girl for grant tasks because electron, package and builder, they build separate package for each operating system. So you can configure that part of your girl for grant task list. Hi. So you told about debugging part? Yeah. So is it possible to debug it remotely? If like you have a static IP address or you can port forward your laptop, then yes. No other way. No other way. Okay. Hi. Hello. On top here. Yeah. So basically, can you hear me? Yeah, yeah. Yeah. So basically, js jargons.com if you've seen. So, so the backend is an express app connecting to mongos. So do I keep it? Do I package it along? So it is on the front end, we use technologies that we can package it while building the app, right? But on the back end, since it's an express app, do I keep it local to this particular electron app? Keep the express part in your electron and connect to mongo over internet. That's what I would suggest. Oh, you still want to hit the DB online, right? Like is your user specific or your DB centralized? If your DB is centralized, then it has to be somewhere else, not on the desktop. A little part of it should be user specific. And then the others, the generalized data should be you can use SQLite DB for the local part here. But the centralized mongo DB you connected over the internet. Okay. And we also have service workers running. That will work perfectly. The Electron supports it? Yeah, it does. If you're using Electron 1.3 and above, then service workers run on it. Okay. Thank you. Is there other questions that I can take them offline? Yeah.