 Cool. All right. I did finish architecture and urban design, but clearly left, so whatever. Hi. Whatever. We've already gone through who I am. Hello. So we're happy to be here. I did work for the city of Boston, and I did live here, and I do really love Boston. All right. So the longer... Is this... I don't know if I'm talking... Oh, that's better. So the longer version... Wow, these are totally stretched out on here, but that's fine, probably. The longer version of my talk title... I felt really bad about this talk title. I was like, what a bold statement. I feel so bad. It's Nativeize is the new normalize. Win websites become desktop apps with electrons. So that's the caveat. Because really what you're trying to do is make an app that's made up of websites feel native and not feel like a website. And before I dive into that, I will... I'm glad that I saw the hands about who knew about electron. I have really no idea. I was like, everyone's going to know about electron. This is old news. But I think this will be helpful to give a little background. So electron, this is the blurb, the once in its blurb about electron. It is a library for creating desktop apps with web technology. And we can break it down a little bit more, and that it's a library for creating desktop apps for Windows, Mac, and Linux with web technology, JavaScript, HTML, and CSS. It's totally open source. It was created by GitHub. It's what GitHub's editor, Adam, is built on. It was originally built for Adam and open sourced along with Adam. And now is its own project with its own team and really growing community around it. And so it's maintained by a small team at GitHub. And then a lot of contributors. There are a lot of individuals contributing to Electron Core. And then there are a lot of companies who are now building their apps on Electron that are pushing a lot of changes upstream. So what is going on on the inside of Electron to make it be able to do what it's doing is combining these three elements. And so what I want to make clear is Electron is not a web view. It's not just a rapper, a native rapper around a web view. It's actually a way to fully make a native app that's really integrated with the desktop. And it does this by combining Chromium for drawing web pages, node for accessing file systems and networks, and then Electron has its own set of native APIs for doing operating system functions for three different operating systems. So the Chromium part. Electron is using the Chromium, which is the open source version of Chrome. It's using just the part of that that knows how to draw a web page to paint elements, turn HTML into the visual things that you see. So when you're working with Electron, you get the complete DOM as you would expect, and then you get everything that ships in the latest Chrome, which, well, right now Electron is on 53, but it's soon to be on 54. Usually when a stable Chrome releases, it's about a week before Electron updates to that Chrome. And then you get all of node. And so this is the really like magic sweet part, that node is available everywhere in Electron, even in your HTML. So when you're writing a script tag in your HTML, you just write node. There's no flag. There's no setting or anything. You just write node as you would write client-side JavaScript. And so it's cool. You can access the operating system. You can access the file system and then immediately update the DOM. And then there's the native APIs. So Electron makes available a lot of different APIs for doing all the different things you could imagine that you would want to do to integrate your app to the operating system. So for instance, a dialogue like an open file dialogue. There's one API for that. Electron does the work of figuring out if the user is running your app on Mac or if they're running it on Linux. You just have to use the one API. So in whole, Electron is a lot like making a website, but only having to care about one browser, the latest browser, and getting to use node and operating system features. So Electron apps are made up of HTML, CSS, and JS files. And there's a lot of overlap for designing for Electron and designing for the web. This is the Electron API demo app. It's not as stretched out. But this is an Electron app demoing the Electron API. It's something our team made. It's open source. It's in the Mac app store because Electron apps can be in the Mac app store. You can also download it, but it's a great way to get a sense of like what are these native things that you can do with Electron. And also explore the source code for this app itself because it's a nice example of a really basic Electron app. So you might already be using some Electron apps. If you use Adam, you're using an Electron app. If you use Slack, it's an Electron app. Visual Studio Code, which is Microsoft's code editor, is an Electron app. Brave, which is a browser built on Electron, which is built on Chrome. And Pix8, which is a prototyping tool. These are just a few. We have on the Electron website, which is open source, we have a page for anyone who wants to add their Electron app to that page. They just make a pull request and they add their app. There's something like 200 apps on that page now. But, alright, so, reminding back to the whole point of this talk is how do we design for this new environment where we're creating an app with websites, but we want it to not feel like a website at all. And this is something that I feel like a lot of teams are figuring out piece by piece on their own. Normally I give talks about a lot of the JavaScript side of building Electron apps. And there's a lot less out there about actually all these gotchas for what you need to do to remove the webbiness from your Electron app. And so that's what this talk is going to be about, removing the webbiness. Oh, yeah. Because even though you don't have to support multiple browsers anymore and that feels huge, you have to support multiple systems. And so there's also gotchas around that. Alright, so the first broad category of things that I'll talk about are design things. The first, nativize your CSS. Nativizing is doing these things in CSS that you would never do to a website. Or, I don't know, maybe you would, I don't know your style, but you don't want your app to feel like a website. So no selecting, no dragging, no gloves. If you think about it, when you're using a desktop app, you can't select the text. You can't drag your button off the screen in your desktop app. And buttons don't get the glove cursor. They don't get the pointer. They have the normal triangle pointer. And so straight off the bat, you have to do these weird things like turn off selection. Also, no dragging images. You can't do that in the desktop world. Then, unless you need these things. So in the Electron API demos app, we have a link here that goes to an external, it actually opens a link in a browser. And so we wanted that to have, we wanted to differentiate it, and so it has the pointer. But then this button doesn't. The button has the default cursor. And then we have code samples, and we want you to be able to copy and paste them. So they actually need to be selectable, whereas the rest of the text isn't selectable. So we have an is selectable class, and then we make all of the code selectable, and then links are pointers. Another thing that is a nice snippet is to target all of your external links, because your app will have a lot of internal links probably, but in Electron, if it has an HTTP or HTTPS, it's probably an external link, and so you can nicely target those and think about accessibility and how you differentiate your links that are opening in another application, another window. Also, no rubber banding. So if you think about when you're in a website in Chrome and you try to push it down, you get that bounce at the top. That's the telltale sign. This is a website and not a desktop app, so you've got to take it out. If you do need a scroll bar, you can create a container div, but in general, to stop the whole page from rubber banding at the top, this is another snippet of nativeizing. All right. So after you've done your basic nativeizing, I'm feeling really bad saying that word now, you start to think about your app's actual UI. So Electron provides you APIs for opening dialogs, using the native notifications and things like that, but your actual app's UI, that's totally up to you. So you can emulate operating systems or follow your heart and create a whole new UI. And the first thing your users are going to see is the window of your app when it launches, and that's when you can start making decisions about how your app looks and feels. So you'll see I have four windows over here. The first one is the default one where you get the Chrome at the top with the traffic bar lights. That's default, but you can choose to totally remove that and set the frame to false and have a frameless window. On Mac, you have a couple more options for the title bar style. You can do title bar hidden and hidden inset, and the only difference is the traffic lights are positioned in a slightly different way. But that gives you the ability to kind of push your app full bleed, but not have to implement the traffic lights yourself. So you make the decision when you define your browser window to set the frame to false before it shows. And you can do things like also make it transparent, so you can set transparent to true for your window, and then if you set the HTML and body to a transparent value, then you get a transparent window, which could be nice depending on what your app does. But there are some major caveats to using a frameless window. They look really nice, but you have to roll your own toolbar UI. It's not hard, you know, onclickwindow.close, but you are making your own traffic lights. You need to create a draggable region where your frameless windows aren't draggable. And then any title bar text that you make needs to be non-selectable, because you don't want people who are trying to drag your app to then be selecting the title bar. And then you need to make sure that you don't have click events trying to happen in areas that aren't draggable. So just note. But it's totally possible and people do it. I've got a link down here to a longer page about how to set up a frameless window and catch all of these things. This is an example. The API Demos app uses the frame. It gets the title and the traffic lights. Slack. This is Slack using the hidden inset and pushing all of their UI to the top, but keeping the traffic lights. A couple more examples. Hyperterm is an electron-based terminal app. And you can see here they've got... Both of these apps are using hidden inset and you've got the bash title there. And that's the type of thing that you would want to make sure people cannot select when they're actually trying to just move your app around the screen. And then WebTorrent is creating... it kept the native traffic lights, but then implemented its own toolbar UI. So once you go beyond the frame, then you have the actual UI itself. This is Vector, which is an electron app that is creating a totally custom UI. They even have custom traffic lights and all of the buttons obviously aren't specific to any operating system. Another one, this is SimpleNote, which is by automatic, and it's a really minimal UI. But then you can emulate the operating system UI. So this is Nylas's N1, which is a mail app, which is with their toolbar, they're emulating the native toolbars, the native Mac styles with their buttons. And then they do the same thing on Windows. You can see like the icon, this new mail icon changes and the icons look different. It's flat and it's white. And you can actually just swap this out with classes, and that's what they do. Because you have Node there, you can just check what platform the user is using and then add a class to the body and then toggle between Mac and Windows UIs. You can even go further if you want. There are APIs in Electron to let you know if the user is using dark mode on Mac or what the accent color they're using on Windows is. This is an app called Timestamp that is doing that. It runs in the menu bar, but it checks to see if the user is in dark mode and if they are, it updates the UI to match that. There are some toolkits if you do want to do the native UI route. There's one called Photon. If you want to contribute to Photon, that would be great, because right now it's only Mac. There's another thing called React Desktop. So if you use React, it is native UI components for Mac OS Sierra and Windows 10. All right. Another one, single page apps. I'm using one of my apps as a what not to do example. This is a website I turned into an Electron app and you can see the flashing, because again, this is a Chrome window, so whenever you switch pages, it takes that second to load the new page in and so doing a single page app will save you from all of these weird flashes here. And you can pick your favorite flavor of front-end framework or not, you can use HTML imports. That's what we used in the API demos app and it worked really nicely. And Electron has DevTools extension support for Ember, React, Backbone, JQuery, Angular, all of these things. And so if you have a framework you already know and love and want to use it, it works with Electron. Icons. All right. These are the ones where it's the gotcha for you only have one browser but you have to support multiple operating systems and icons are different on every operating system. So Mac and Windows and Linux all have these different file types but the pro tip is to start with a high res PNG and then you can generate the ones for Mac and Windows from that and I have some links on here that are online tools that will generate the right operating system for you because you don't want to ship your app and then have the icons look all weird. Another one is that Linux icons are actually set when you're defining your window. Mac and Windows operating systems, their icons are set when you're packaging the app but if you don't do this here your Linux app is just going to be a gray square with a question mark and very sad. Windows will actually also use this icon to put it in the top left corner of a window so it's a useful thing that sometimes it takes a lot of pain to realize that you need to do. And then again you're only designing for one browser so whatever works in Chrome will work in your app on all three platforms. CSS variables, constraints, the shadow DOM, custom elements, version one is going to be in Chrome 54 which will be in Electron soon and over 90% of ES6 works in Chrome so there's a lot of stuff you can just do in Electron out of the box without needing any other libraries for or compiling for. Next is interactions. This is more about using Electron APIs to make your app integrated better into the operating system. The first thing to think about is the startup how users see your app as soon as it loads you can change the background color of the window to actually match your app because by default it's going to start up white and if your app is bright blue there's going to be a flash of white before your page loads especially if your page has a lot of resources and takes a long time to load so one thing you can do is change the background color before it loads anything and you can also think about how to use CSS animations and transitions to gracefully bring all of your app's components onto the screen. Another one is just don't show your screen at all or don't show your window at all until everything is loaded and ready to show so you can initially set your window to be false and then once everything is loaded then show the window but if you're making a menu bar app and you think about how menu bar apps work so the ones that are just in the top title bar those don't have a dock icon and they're also, you don't want a window to open when the user launches your app you only want it to happen when they're clicking the app and so these are things that aren't default in Electron so if you're doing a menu bar app you do want to set showing it to false initially and then only show it when they click on that tray icon menus, menus I feel like can be so often neglected but it's a way that your users are really going to be able to tell if you've put thought into making this feel like a Windows app or a Mac app so things like preferences dot dot dot is how it's written on Mac but it's called settings on Windows and so it's really, it's nice if you take the time to actually set your menus for each of the operating systems to what users would be accustomed to seeing this is an example from Adam for Adam on Windows and Adam on Mac what the menus look like another thing that doesn't cost a lot but adds a lot of niceties to your app is like if there are major parts of your app's UI you should add them to the menu because then you get an easy way to create a shortcut, keyboard shortcut for them and then they're like accessible and the help like this protocol is one that I think is really nice like if you are creating an app to view images or open PDFs you can set it as the default for that kind of file or you can create its own protocol so for instance in the API Demos app we have a demo of doing this where we create an API Demos protocol so you can actually have this link on a website and have it open your app on the user system and there's some other nice things like saving the screen size and state because you've got node it's really easy to save an object to the file system write a little JSON file and have that file read every time your app starts so that you can start the app in the last position and state that the user used it in you can use desktop notifications they work on all three platforms drag and drop on app icons and launching the app on startup and then so many more things I said when Electron first came out a lot of its API was tailored towards Atom whatever Atom needed to do that's what we built into Electron but now teams from all over who are building all kinds of apps on Electron are contributing APIs and so there's so much that you can do to integrate your app into the desktop with Electron and finally some nice things to do while you're designing and building your Electron app use the dev tools because this is Chrome, dev tools are there and you'll probably find yourself opening them manually each time but you can set them to just open by default which is much nicer and there is a library I've linked to here called Electron is Dev which is a nice way to tell if someone's running your app locally and then you can just set the dev tools to open every time on startup every time someone's running your app locally accessibility a lot of because it's still the web a lot of accessibility issues from the web are shared on Electron and Electron has a dev tools extension called Devtron that's using Google's accessibility auditing library and so when you use Devtron then you can get this accessibility audit so that you can make your Electron apps accessible too please also Khan Academy's Toht Ali if that's the way you say it I hope pairs really well with Electron apps because the thing is with Electron apps you don't have a URL to the view of your app you can't use some of the online tools and things like that so please make use of these and following the test the test talk there is a library called Spectron that we have for Electron oh gosh that is a Selenium and WebDriverIO library that knows about the Electron API that you can use to test your apps so this is running it on the demos app and so it's not doing it's not taking images and comparing images and it's really up to you how detailed these tests will be but for instance like this test makes it's opening the app it's clicking buttons and asserting that a certain page is visible that there are certain amount of elements on that page that the elements have these names but you could really specific to make sure the colors were right or the position was right of these elements and so Spectron is really nice and then you can run it on all the platforms and finally the menu bar apps I think are such a great gateway into Electron because they're super small and focused like this is a web page that's this big and so you can kind of just have an idea execute it you get the satisfaction of having made this thing and it's working and they're fun and then you can just fill up your menu bar with things this one being shown here is called moji bar which lets you find the right emoji based on your emotion and then there is a library called menu bar by max Ogden that basically does all those things default for you that I mentioned like with the menu bar app you don't want a dock icon and you don't want it to launch when people click your app this menu bar library sets all of those defaults in Electron for you so it makes it even easier to get started and then lastly I'll put these slides up online and I just have links here for resources for getting started there's some so this Electron quick start is a good one it is a bare bones Electron app that you NPM install NPM start and you have a blank Electron app to get started with it's a really good one really for just starting any Electron app awesome Electron has this really long list of every single tool and talk and book about Electron the API demos app and then repos using Electron is a new one it will give you the top 100 libraries that Electron apps are using so you can kind of see spoiler it's react but you can see the other 99 libraries that people are using in open source in open source Electron apps on Github so thank you that was great my gosh your talk was full of just like so many tips and tricks and gotchas and everything you need to make a good Electron app so before you started at Github were you working with Electron or did you know anything about it oh no not at all I mean Electron is itself only a few years old so Adam had started when I started at Github because I worked on different front end things at Github for like a year and a half before I switched over to the Adam team and then to the Electron team so no I had no idea really and it just wasn't a thing that Github was giving attention to either like because Adam was the focus right so there was one person maintaining Electron and everybody else was working on Adam and once I joined the Adam team and I learned more about like the library actually powering Adam I kept being the annoying person pushing to work on Electron so then I was the first other person to work on Electron and then I did that for a while and then in the beginning of this year we actually became a real team with our own repos and our own Slack and yeah so we have your pushing to thanks for Electron getting out there that's incredible so we have a couple questions one of them was are service workers available in Electron yes it's everything that's the only thing that's not available from Chrome and Electron are really Chrome specific things like trying to create now I don't know what it's called but the place you type your URL into you know like things that are very specific to Chrome are not in Electron but everything that is specific to rendering a web page in the DOM is available pretty neat and then the other one was how do you fork for the different operating systems are like how do you how do you work for the different oh so you only have one code base which is also a great perk of Electron so instead of having a different code base for every operating system you have one code base and the way that you you only need to differentiate for operating systems in certain ways like with the CSS like detecting the platform and changing any CSS if that's something you want to do but all of the Electron APIs there's just one of them and Electron figures out which operating system the user is on so you don't have to have you don't have to worry about you don't have to worry about what the user is using so much you actually don't have to worry at all if you don't want honestly you can make an app that just works well on Mac and you can not care Windows gets the Mac the Mac world yeah so I mean it's up to you how careful you want to be about using the right terminology in the Mac in the Windows version and things like that so you actually don't have to but if you want to make it a nice experience on multiple platforms you take these extra steps but it's still just one app so it's one code base is it like it controls and if statements for like if it's Windows do this if it's Mac yes but only in a few spots so only right like only if you're changing the CSS the menus are something where you would check the platform to change the menu labels but like you wouldn't for a dialogue box and you wouldn't for like 85 if not more percent of what you're doing you're just doing once there are only a few instances where you do where you might want to check the platform and then make an adjustment yeah I'm just like so blown away that HTML CSS and JS now guesses to the point of writing desktop apps which is like who would have thought you're like oh my gosh I gotta learn this native language Mac or Windows native language and now it's all in our hands it is super fun I do like I feel you know weary of like saying anything is easy and fun like when the read me is like using this is easy but but there is honestly like this magical fun feeling when you're using Electron when you're able to just write in your HTML and and you're not how you can write ES6 and you can use CSS variables just everything out of the box there is actual fun feeling of writing and electronic great and how big is your team now is it's still just four yeah four four we get a lot of support from the community yeah people working on it that the best thing about open source and now that it's more and more people are using it I'm sure that has propelled yeah definitely like slack and Microsoft and brave have teams that are working on Electron core a lot and so it's awesome how does github feel about Electron now I think they're pumped about it yeah it's a really unique project for github to have also because it's one of github's biggest open source projects now and in some ways has eclipsed Adam but and it different it's from Adam and that Adam is still very driven internally by github right like the Adam team and github are deciding what features go into it I mean of course there's bug fixing and things like that but the roadmap is really set by github itself whereas Adam is not even using Electron 1.0 Electron went 1.0 or maybe it's almost there checked but I mean Electron went 1.0 in May of this year and Adam at least as of like a month ago wasn't on 1.0 so a lot of what's driving Electron development is the community and not internal at github and so it's a very you can see the power of that community drive it's a cool open source project to be on where and I mean github is fine with that so yeah like the community is really driving the development of Electron that's great alright thank you so much Jessica