 All right, it looks like it's time. Hi, everybody. I see a few familiar faces from the Four Kitchens booth. If you've come by and seen the watercolor painting robot, you'll learn just a little bit more about some of what makes that work today. Looks like we've got a few more rolling in. In the words of my incredibly smart co-workers, we should not punish the punctual. So I'll just go ahead and get started. Here's my slide button. This will work. Welcome, everybody. My name is James Todd. I'm a developer and engineer at Four Kitchens. You can find me on GitHub at Tech Ninja, or on Twitter at Tech Ninja 42. Feel free to tweet all about this. I have been dribbling for over 10 years, and I recently transitioned from contracting to full-time at Four Kitchens, and I haven't looked back. In my free time, I toured Bad Camp, Maker Faire, and the world with my eldest progeny, working to get girls and kids into STEAM and programming through community outreach. In addition to this and other work, I support and maintain two fully open-source electron application projects. Oh, I also put another one in there. I'm also a co-author for an exciting series of Arduino programming books for kids. And I also support and maintain two open-source programs for in-electron called RoboPaint and Pancake Painter, both of which you can come down and see demos of at the Four Kitchens booth. So, let's get into it. For those just starting out or not well-versed in how JavaScript development goes, don't worry. Even though I'm going to cover a whole lot in the next 45 minutes or so, I've built in plenty of time at the end for questions or comments or anything else that you are curious about, or even stuff I didn't entirely talk about. So, just hold your questions to the end and everything will be great. Thank you. All right, so quick, just a little term reference for anyone who doesn't know about some of this stuff. We'll just kind of go over what some of these things are about. If you want, you can take pictures of these and reference them. So, JavaScript, this is the programming language originally created for web browsers back in the day and in use around the world. Node.js, this is a JavaScript build for servers or regular computers, and it now runs many popular sites and services you may have used. NPM, this is the Node package manager for Node.js. It lets you download modules and libraries by name that let you extend functionality. So, other people write libraries and stuff and then you can download them and use them immediately. An API, when we say API, we mean it is an interface written to let programs do something with it. A programmer will make something and then you can program with it. Restful, this stands for representational state transfer and in general it's used to reference when you have a standard for running APIs over the web. If you visit a website, you've used it. And then we have the DOM or the document object model for web page elements. If you think of HTML tags and other low level data attached to them on a web page, that's what that is. We have React. This is a popular Facebook framework created for component-based user interfaces and holding on to state, which state is where you hold on to information and then see where it changes. Express is a very popular Node.js web server and Restful API router. If you wanna host an API or a web application on Node.js, it's a popular option. Headless, if you're running a system or service, it's headless, that means that you're running the backend without directly connected front-end. This is a very popular thing to do with Drupal these days. All right, so what is this Electron thing? We have a quick show of hands. Who knows about what Electron has seen it? Look at that, get you guys. This'll be easy. So in simple terms, Electron is basically a slimmed down version of Chrome that's yours to customize to your web and make pretty much anything with. Using its world-class HTML and style sheet renderer combined with the power of Node.js. More technically, it's a shell, an API layer on top of Chromium, the open source base for Google's Chrome web browser, that also happens to contain V8, the engine that runs Node.js. This means that basically every web application or site that runs in Chrome can run in Electron and JavaScript code running within it has access to the full Node.js API, allowing you to build Node.js applications using modules, using Require, installed by NPM or Yarn, while still using native document object model and window-based interface that you're used to working with in a browser. It is the best of both worlds and in one easy-to-install package, and it rocks. It builds for Windows, Mac, and Linux natively. Every system Chromium has a build for, which can include things that don't exist just yet, and includes a huge variety of APIs and native OS-specific dialogues and notifications and a whole heck of a lot more. Different than other Node and browser shell implementations like NW.js, Electron uses a main process and a renderer process. Using these two separate processes, it allows you to run your app and entirely window-less if you want to, and be able to control browser crashes or other low-level configuration while remaining multiprocess and extremely quick. On multiprocess machines, this is a huge boon. Using Electron makes development a snap with a single JavaScript code base for all systems for your application. You can implement with any of the common frameworks or libraries already used in millions of sites across the web for client-side, and you can quickly debug style sheets, screen drawing updates, network connectivity, and tons more with the debug tools you're already used to inside of Chrome. And after the initial application download, local files are network-agnostic so your app can be used completely offline as long as it's written to do so. So who is using Electron out there in the world right now to ship modern native desktop applications? Here's one. Electron's backing by GitHub and subsequent dogfooding in their flagship text editor, Atom, means they've fully committed to its support and rapid development over the past four years. A bit little by some devs who find its memory consumption at startup time a little bit much. Thanks to its web standards, UI, and Node.js backing, it's garnered a huge following and over 5,000 published extension packages to improve or augment its functionality and over one million active monthly users to date. As long as Atom continues to thrive in its community, Electron itself will continue to gain quick fixes and updates as both Chromium and Node.js communities use cases grow. It is really awesome. If you haven't tried it, you should definitely give it a try, totally free. And then spurred on by movement to have an uncolored space for writing WordPress Maker Automatic recently released a WordPress desktop, a dedicated interface for managing content and writing posts, calling it a seamless cross-platform experience that allows you to focus on your content design with no browser tab to distract you. By using Electron, a small team of two to four developers were able to leverage other teams' efforts in implementing React and Calypso to build the desktop app in just a couple of months. It really is that easy. Microsoft's recent expansion into open source includes one of their latest forays into web and code development with Visual Studio Code. Another code editor, but with their own Visual Studio Spin, you can run code natively, do debugging on the fly and integrate with other systems and run times like PHP. It's noticeably different than Atom and definitely worth a try if you're in the mood to experiment and see what Microsoft has been up to with open source. I've actually talked with the development team on this and they're really dedicated to it. They're gonna be continuously updating it and it really is worth a try. There's also a ton of other ones from smaller companies and Slack. You might have used that one. But you don't have to take my word for it. Go ahead, go to electron.atom.io slash apps and check out the other tools and experiments available there. And if you make an app, you can submit it and it'll show up on that list. So, when in Rome, making your sleek, powerful web app into a desktop application may seem simple, fun and amazing, and you'd be right. But it doesn't necessarily mean you should do it. Ask yourself a few questions before nosing into the deep end of desktop development as the application boomerang makes its turnaround from the web back to desktop. Are you writing it for the right reasons? Just a few weeks ago, a post from October, 2016 came across Hacker News by noted developer Joseph Gentle. It titled, Electron is Flash for the Desktop. An incendiary title and post, a deriding memory and CPU usage in Slack and accusing electron developers as being lazy for packing together an entire web browser along with their application. This soon sparked literally thousands of comments across both Hacker News and Reddit. Some agreed with them and others rallied against the ideas presented and the rest were either indifferent or rallied in defense of individual applications and developers' needs or choices in the matter. Policy bets, big league hacker for the Slack Electron app and maintainer for a number of electron tools and modules soon had the top comment on Hacker News, stating simply that it's delusional to think the same effort could be spent to build the exact same apps that are being built for Electron. These apps simply wouldn't exist at all in the existing technology for building native cross-platform desktop apps without that electron without that. Possibly requiring 10 times the resources to build and support, sorry. My throat's a little dry, sorry. This is not the end of the conversation, of course. I implore everyone to do their own due diligence and look into these comment threads in original post for useful information before diving in and signing the contracts on your next project. If you need to make a desktop app, there are definitely other options and with their own pros and cons. I will say that you're unlikely to find such an incredible breadth of community and resources than those available to Electron right now and in the near future. I have water now, thank you. We can do this. But first, before going headlong into a project, ask yourself these few questions. Can your app run offline reliably? Many desktop apps are expected to with the obvious accession of chat or other social media or internet centric apps. You need to consider some semblance of offline mode or app usage just as with mobile apps. You may need to queue something, you may need to access some form of API or authentication. Gotta think about it. Can you meet the needs of your users with a clean application update path and installation support? These are often completely new avenues for most users as application install can get messy. And even if it works 99% of the time, you still have fringe users with strange configuration issues on weird or old machines. Chromium does not support every single operating system. That is important. Can your users get enough benefit from the added download and runtime aspects? Electron can be spelt if you write it that way, but it takes effort to keep processor and memory usage down. And will the app bring enough value to a user to benefit not just having another web app? These are all things to take into account, but it needs to be noted. Some aspects of Electron are impossible to find elsewhere. Do you need to run low-level native functionality like reading or writing very large files or listing files locally on a hard drive? Hardware access, running native C libraries, not usually found in the current or near future web APIs? Complex image or video processing by GPU access with upload times or running expensive servers are not possible. Do you need to quickly port a node or node-only server or other application for simple client-side use? As a web app with access to a whole computer, you have the ability to run servers, compile node libraries, and a whole lot more. Do you need more multi-processing power with DOM access? Using Electron's WebView Abstraction, which we'll talk about in just a minute, you can have the power of an entirely separate Chromium process at your disposal with optional node support to use within your shared code base. Using IPC for communication, you can orchestrate incredibly efficient and fast user interfaces that asynchronously process and display data. And if you're still in the fence and you're worried about the cons or future possibilities, just give it a go. Because of the shared technology stack along with everything else on the entire pipeline, I encourage any curious developer just to give it a try. So many parts of the process are similar to existing ones, and there are so many helpful resources available that you too could have an Electron app up and running in a day. Or even before the end of this session. Long-term user support and release infrastructure be damned if all you need to do is see if your idea is possible. Not to mention developing with Electron can be just plain fun. So in the words of the great poet, ship stuff every day, or something like that. In the next section here, I'll show you a little about what I ship on the weekends in Electron. Should help you give you a little background on what a single developer can accomplish given a little time. As I said in my introduction, I personally maintain two open source Electron projects in my spare time. I've been the sole developer from the start and have been learning to get a bit better at everything by simply doing. I'm not 100% up to snuff on ES6, nor am I utilizing the best and greatest frameworks, but I am shipping real applications to hundreds of users around the world, and I think that counts for a bit. Going from Drupal and PHP development to JavaScript has been a long learning process for me, but I find that using Electron removes a ton of barriers for entry and allows me to experiment in a solid and reliable environment and allow for quick turnaround time. My first project, RoboPaint, started back in 2013. It's an experiment to try and drive my eldest child's watercolor bot project using JS and low level serial port communications in straight node JS. Originally created as the CNC server project using a simple express server, hosting web pages to load SVG files and parse them in a complimentary restful API abstraction to make talking to drawing robots easier. This exposes a simple set of drawing endpoints and manages queuing and buffering stateless commands against an inherently stateful physical robot over serial. This sounds pretty complicated. Oh, but it is, yeah. The end result is a simple to use drawing API that allows for color tool changes and compression buffering to allow seamless and fast drawing on robots from pretty much anywhere. And you can see a live demo of this over at the Four Kitchens booth. Due to a strange series of events, we ended up at the White House Science Fair and using the CNC server API running on a Raspberry Pi. I managed to cobble together in a few short weeks a live demo allowing President Barack Obama to draw Go STEM through an iPad app. Upon returning, we ran a successful Kickstarter to release the robot as a kit and I decided to release the script as a simple to install desktop applications for users via Node WebKit. In 2015, we switched over to Electron and we have not looked back. Thanks to Adam and other big name projects supporting it, the community behind Electron ensures that bugs that come downstream from Chromium are squashed quickly and features and fixes come in nearly weekly releases. The RoboPane application runs far, far faster and allows for really incredible multi-process support. So all of it has benefited users incredibly. One additional awesome feature I love about Electron which I mentioned earlier is the WebView tag. It's basically like your own little cloned Electron Sandbox iFrame. By simply embedding a tag in the window HTML with the source of another page, Electron manages running whatever code is given for the HTML in a new Electron process which you can send messages to and from via Electron. Electron's built-in inter-process communication or IPC modules. You can also attach a preload script to this optionally load node modules or run arbitrary code, transparently into the global scope for the WebView. I should have had more water today. This is the basis for drawing modes in RoboPane. The main application manages the connection to the robot and some basic API wrappers for modes and then modes are their own node projects stored on NPM. You just do NPM, install, Electron, mode, edit. And there it is. These are loaded dynamically from the node modules folder based on a few specific keys in the node module package.json. Each mode is its own application, running its own code, but simply interacting with RoboPane SVG input-output interface or through direct robot control. One second. Thank you, Randy. You're a lifesaver. What would I do with that? Yay! You're a great waterboy. This all leverages the incredible extensibility WebView provides and allows the main window process to run seamlessly even when the mode uses 100% of its own available CPU usage on multi-core machines. We have the watercolor bot running over at the four kits booth, as I mentioned before, so you can come by and check it out. It just so happens that the Slack application uses WebViews in the exact same way to sandbox different organizations within the application. And they have a great blog post on how they're working to keep memory usage down for power users as running these separate processes can get a little heavy with so many DOM operations running at the same time. Water saved me. My second open source electron app is Pancake Painter, a simple purpose built drawing import-export program for the pancake bot. The world's first open source commercial pancake printing machine. We were hoping to have this down at the booth, but getting the pancake batter was tricky. That would have been fun. Back in August of 2015, the creator, Miguel Bones, Waila, contacted me out of the blue and asked if I would build a desktop software and after seeing my work on RoboPaint. I said sure, and we worked out a base set of features in a week, and in about a month, I was able to build the entire app from scratch, from drawing, file format, saving, settings, menu, and everything. It's open source from the start. I created and managed everything through issue queues on GitHub, and you can trace every step of the applications for my commits and pull requests. Hopefully that'll help somebody. The app itself strives for simplicity, allowing users to directly control where batter should be placed in lines or fills for the notably difficult work of printing multi-shade pancake art with real batter. It uses the incredible open source vector drawing library. I know I'm not a very good artist. I should have done better with that. I just did it quick. It uses the incredible drawing library, paper.js for path drawing, breakdown of the drawing into G-code, editing, layering, interface tooling, file type export, complex path Booleans, and a bunch of other stuff. Paper.js is pretty darn amazing. You should go check it out. The app granted me the top red AMA on the 1st of January this year, and I hope in answering the hundreds of questions that there have, I hope to have inspired other junior developers out there who need to worry. I'm not sure what I wrote here. This is strange. Doesn't matter. It's more important to try and build something, an experiment, than to worry about making it exactly right. Give it a try, experiment. All that is really important, and I try and get that across. Back in February this year, we released a new feature to allow automatic tracing of almost any input image into something printable as a pancake. You can see here by simply picking a raster image with a complexity preset. You can quickly make adjustments and render vector strokes and fills optimized for creating pancakes. All fluid user interface elements use Flexbox for positioning and sizing, and all UI animations and blur are powered by style sheets directly. Isn't that awesome? That's cool. This leverages an open source C++ application auto trace, pre-compiled for all release systems individually to take formatted images and output SVG artwork via the command line 10 to 100 times faster than equivalent JavaScript code could accomplish. Electron makes the seemingly impossible or just downright difficult requirements like these not only possible to implement, but simple enough for a single developer to handle and ship in mere months. Well, in some circumstances anyway. So creating your first application project is easier than you think. What skills might you need to dabble in Electron? Electron bases a lot of its logic and configuration in JavaScript, but you likely can get by with a working example applications and simply add your own HTML and style sheets for starters. The rest of what you need are a few simple terminal commands with simple arguments. A more complete working knowledge of the incredibly popular Node.js and its packet management ecosystem will undoubtedly benefit you. But if this is your first foray into JavaScript, you likely won't get too lost as long as you know the basics of how browsers, HTML and CSS work together. So let's go ahead and take a look. Before we begin, make sure your operating system meets the minimum system requirements for Electron. And then make sure you have Node.js and NPM installed. Go to Node.js.org and download the installer. Fresh working directory to save files in. Terminal and command line access to that directory. And lastly, bring your working knowledge of the web and it'll all start to make sense. I mean it. Bless you. For development, you'll need just three files. Package.json, main.js and index.html. Create the files locally in your projects directory. And this will be handed to Electron when you start the app and it'll do the rest. Now let's look at the base minimum content of these files. Yes, I can show it. First one up, package.json. A simple JavaScript object notation file for the top level metadata and configuration for storage. You can have a lot more fields than this, but they're not directly needed. This is the standard Node projects syntax. Name your app and reference your main application.js file with all the dependencies. Just make sure to include the Electron package itself and this will ensure when installed on different operating systems, it'll start natively and with the correct version during development. Note we also have a start script defined that will utilize our NPM installed Electron binary to execute the app for us. Very simple. Next up, a little more in the main.js file. This code is the main process that always runs as long as our app is and creates our very first window. Here we define the initialization code and create and manage our windows and renderer processes. We only have one here. This code simply says that when the main process is ready, a window at a given size, 800 by 600 pixels will be created and then it will load our next file, indexed on HTML. The standard HTML and JS rendered in its own process separate from the main inside its own window. Whatever JS runs here can access the main process variables via a shared IPC interface and it can access all of the page DOM, low-level Node APIs and modules and Electron's native APIs that are specific to each operating system. Behold the all-powerful Electron. Now we switch over to the terminal, go to the application directory and just run npm install. With a decent internet connection and a smidgen or two of patience, this will install the correct Electron binary we defined in the package.json dev dependencies and any other dependencies we had in there. With that done, we can now run npm start. What? npm start. This will run the script defined in the package.json under start, which will run the Electron binary downloaded against the dot directory, otherwise known as the current directory. It's gonna play again, it's fine. Your pinned Electron version will execute the main JS, initialize the window and ta-da! You'll see this message or you should. Now you have the power of the universe in your hands, close to it anyway. So to shortcut all of this, to not have to copy down any of those files and stuff, just go ahead and clone this repository, follow the eerily similar instructions in the readme and you'll be running in no time. Did you get your picture? Got it, okay, good. You can now structure your application in any way you see fit and with any helper modules or libraries that you're used to using on the web, there's a bunch of example apps out there which will give you an idea but really you can structure it any way you want. And since you can use both in browser and node-based code, almost everything in the npm library just works. There's also a growing list of contributed modules to aid in the duality that Electron inhabits to make the development of Electron applications even easier. Yes, you can use jQuery if you want to. One of the greatest benefits of Electron is the powerful native APIs available. Everything from screen capture to custom dynamic windows, progress indicators, tree notifications, Mac, touch bar support, now in beta and tons more are available. Check out the API example app from the Electron homepage for an awesome demo of almost everything that Electron can do for a given OS. So you'll have to try it on different computers and you'll get different results. Now let's get into something a little more real, integration with a real life Drupal application. We are a DrupalCon, aren't we? Let's get it done. As quick aside, during my research for this session I found a project by incredibly enterprising developer, Sean Bousquet, who managed to figure out how to run Drupal directly inside of Electron using a portable PHP binary in Drupal 8. He stated that while this is technically possible, Drupal was really made for running on a PHP server deployed to the web and doesn't really lend itself well to the experience. Sean recommends running headless Drupal and interfacing with it via the Drupal API as we do here. Big thanks to some great work from infinite Luke Harrington and the Four Kitchens training team, members, thank you guys, for their Drupal 8 training and React to DoList application they held on Monday. I can show you how you can easily leverage an existing web application into Electron and use local resources to connect to remote Drupal data stores and APIs to keep app users up-to-date. Thank you, Randy. Take one for the team. Yeah, I was gonna say, this is just gonna keep going. All right, for those not in the know, Drupal 8 has been built from the ground up with external applications in mind containing a RESTful web API that allows for authentication of remote administration of entities and content with every site on it that's enabled. If you only run Drupal for content management and storage, not displaying or theming its content, directly it's referred to as headless or bodyless or decoupled, there's a bunch of names for it. Just to give you an idea of how popular this powerful method is becoming, just check out how many sessions at DrupalCon this year there are surrounding the topic. Every single one of these, it's incredible. If you go to these slides after I'm done, these are all links, so you can go directly to them and see the videos. This gives every properly configured Drupal 8 site the keys to allow a mobile external application, the ability to display or input content or data directly into your site. And with the waterwheel module installed on your Drupal 8 site, you can use the waterwheel JavaScript API to interact with your content in a more abstracted and cleaner way. With these abstractions and data separation, you can use React or something similar to that to control the display and distribution of content and let Drupal worry about the architecture, taxonomies and content administration. In case the idea is new, do you encourage everyone to learn more about how this distributed model is growing in efficiency, popularity and commonality? Check out some of these. Onto the demo. Now I've taken the waterwheel training application and simply built out a basic main.js wrapper. This is just an excerpt of it. Built off the Electron quick start example, given earlier, to launch a window from the index.html in the build directory and a little code to manage closing the app if the window is closed, something you'd likely not do on a Mac in a final application. There's a little bit more code you need for that but you'll see it in the example application. Next up, the package.json points to the js file and our index.html that we expect to load. And we had a specific line in the package.json for starting the app via Electron. As we did in the minimum example, including Electron as a dependency means it will download it just as we did for our minimum. Build of the application is running in for development. It's simple, using npm, we download the dependencies and when that finishes, when that finishes? Yeah, there's lots of stuff to get. I actually, I did actually use, I originally used yarn on this and it just, it died when it got to Electron. I think there may be something up with that. I'm not totally sure, but it took actually a lot longer. This part was faster though. I think this is the point at which we grab our swords and practice fencing and the hallways, no? Good piling. Oh, this isn't necessarily piling. Wow, that is long, isn't it? This is actually part of the joke. This is all prerecorded, so we don't need to watch this. I mean, we can if we want to. But man, I don't remember it being that, I don't know, whatever. Moving on, when finally done, we build the app with npm run build. This creates all the files in one place ready to be displayed by Electron. We wait for that to finish and then we run the application via npm start. This will launch Electron, pointing to our application directory just as we did with the minimum example. Am I actually gonna let it finish? Do I care? I don't care. Now that the Electron has been loaded up, I can log in with my Drupal test credentials and the app will load. I would data directly from the Drupal 8 site. I can see other to-do items on the list, give a thumbs up or even create brand new items. Each to-do item here is a node on the site and each thumbs up is also a node that references the to-do item for each node. From here, we could add operating system notifications to event triggers to to-do item event schedules, registering the app to run a startup window list and an operating system tray or add a whole host of other functionality. We now have access to the full Waterwheel API wrapper and through React to read, list, write and update content from our Drupal 8 installation, utilizing the JSON API standard. By default enabled, you can open the full Chromium DevTools and do full application debugging per window. We can run require on the console, pull global variables, mess with CSS, pretty much anything. We can also see network traffic, window drawing information, style sheets and even custom Chromium plugins, which there is one for React which would help you quite a bit. We say, ooh, ah, look at that. Yep, it really is that easy. Combine a mess of open source tools, a little patience and some great app work and you've got yourself a cross-platform desktop application that integrates with your existing platforms or APIs and looks really good while it does it. Be sure to check out the repo for that React training application to get a good idea of how React and the Waterwheel wrapper talk to Drupal and consume data. I seem to have a blank slide. We can just look at those cool design slides, or anything like that. Now, for those looking to ship for real, squirrel. Let's talk about what it's really gonna take to create your app, make it ready for users, get an updates, keep secure and use best practices and how to keep everything in its right place. The one I like trying to app boils down to a simple folder of files. You can't simply hand end users a zip file like this, though it really is all you need to develop from. You're going to need to build releases for all of your supported operating systems to give end users an easy to install single file download that does everything for them. The electron community has put a huge effort into making this as seamless as possible. For Windows, enter the squirrel framework. Squirrel was created to improve the tired, decades-old cliches of software installation on Windows, suggesting a better way forward with their five tenants of good modern software installation given on its readme. Integrating an app to use squirrels should be extremely easy, provide a client API and be developer friendly. Packaging is really easy, can be automated and supports delta update packages. Distributing should be straightforward. Use simple HTTP updates and provide multiple channels a la Chrome dev beta release. Installing should be wizard-free with no UAC dialogues to stop a user, does not require reboot and is .NET framework friendly. And updating in the background doesn't interrupt the user and does not require a reboot. It manages these goals incredibly well and the squirrel.mat counterpart mostly exists to make sure it uses the same update server architecture as the Windows version. If you're curious, Linux releases are expected to take advantage of existing package management systems, so it doesn't, there's not really a component for that. But Windows and Mac are kind of the harder systems to manage there. For building your app on all operating systems, package everything into a release folder using Electron Packager. You just run it on the command line. Then to create the installer for Windows, use the Electron Windows installer module. And with just a few simple command line configuration options, it'll manage signing, packaging, icon association, and creating a single EXE file to install. For Mac, using the module app DMG after packaging and app signing, you can automatically build a mountable DMG image with background and customizable icon positions. It's really cool. For Linux, there's modules for packaging Ubuntu and Debian .deb package files and one for Redhead RPM files. You can include extra information about the package description and company, et cetera, and it will actually show in the package manager. All of these operating systems assume they're being built on the target operating system. So some of these can run in other hosts. Mac builds are very picky about running on non-Mac systems. And parts of Windows builds can happen in Linux. But for the most part, I would recommend, sorry, building on the host system. You're gonna have the smoothest way forward. The good news here is there's plenty of top-notch, continuous integration services available that can run your release builds automatically on each operating system required in the cloud and on demand triggered from your repository updates. It's really cool. When you use your Execute to the Windows installer, they'll see a window centered on their screen that plays a gif while the setup installs. This is the one for the pancake painter. I actually contacted the guy on Reddit that made this. I was like, hey, can I use this? He's like, sure, go for it. Endless pancakes. All apps are installed to default user app storage locations so they don't need any dialogues to stop the user. And there's no setup to say where it actually goes to. Some people find this a little strange. So you can, in fact, use another installer. But I find that this is very straightforward. And for 90% of users, they have no problem with it whatsoever. One of the biggest aspects of having an electron app significantly different than a regular web application are offline files. These files sit in the application root directory and are served directly to electron windows and code. They load incredibly fast, but at a cost. They're not live on your server. This means your releases are locked in to whatever version a user last downloaded. In the land of web apps, this is a bit uncommon. With users expected to be downloading the resources on every visit to a website. In another way, this ensures your apps are at a given build at that version will be 100% guaranteed to work as expected for that version. So bugs or features, all of those things work. Assuming your external APIs are well-versioned and you have long-term support setup for them. On the other hand, it means that a user doesn't have the latest version and they're going to need to download an entirely new build and be notified when that new version even exists. Electron contains embedded module support for leveraging the squirrel automatic updates. With a little implementation, it allows your app to get notifications from a release server, download them in the background and then run the application from new files at start. To do this, here's a little course on it. Using the auto update module, you can connect to a release server on startup and check for updates. This requires a third-party server running on your own domain. But as long as it supports the squirrel framework standard, your setup is pretty straightforward. At the time of writing, the top two projects for this are Nuts and Electron Release Server. And there's some of the great features they include. With release server managing and getting update files from your correctly configured Electron app, all that remains is to implement autoupdater.check for updates and autoupdater.quit and install. Check the Electron API demo application for a complete autoupdater implementation to model your own Electron app. It is very, very cool. Next up, security and sandboxes. As a desktop application developer, you must both ensure that your code is safe and that external applications can't simply take advantage of your app, either outside or from within. To allow JavaScript within V8 to access window DOM data, node APIs, and OS interaction APIs, the protective sandbox that surrounds each renderer when acting as a web browser has been disabled. This is what makes powerful applications in Electron possible, but it opens the door to attacks. If you directly load external resources into these environments, imagine a chat application that doesn't properly scrub JavaScript tags and allows for arbitrary code execution. A successful cross-site scripting attack like this could trivially take over a user's host machine and cause untold damage. It is, it's dangerous. Thanks to some great work by the community though, as of version 1.1.1, you have some great tools to your disposal for dealing with external content. Node integration for entire windows and web view tags can be completely disabled so that you can have a safe place to display external content if you need to. Windows without node integration now cannot use web view tags because they are capable of running node code. And with node integration disabled, limited sandboxing is actually re-enabled for that. What's generally recommended, of course, is that if you need to display user content, always ensure it's being cross-site scripting sanitized before writing it to the DOM. The same, of course, always applies to content being entered into your app, passed through the API or otherwise. The rules don't change much for Electron when it comes to little Bobby Tables putting his name in the system. Always sanitize your data inputs. OXKCD, you slay me. As with many other applications, always be aware of user input getting into other users of your own servers. Always sanitize user data on input and output to prevent SQL injection or XSS. Prevent file bombs by having sane limits and restrictions on file types by MIME type. If at all possible, only ever load local HTML and JS and CSS resources in your Electron app directly. Restricting external interaction to scope limited APIs. And if you need to display externally hosted content, limit direct interaction and always disable node integration. Finally, if you want to know when problems happen on your apps or out in the wild, you're gonna want them to call home and say what happened. Electron comes with a built-in crash reporter module seen in here in the base minimum example code needed to initiate it. It makes a post to the server, given your submit URL with the full crash report and system information. It uses Google's breakpad format so you'll need a server like Mozilla's Sakura or Electron, or the Electron project supported mini breakpad server to send reports to. So, in conclusion, I've not actually talked about everything to do with Electron or it's competitors or a bunch of other stuff. But if someone handed you everything you needed to know, where would the fun be in learning and exploring on your own? I think some of the most important things you can take away from this session are that Electron is an incredibly active and constantly evolving project and it's still somewhat new. Chromium has been around the block, but new web technologies, build systems, and commercial use cases ensure it's constantly on the move. Electron is not always the right solution for an app. Of course, neither is Drupal sometimes. Do the research and experiment a bit and see if it's right for you. And when in doubt, just give it a try. The barrier for entry is incredibly small to get started and there's a ton of great tools in the community has made for making the rest of the work really a lot easier. Electron is incredibly powerful and has been used to ship thousands of awesome projects to users around the world. Though it's still young, it's got the chops for making real apps for users today. Thank you. And now, and now it's time, we're ready for questions from the audience. If you got something? Yeah. So in my use case, I've got a POS to be built with the need possibly for offline caching and handling. Obviously in that case, we'll be doing credit card transactions but cash transactions and the like. Is Electron a good fit for that? It could be. How does it handle it? Yeah, if you have an API that you're accessing, well, okay, so for credit card transactions you definitely do need to be connected but for cash transactions, you could probably buffer those somewhere, hold on to them as, you could probably even write them as files and then pull them back in. Just in case you've lost power or something like that, you don't want to just store those in memory. That might be bad. So you just hold on to them until you get service again. There's a couple modules out there. I'm not sure the name right now but there are some that you can get and they actually manage this for you so that you don't lose any of your data. Another great thing about Electron is that you have full access to its standardized web database and web storage so you can actually store data directly in it and it will manage writing that to files and ensuring that that stays with it so that when you reopen, I actually use that for configuration storage on both my applications. That's awesome, thank you. Oh, you're welcome. Can you speak about packaging Electron apps on Windows and Mac specifically? You mentioned CI. That's usually Linux but Mac and Windows, how do you do this? There are actually, is it back? Okay, that's good. There are actually CI systems that will allow you to boot up a Windows server or even a Mac server to be able to build natively on those systems. Yeah, can you name some? Like cloud providers, cloud CI systems? I know, yeah, CircleCI is pretty good. Does Windows and Mac? I think they have Mac and Windows and I believe that, what's the one with the mustache? Isn't that one? I've forgotten. It's the one that GitHub usually suggests. There's a number of them out there. I think a few quick Google searches. Travis, what's that? Travis with the mustache. It might have been Travis. I'm not sure actually. Yeah, Travis does Mac only. Windows is really. Mac only, they don't have Windows? Yeah, Windows is really hard to find so I'm really surprised. There are a few. The neat thing about Windows is that it's a little bit less picky for building. I know that I've done Windows builds on Linux before but there are certain parts that you need wine running in the background so that it can go and run a couple native Windows applications but the fact is that there is some things for that. I have not found very good support for writing DMGs on Linux. Yeah, that can be kind of tricky. Thank you. Are you welcome? Hey, thanks for the talk. Of course. My question is really kind of about packaging also as well across the different host OSes so I know in your talk you mentioned a little bit about how one of the closed buttons actually there was some conditional code that of course on a Mac it probably wouldn't actually close the application whereas Windows it probably would. So does the Electron app kind of like the APIs handle a lot of that functionality so it just takes lack for example, notifications would I be doing some kind of conditional code there just to kind of handle the different operating systems or does that do a lot of the heavy lifting with it with the core? Incredibly simple to check the operating system just like you do in Node you can say process.system and it'll tell you whether it's Darwin or whether it's Linux or whether it's Windows and you can simply put it the actual amount of code for that is tiny, it's very, very small and you can simply say if this is a Mac don't close everything, don't kill the process otherwise just exit out of everything. Gotcha so really it's kind of like fringe cases that you're really going to be doing conditional code? Yeah and there really are very few of them I've had to write very a couple in the applications and the applications are really pretty big there's a few more surrounding menus as the menu structure is something that it does fully support I didn't really talk a lot about it but you can set up different menus for different operating systems and have those be there. Another thing I didn't talk about is translations which you need to ensure that are part of that but actually RoboPaint has full translations for all of those using I18N, oh that's not what you asked I'm sorry, anyway, yeah. Well thank you, appreciate it. You're welcome. For something like your Pancake Maker how do you call the Pancake Maker from your Electron app? Are you posting like interfaces or? So the RoboPaint the first application has a direct connection with the robot we actually use a project called Node Serial Port which has a compiled aspect for it that actually has a low level controller to go talk to the serial port because it's different on both operating systems. For Pancake Painter it turns out that they wanted something a little simpler for home users so we just write the files directly so we create the gcode files that it needs and then people put those on SD cards so there is actually no direct connection but the RoboPaint does have that. All right, thanks, you're welcome. If I have a offline or a website that's capable of being pulled up offline and I wanna package that up into an electron application but I'd like to use an alternative backing store how would I do that in a way that doesn't add too many lines that is shared with the web client that's completely useless? You should be able to run most of the code. It kind of depends. I mean, there's a lot of ways to store data. Depends on exactly what you've got. Yeah, what, you got an idea? SQLite, which is... Right, not necessarily which backing store, any DB, like which backing store I use but rather alternating what I use so if I'm using local storage on the web but for my electron application I wanna use an actual file to store it, such as SQLite, how would you suggest switching that within the electron application without too much shared code basically? There is a possibility that you could run something locally that mirrors the exact same API that it uses to be able to go and do those communications. I'm not totally sure but you might have to write something custom for that. There might be something that exists. It is a fairly specific thing but I mean, yeah, there might be something that exists out there for it. Electron lets you do almost anything. All right, thanks. Sure. James, do you need any more water? I'm thinking about it. Okay, just let me know. Thinking about it. Thank you, Randy. Thank you, Randy. Another question that one of my coworkers actually asked was what version of Node.js is shipped with Electron? And the answer to that one is actually whatever version is about a month behind. If you check the release notes for Electron when you go in, you can see they actually pin it to a version of Node.js and a version of Chromium. I'll let you do pretty much anything with it. If that's all the questions, then thank you, everybody. Woo-hoo! Here it is for Contribution Sprints. What'd you think? Two minutes early. You like it, guys? My pie. That was awesome. And the timing was good, too. Is the water wheel example online? Is it open source to one? The to-do app. Is it all open source? No, the to-do app. Oh, the to-do app. The React to Do app is the Electron version is not, but believe it or not, the only changes I needed to make were the ones I showed on screen. Okay, thanks. Oh, yeah, I can totally release it. Yeah. Thank you. You're welcome. It was funny because I was following Reddit and just like how savage these people were just cracking the hell out of their subscription that they had for all their code. And then they changed it, and then they did it again like three days later, they were able to crack it, but that was the first time I ever installed one, and I was like, oh, this is convenient as hell, because I'm not gonna make it just like that otherwise. Thank you. Appreciate it. Vector, like, a more generic.