GitHub&#39;s Electron

Alright, we’re back. We’ve got Zeke Sikelianos on the show today. Jerod, this is a big show for us, because we’ve talked about Electron several times on the podcast, and this has been a 1.0 in the making, basically… So what’s up with this show?

Yeah, we’re always happy to have people from the GitHub on the show, especially since so much of our open source is hosted there and they do so many cool open source projects themselves, not the least of which - maybe the most of which at this point, since everybody’s building cool stuff on top of it - is this Electron thing.

This Electron thing, for sure… So Zeke, you’re on the Electron team - what part do you play there? And welcome to the show, by the way.

Thank you, it’s good to be here. I joined the team in March, I’m the newest member of the team. We are four people officially, and lately my role has just been around smoothing out the documentation and in general making it easier for new users to get up to speed with Electron and get their apps built.

Well, to start off the show, Zeke - and I can only imagine what your story is, because you’ve got a pretty diverse background as per your website: graphic designer, open source hacker, aspiring home builder - I’m not sure where that last part comes in, but we’d like to learn a bit about the guests that come on this show, to figure out, hey, you’re on the Electron team now, you work at GitHub, you do what you do now, but what got you there? What inspired you to become a software developer, become a designer, or even become a homebuilder? What’s your story? How far do we have to go back to get there?

Well, I guess we could go back to my childhood. My father’s side of the family is a bunch of artisans and artists and poets and builders and things like that, so I come from a very creative family. As a youth I was really interested in art and design. I think I actually got my start doing graphic design and learning Adobe Flash - actually it was Macromedia Flash at the time. I just wanted to create interesting things on my computer, and I eventually came to realize that writing computer programs was a really powerful way to do that, because you could make minute changes to code that would have some really interesting visual change.

[04:14] I started as a Flash developer back in ’99, 2000, and was going to college but was really more interested in doing web development than my studies, so eventually I dropped out of college, got a job at a graphic design firm and became the sort of resident web person there. For a number of years I was just working for a branding agency, doing lots of design work but also starting to learn more about how to build web applications.

The ActionScript thing only got me so far, and eventually I needed to learn a server-side web language to start making interesting web pages that people could interact with, that could save information. So I learned PHP and did that for a number of years, and I eventually wanted to learn something better, something more powerful or a little bit more of a humane programming language. I ended up getting into Python and eventually Ruby.

My interest in programming just continued to grow, despite the fact that initially it was just a means to an end. It was something that I was learning so that I could make more interesting visualizations or facilitate new ways of doing graphic design. I eventually moved out to California in 2007, and started doing Ruby on Rails development full-time. I moved to Silicon Valley eventually and started working for Heroku. That was really when my career started to become really programmer-focused, working primarily on developer experience stuff.

It was strange that I ended up at Heroku because the reason Heroku appealed to me in the first place was that they provided a way for me to deploy web applications without having to know really anything about how servers work or how to manage, load, or how to configure a database, or all those kinds of things that you have to know, all that ops sort of stuff. I really was kind of the ideal customer for Heroku, and somehow ended up being so fascinated with the product that I ended up working there as an engineer.

I kind of got involved in something that I swore to never have interest in, and it sort of continued to happen from there.

At Heroku I first worked on the add-ons product, which is basically an app store for developers. It’s a place to buy software as a service or platform as a service type things. If you’re building an application and you wanna provision a database for it, you go to the add-on side or use the command line interface to effectively purchase a database in the cloud. My job there was to kind of design and build out this app store.

From there, I eventually… I was getting more and more interested in Node, having had a background in ActionScript, which was effectively a much more advanced version of JavaScript from the late ’90s. I really got interested in Node and saw that it was giving life to JavaScript outside of the browser. Heroku had a product for deploying Node apps, but it was not maintained and it was not an official product, and there was no real team around it.

[08:00] People were starting to think of Heroku as not the place where you would want to host a Node app, even though we were technically capable of doing it. So I devoted myself to revamping the build process for Node apps on Heroku, so when you Git push Heroku master with your Node app, there is basically a set of Bash scripts that run that prepare your app to run on the platform. It’s things like figuring out which version of Node to install, running npm install, cleaning up the app and putting it on the shelf, effectively on S3, until the routing layer is ready to pull it off the shelf and serve traffic with it.

This was kind of the beginning of the end for me in terms of my design career. It was really intriguing to me and really fun, but it was also just a purely developer-oriented project. There was literally no aesthetic element to it, just really trying to improve developer productivity. It’s kind of been an identity crisis for me, but I’ve embraced it. It was really rewarding to work on this thing at Heroku and see that I could make a small change to a product that was being used by thousands of developers every hour, and just knowing that if I made the build process a minute faster on average, that was saving five thousand developer minutes per hour, and just thinking about all the people who were having improved development workflow because of this work. Working on something with that kind of reach is addictive.

From there, npm was forming as a company. Isaac Schlueter, who created the npm project, had just left Joyent to found npm. I got in touch with him and ended up leaving my very comfortable position at Heroku to help start npm.

What was your role at npm? Since your designer heart was a little crushed, did you get to piggyback up a little bit, or did you stay on the developer side?

Yeah, I got a little bit of it back. My job was to work on the website. The website that you see now at npmjs.org or npmjs.com, most of that is my design work. We did work with an outside consultancy for some of the design, but primarily the package page was my main focus.

My goal there was to try to make the npm package page as useful or more useful than a GitHub repository page.

As a developer, when you’re trying to find a dependency that you need to use in your project, there are a number of indicators that you look for, like “Is this project maintained? Does it have tests? Is it well-written? Does it have a bunch of issues? Has it been abandoned?”, things like that. My goal was to collect as much meaningful metadata about a package to display on the npm website as possible, so people could just go, get a quick gut check, “Does this thing look legitimate?” and if so, install it.

So I got part of the way there; I don’t think it necessarily quite rivals GitHub’s readme pages yet, but incremental progress…

Yeah. So just to be clear, you’re talking about npmjs.com/package/blah, whatever that blah is, like /async, /npm, whatever the package is; when you hit that package page you can see if it’s public, you can star it, learn more about it… This is the page you’re talking about, right?

[12:00] Yeah, absolutely. Some of the most meaningful pieces of metadata there are - it’s mostly in the sidebar - how recently was the package published, how many releases have there been, how many maintainers are there… And then we realized that a lot of the really interesting data was actually coming from GitHub, so we wired up something to collect issue counts and pull request counts and display those in the sidebar as well. Also, downloads are somewhat useful in helping to decide whether a package is legitimate.

Unfortunately, with downloads there’s so many mirrors of the npm registry that even if your package is not being used by any humans at all, just the mere act of publishing it will cause something like 50 downloads in the last week to be displayed, just because all of the mirrors are catching up and downloading the package. It can be a little bit misleading, but it can still be kind of a gauge.

I don’t know if you guys have seen it, but just recently, Adam, we were pinged about a new project called npms.io, an npm search. We’ll have it Changelog Weekly either this week or next week, depending on when this show goes out. I think you’ll like it, Zeke, because it’s trying to do to the free npm search what you’re kind of doing for the first party package pages, which is to organize the search around quality, maintainability and a few other metrics. He actually scores each package - I’m not sure how the algorithm works, but he scores them on a 1 to 10 on those three different metrics, and then he integrates that into the search. It seems like a proof of concept. I think he probably eventually wants npm to adopt it as the way they do their search, but it’s interesting because he’s trying to pull in a lot of that extra “How do I decide the quality of this project?”, similar to the kind of stuff that you were trying to expose when you were working on the package pages.

Yeah, actually when I was at npm we talked about that a lot, and I think one of the conclusions that we came to was that you can’t really assign a numeric score to a package because there are so many factors that can be affecting your judgment.

There’s a very prolific module author named Substack, who was one of the early members of the Node community, and he wrote some really fundamental packages and a lot of them haven’t been touched in three or four years, but they do exactly what they need to do, and they’re done. You may see a package and think, “Oh, this hasn’t been touched in four years, it’s probably not safe”, but in many cases those packages are actually stable.

I personally think that the best way to help people make decisions about which packages to use is just to display as much information as possible, rather than trying to quantify it all in a single score. But yeah, the npms website is cool, I really like what they’re doing there, and from experience I know that the npm team - at least when I was working there, had no spare cycles to work on the elastic search appliance that they currently have. It was kind of like the thing that nobody wanted to touch, so… [laughter] It would be surprising to me if they put any real effort into search, so I would continue to expect those kinds of developments to come out of userland, so npms is definitely a good thing to keep your eyes on.

Yeah.

[15:56] Well, about this kind of thing too is that most often in open source - and this is what I love about open source - is that these two could very likely be offered positions potentially at npm. Like, “Hey, you built this awesome thing, you’ve got some good thoughts around it, or at least some motivation… We need help, come join the team.” Maybe it’s contract, maybe it’s long-term, who knows, but there’s been several jobs… Thomas Watson, I’ve talked to him, from the npm community as well - he works at Opbeat now because of his influences and because of his work on Opbeat in the open source area. They were like, “Hey, you’re really passionate about NodeJS on Opbeat. Come work for us.” He now leads that part of the project for them, and I think that’s the beauty of open source. You can tap into something and strike a chord and then be offered a job.

Yeah, as far as finding ways to integrate third-party features into the npm website, there have been a few of those that have happened. If you look on the sidebar on any package page, you’ll notice there’s a little link that says “Try this out in your browser.” That’s actually a third party set called TonicDev that has a little sort of online [unintelligible 00:17:09.05] kind of console thing where you can actually play with a module live. Obviously, it only works for browsers or packages that are browserify-friendly, but there are many of those.

Then also I think npm’s search tool has an autocomplete feature that is also powered by some third-party service, it’s called Constructor.io. Those came to exist just because there were people in the user space who were really interested in getting these integrations on the npm website, just because obviously their visibility in the community is gonna go way up.

Unfortunately though, just last week or two weeks ago npm closed the source on their website…

I saw your tweet, you seemed bummed about it.

Yeah, it’s really a disappointment to me because the main thing that I was working on at npm was modularizing the website into some different npm packages with separate responsibilities, the end goal being that it could solicit a lot more feedback and contribution from the community. Unfortunately what happened is that npm had to make some internal revisions to the registry. In a nutshell, the way the npm registry works now internally with private and scoped packages is that there’s a Postgres database that they run that’s not public, that is a follower of the Couch database. It does a bunch of work to clean up the data in the CouchDB and then also to add supplementary metadata about scoped packages. Scoped packages are like AppUsername/PackageName. This is a new way for paid users of npm to - actually I think free users of npm, too - to have their own names for packages. But for technical reasons, the registry is effectively closed source now. When that happened, the npm website was no longer able to be run by anyone who doesn’t work for the company. You could still the website source and npm install, but if you actually wanted to run a development version of the website you couldn’t, because there was no data store to integrate with, or no mock database to use.

This was something that was really important to me, and unfortunately that is not a priority of the company. Understandably, companies have to figure out a way to be profitable, so their focus is really on trying to encourage adoption of their paid plans and their organization product.

[20:17] That makes sense… I mean, everybody has their own motivations. We’ll have to save debating that for a different show, because we can go too deep there. It sounds like your experiences at Heroku, your experiences at npm obviously play into what you’re doing now with GitHub and Electron, and from what I understand you also have had some designer input onto the contributions page, which we use quite a bit, too. As developers, we look at that page quite a bit just to kind of compare and contrast what’s happening in a repository, who’s involved in it and what their contributions are, and obviously representing and clearly defining those people for doing what they do there…

But take us to GitHub. Your designer heart crushed to a degree at Heroku, but you were doing great things… Revived it again at npm, and this story you’ve told us now. So what’s the state of things now for you personally, and then take us to what you’re doing with Electron at GitHub? We’re coming up close on our break, so let’s do a short version of that. We’ll kind of tee this part up and then we’ll go into a break and we’ll come back and go deeper. So help us get to GitHub for you.

Okay, sure. So in the last year and a half or so in my life things have changed quite a bit. I ended up leaving npm, I got married, I conceived our second child with my wife, moved across the country to New Orleans, ended up moving back across the country to Santa Barbara to be closer to family as we have our second baby… So in that process, one, we were moving through all these transitions, I was kind of just freelancing. I ended up working for a startup in the East Bay called Josephine, that is trying to change the market for homecooked food. They’re trying to enable cooks to sell food out of their homes, so I was helping them get their product up to snuff for a while. I kind of had a little bit of downtime there and was really looking for the next place to land where I could really sink my teeth into more Node-related stuff. Of course, GitHub was really appealing to me, and I already knew a few members of the Electron team, having worked with them in various capacities. The npm website’s readme parser is actually powered by a piece of Atom, so I had collaborated with Kevin Sawicki, who is one of the founding members of the Electron team. So I kind of had my foot in the door a little bit there. Electron was just really appealing to me because it’s like being a kid in the candy shop. You get the latest browser and you get Node mixed in, and the combination of those two things is just really, really exciting, especially if you’ve had to deal with the inadequacy of browser development life for the last 15 or 20 years.

Let’s go ahead and pause there and we’ll come back and we’ll dive a little deeper obviously into the Electron team and where it came from. We’ve got tons of stuff to cover in this show, so let’s break now and when we come back we’ll dive deeper with Zeke and Electron. We’ll be right back.

Break

[23:42]

Alright, we’re back with Zeke Sikelianos. Zeke, we love Electron, we love all the cool things that it’s come from. It’s obviously been extracted out of Atom, there’s some history there, but for those who are listening to this show thinking like, “Okay, I’m catching up… What is Electron? How can I use it? Who is it for?”, what do you tell people?

Yeah, so the gist which I’m gonna steal from the homepage is if you can make a website, you can make a desktop app. Electron is really just the open source core of the current web browser, mixed in with the Node.js runtime. What it enables you to do is write desktop applications with HTML, CSS and JavaScript and package them into distributions for Windows, Macintosh and Linux computers.

That’s awesome. That story is not a new story, though. There’s been some others out there in the past, and one question we have here is what makes it different, what makes it better than maybe some predecessors? I won’t name those, but from your perspective, what is it about Electron that just makes it be so wildly adopted? As you’d mentioned the homepage, you’ve got applications like Slack using it, you’ve got Wordpress.com using it, WebTorrent, which we’re gonna cover in a future show, the new latest and greatest HyperTerm, which we covered more recently with Guillermo Rauch… What makes it better, or the better thing, than what has ever come before it? Do you know that?

I would say it probably has mostly to do with timing. Electron, though it seems like a new thing, it’s actually been worked on daily by this guy Cheng who is the creator of it, who’s on our team at GitHub. He worked on Node webkit starting four years ago and eventually having learned from development on Node webkit, some of the things that he got wrong or that he wanted to redo or do differently - he started on Electron.

Electron has been really in development for about four years now, under various names. I think really we’re just at a point now where with Node having come into existence about five years ago and the ecosystem having enough time to flourish and reach a much broader audience in developers, we’re just now at this point where Node is a much more accessible tool, that is a more fundamental part of every web developer’s toolkit. I think it’s just more a matter of timing than being the right product.

You also have a segment here on the homepage that says “The hard parts made easy.” As deep as you can, take us into those things. You’ve got automatic updates, native menus and notifications, you’ve got app crash reporting - these are things that typically if you built a native app on any platform, you’d have to figure these things out on your own pretty much. You’ve got debugging and profiling and then, the super hard one, Windows installer. Help us break down the hard parts made easy, what can you tell us about that?

The way that I interpret that statement is that we have a set of APIs that are abstractions around common elements of operating system. There’s a thing called the tray API, and each operating system has its own notion of what the tray is. On macOS is the thing in the top right that has little icons on it; on Windows, it’s the equivalent thing in the bottom right corner of the taskbar. What Electron does is it gives you one API that is sort of ironed out across all those different operating systems to behave appropriately for each OS. So you’re not necessarily thinking about the idiosyncracies of each operating system, you’re just coming up with a tray interface that can work in all contexts. I think that for me is the biggest thing in terms of making the hard parts easy.

[30:13] I guess another one would be that traditionally if you wanted to become a desktop developer, you sort of have to make a judgment call; you have to decide whether you want to be a mac developer or a Windows developer. If you wanna develop Apple products, you have to learn Objective-C or Swift; you have to sort of buy into the ecosystem of using Xcode and all those things, and there’s a lot to learn there. You’re basically vendor-locking yourself in. What Electron does is it allows you to build those similar kinds of tools, but using technologies that are open.

HTML, JavaScript and CSS have been around for a long time, they’re not going anywhere, so a broader group of people is familiar with these technologies, so the barrier to entry to desktop development is much lower now.

Anytime that you have a cross-platform toolkit, like let’s take the old one that we can all kind of collectively roll our eyes at is Java applications on the desktop, where they run cross-platform - Mac, Linux or Windows; they’re just so obviously non-native, whether it’s they share widgets, designed with UI widgets that are cross-platforms, they’re not native to the operating system, or perhaps you have new APIs, for instance Apple is rumorly releasing the new MacBook Pro with that really cool OLED function key row so you can program against the function key row and put your own buttons in there when your application is focused; just a rumor, but no doubt that’s gonna be a brand new API, and because Electron and those that came before it are cross-platform tools, you don’t usually have access to the new shiny, so you can’t make it feel as native. So I guess the question is, it doesn’t seem to be slowing it down any; we’re still all excited about it, so what Adam and I are wondering is does it have affordances for you to work around those things, or does it give you access to native APIs better than the old cross-platform things, or maybe [unintelligible 00:32:25.13] and it doesn’t matter anymore? I don’t know…

Yeah, there are actually lots of APIs that are specific to a certain operating system. What would be a good example…? There’s something related to your computer sleeping; when a sleep even occurs or a waking even occurs, those events are unique to macOS. In the Electron documentation, those things are denoted with a little symbol for each operating system. There are some things that are unique to each operating system, but in general we’re trying to add every feature that we can to Electron that is available on each operating system.

The example you just gave, of the specific keyboard functions, that would be the kind of thing that would be implemented and it would only work on Mac, and we would just have to document it as such, but in general these things are landing in Electron pretty quickly.

We have some brave users who are installing the very newest version of macOS, like Sierra, and helping us find those bugs ahead of time before it lands.

So you don’t have to go and remake the wheel on your own; like Jerod’s saying, these particular features that might be only macOS, or whatever. You still plan, or at least have some ideas that you would want to implement the APIs for Electron where you don’t have to… You know, kind of take it 80% with Electron and then the other 20% you just figure out the native stuff on your own.

[34:02] In general yeah, I think that’s a good point to answer.

Let’s go back a little bit into the history, now that we know what Electron is and what it offers… It’s kind of a cool story, because like you said earlier in the show it was extracted out of Atom, which is another huge GitHub project and endeavor, and a successful project on its own. Yet, out from Atom comes Electron, arguably even more successful than Atom itself, just because it’s [unintelligible 00:34:30.11] and being used by probably millions of people at this point, whether they know it or not. Tell us a little bit of what you know about the story of extracting Atom and extracting Electron out of Atom - the history there, the decision-making and so on.

Sure. I think really the turning point was when companies outside of GitHub started to use the tool, which was then called Atom Shell, for their commercial products. I think the tipping point was when Microsoft’s Visual Studio Code editor started using Atom Shell, and it seemed a little bit strange to still call it Atom Shell when it was being repurposed and used elsewhere. I’m not sure where the origin of the Electron name came from, although I think it’s a pretty fitting name. I think it came from possibly defunct GitHub CEO… But yeah, essentially they’ve just renamed it so that it would have a more generic name, that was representative of its potential ubiquity, I guess.

One thing that I’m interested in, and perhaps since you’re somewhat new to the project you might not have these insights, so just say no if you don’t… But when did Atom Shell become a thing, and why? Was it always separate, or was it part of Atom and then they said, “Hey, let’s make this its own thing”, and then once that got popular, like you said, they renamed it to Electron. But was Atom Shell always separate, or was it part of Atom and then got separated?

I’m a little hazy on the details… For a definitive story, on the Electron blog Cheng has actually started to publish a series of posts about the history of Electron, and I think he’s done two so far. One of them outlines the very beginning, from when he was first working on the Node webkit. I think what happened was that the Atom team was working on Atom, and I think they started with Node webkit and found some issues with it; it didn’t entirely serve their purposes. They reached out to Cheng, and I think GitHub for a long time was actually just contracting with Cheng. Cheng was a contractor for GitHub, and I think that’s really where the new Atom Shell/Electron project got some life breathed into it - because GitHub needed it for Atom.

As programmers, we’re always trying to decide the right time to extract, [unintelligible 00:37:04.12] a layer of abstraction, and it seems like this is a huge successful case when what was Atom Shell and became Electron… Maybe not obvious at first to them, but once it became obvious, it was a huge move, and perhaps the best move they’ve made with regards to the project, because like I’ve said earlier, Electron’s adoption at this point probably far supersedes that of Atom’s, wouldn’t you say?

Yeah, I actually don’t have any numbers on that. Of course, it’s a more general purpose tool that’s sort of lower in the stacks, so of course its utility is more broad.

[unintelligible 00:37:47.18] with the reference to Guillermo and HyperTerm - it enables… Exactly what it says, if you can build for the web, you can build a desktop app, on the different platforms. I think it’s kind of interesting to look at this perspective of these superpowers that came out of Atom, Jerod, as you were sharing the story of where Electron came from; this was an internal thing at GitHub. Whether it was called Atom Shell or not, in the beginning it was there to help prop up what is Atom on many platforms, and the decision to extract that has given so much power to people like Guillermo, who simply want to use the necessary tools in JavaScript to build out a new terminal emulator. And rather than having to think through all the things that have already been thought through, Electron is open source… They use Electron to build and deliver HyperTerm, and so many others, he’s not the only case of it. What does it mean to you to have people like Guillermo have that kind of power, to be able to build for the web, but then also be able to deliver desktop apps through Electron? As a designer at heart, that got their heart broken a little bit, back to developer and now back to a mix of designer/developer - how do you feel about that?

I’m really excited about it. Actually my co-worker, Jessica L., described this as “This is the promised land.” [laughter] We’ve waited so long to have a legitimate development life as JavaScript developers. JavaScript has been really abused as a language; everybody has described it as ugly and underpowered for so many years, but because of Node it has really had a chance to flourish outside of the browser and become applicable in so many different environments.

Now that we have this thing that is a combination of the hottest web browser and Node itself, the ecosystem is just flourishing. I didn’t know that you guys did an episode on HyperTerm, I’m gonna have to listen to that. I think that project is exemplary of the excitement behind Electron in general.

The project is maybe two months old, and we’ve already seen… There’s a repository called Awesome HyperTerm that has just contributed like mad.

It’s really a month old. When I was talking to Guillermo, I thought - like you did - that it was out there a little longer. When I talked to Guillermo for that show, he’s like “We just released this like a week and a half ago.” I’m like, “Okay…” At the time of the show, which we released on the 29th - I think it was recorded a week beforehand - of July, there was around 90 repositories on GitHub that had the term HyperTerm in it, that was like packages for HyperTerm. During the call, by the end of it, there was another 15 more. It just shows you how fast something like that moves. The cool thing is enabling that kind of development. Without Electron, it would have been so much harder for Guillermo to actually deliver that. I’m sure he could probably have done it, but you just reduced all the barriers to entry.

Yeah, it’s really exciting. Especially with HyperTerm, just to see that somebody built a HyperTerm package manager in that first week that it came out, and it’s powered by npm, so if anyone wants to build a plugin or a package for HyperTerm, it’s a matter of publishing to npm, so there’s not really a bottleneck for contributing to the ecosystem, because there’s already something in place that works really well.

[41:32] I’m really excited. Actually, I’ve been using HyperTerm exclusively for about two weeks now. It’s got a few little bugs, but for the most part it works really well for me. I had a bug with my font rendering yesterday, and I was able to open the web inspector in my terminal and figure out what was wrong, and that was so cool. I had just typed the font name wrong, but actually being able to figure out why I was a having a problem using familiar web developer tools, it was really empowering. Because if something like that was happening with terminal.app or iTerm, I’d just be kind of up a creek. Just being in an environment that is basically the Chrome ebrowser and having access to all these tools that I’m already familiar with as a web developer is really empowering.

Well, let’s talk on that note, because HyperTerm is obviously a great candidate for the power of Electron. Let’s talk to the developers out there that should be using Electron, Zeke. Are there any dreams, is there a list inside of GitHub of like “These are the kind of apps we would love to see built with Electron.” What out there should be built with Electron?

Well, really anything that should run on a desktop. [laughs] The nice thing about Electron - or one of the nice things - is that you don’t have to conceive of an app as a thing with a visual interface. It could actually be an app that’s just like a Daemon that running in the background. Historically, if you’ve wanted to make a Node app that does that, it’s actually kind of a lot of work to try and just get an app that will start when your system starts up or when you log in, and will just run in the background and do something useful. You have to edit .plist files on a Mac… You basically have to do a bunch of tedious work to get it running, and sort of pray that it works out. But with Electron, it has built-in APIs for launching itself at startup, so if you want it to run some kind of Daemon - I have an Electron app that’s just tracking my location all the time, so I have this running stream of geo-information that’s just being pumped into a geo JSON file, just for my own amusement.

I think the interesting thing there is that it’s not just about developing new graphic interfaces, it’s really just a way to simplify the process of creating apps for the desktop.

So you asked who should be using Electron, or what kind of apps should be built with it… I think that’s really only limited by our imagination. We’re getting lots of really interesting apps coming in on the Electron website. That’s an open source website, and people who build apps can submit them with an icon and a little bit of a description, a link to the repository if it’s open source, and things like that.

We’re seeing a lot of things come in, and it’s a mixed bag, it’s not like a specific kind of application. The most notable apps that are built with Electron are probably Atom, Slack… Slack used Electron for their Windows and Linux clients, and they’re in the process of using it for the Mac client as well. Slack is really ramping up their Electron team. They now have at least three people full-time working on Electron stuff, which is almost rivaling what we have at GitHub, so that’s pretty exciting. Of course, Visual Studio Code, which I mentioned. There’s an app called WebTorrent, which is an app for downloading torrents which is really simple and straightforward. Then I’ve been using one called SimpleNote, which is created by Automattic, the Wordpress people. SimpleNote is just a note-taking app, and of course note-taking apps are a dime a dozen, but it has really nice integration with a mobile client as well; it’s just a note-taking app that syncs across all the devices.

[45:54] My personal favorite Electron app ever is called Mojibar. It’s just an app for pulling up a little search tool for finding emoji. It’s nice because if you don’t know the name of the emoji that you’re looking for, you can type in the keyword and you’ll be able to find it. That was created by Muan, who works on the design team at GitHub. She’s produced some really elegant, simple Electron apps. I usually encourage people to look at her apps as a starting point, because they’re usually like a single file that you can read through and pretty clearly understand how it works. She doesn’t really do the thing of like dropping in babble and React and every new thing under the sun, so it’s a nice place to start.

Yeah, a good starting point there. This kind of reminds me of the renaissance - or I guess maybe more like the revolution and less renaissance - that’s happening on mobile, where you have iOS that doesn’t seem to play well with web apps, they want the native app. Then you’ve got this revolution of wanting to build with native tools that you know, and kind of having this operating system resist you or prevent you from doing it as easily. Adding a web app to your home screen in iOS is not as common as it is on Android. So it seems like this might enable people to essentially do what you’ve done in the past with something like Fluid app where you simply wrap a website in a Mac app and it will launch it. It kind of is a little bit like that. Do you see or do you think that some applications or some websites that act as applications should really be native applications? Would Electron add more - like we said earlier, does it add more to it than building it in the native web browser? It seems like there’s a lot more of this potential happening and it’s not quite there yet, but some of the mentions you just said there, examples like Mojibar, it seems like you could probably go to a website, mojibar.com and search for those just as well. Why make it in the system tray, you know?

Yeah… Interestingly, Mojibar has a website counterpart, which is called EmojiSearch.info, or something like that, I can’t remember it off-hand. But for me it’s about productivity. It’s a lot easier for me to evoke a keyboard command that opens the Mojibar search with the thing emphasized, and I don’t have to make any network requests. I’m in the middle of working on some… I’m like in Slack, trying to type some message or trying to file a PR, an issue on GitHub and I wanna use an emoji - I don’t really want to open a new browser tab, type in a web address, focus the input, search, click… It’s really just about being able to move more adeptly, or get things done more adeptly, especially with keyboard shortcuts. In the case of Mojibar, it’s just about the convenience and the speed.

This is making me think - I mean, on the same note here… Jerod, I don’t know if this is appropriate for the show to dream like this, but it’s really making me think that the Changelog could potentially have something to do with Electron and ship a version that essentially just easily adds a player to someone’s local machine, and rather than having to go to the website or open up their mobile app, just one more way to listen to The Changelog or to the many shows we have coming out is a key command. So can just sit and now you can access your playlist and play the next episode, or whatever… I mean, I just wonder if that’s what we should be encouraging people to do. Not so much us, but that type of behavior, using Electron.

[50:03] Yeah, I think Changelog would be a great candidate for that. You have these episode files - I don’t know how big one is on average, but a considerable number of megabytes, and if you had a desktop app, you could download that thing, store it in your user’s cache, and the file would be readily available at all times. So if anybody wanted to listen on an airplane or in some place where they didn’t have web access, they could have a backup of all their Changelog episodes.

Yeah. I think anybody who has a website that is web app-ish… You know, I’m sitting here, using Google Docs, thinking… This kind of reminds me of the days of Fluid and the other tools, Adam, back when we used to wrap certain websites that we visit often, instead of having them pinned in our browser to a specific tab… Like, breaking them free from the browser. I guess my question around that - obviously, if we’re Changelog, we could build an Electron-style Changelog thing that ships as an app, but does it empower users, or just app developers?

I love Google Docs, so could I build with Electron a desktop version of Google Docs without having to run Google Docs itself? Can I wrap it and provide some integrations?

Yeah, so the really easy way to do that would be to use a tool called NativeFire, which is kind of a weird name. It’s essentially like a Fluid app, but it’s an Electron thing, and it’s a command line tool where you just call NativeFire, you give it a URL, and you can pass various arguments, like the icon you want it to use, the name that you want the app to have when it lands in your applications directory and things like that. But the really interesting part is you can also pass in a custom script that will be execute in the window context of that app.

Let’s say you wanted to make your own little github.com GUI or your Google Docs GUI as a standalone app, but you wanted to make it so that various aspects of the app behaved differently. Say you don’t wanna see the menu bar at the top of the screen. You could just write a tiny little JavaScript that is like document.findthiselement.removethiselement. So you have a lot of flexibility there, and you don’t actually have to do a lot of work. In that case, you don’t really need to know anything about Electron if you know a little bit about how to work with Atom, and if you wanna drop in jQuery or whatever, that’s all doable. That’s the easiest way to do it.

If you want more explicit control over wrapping some website, then you could actually create your own Electron app from scratch and then have it open up that website in a web view, and then you still have access to all kinds of other things. In that context, you would have access to the user’s file system, you’d have access to all the HTML5 APIs, like geolocation and things like that. So if you wanted to add supplementary features or behaviors, or take things away from existing websites, you have that option.

It’s kind of like an extension of browser extensions, that’s going a little bit even further. I have a couple of them that I run… I have one for Gmail inbox that I use, just so I don’t have to have a pinned tab in my browser.

[53:53] I think this is probably a good chance for a break. On the other side, we’ve got some more questions for you, like “What’s the future of Electron? Are there any downsides? When is it a bad idea to use Electron?”, those kinds of things. We’ll break here and we’ll talk about those on the other side.

Break

[\00:54:07.27]

Alright, we’re back with Zeke, talking about Electron. We’ve talked about what it is, why you can use it, why you might want to use it; we even talked about the Changelog maybe building an Electron app - how cool would that be?

Super cool.

Yeah, it’d be super cool. Let’s talk about the downside a bit. Let’s talk a little bit about the places where maybe Electron doesn’t quite fit in, or is not optimal. Cases where somebody might pick it up and then say, “Hm, this is not the tool for the job that I need to solve.” So Zeke, I know it’s tough because you’re an Electron guy; you had all the good sides, but surely there are some places where it doesn’t quite fit. Can you share some insight there?

Sure. The biggest one that stands out to me is that Electron doesn’t work for making mobile apps. That’s one of the questions we get a lot, why doesn’t it support mobile, when will it support mobile? The best answer we have for that right now is it seems inevitable that eventually the world will converge on a JavaScript, HTML and CSS framework for building apps that can be deployed to or built for all platforms and all devices. We’re not there yet, so I think the thing to do now is just design your applications in such a way that the moving parts can be shared across-platforms. So if you’re developing an Electron app, you could develop part of your app as a server that can be used by your mobile app and your desktop app, or you can write small npm modules that can be shared between your applications.

That’s kind of a bummer, but I think it’s only a matter of time before we will get to this beautiful place where JavaScript developers can write native applications, and there are interesting things happening in that space. Of course, React Native is a really exciting project, and you can build apps for those targets. Electron has a little bit of catching up to do in that space, though.

Another thing that comes to mind is that general Windows developers are under-represented. A lot of the web development world is focused around UNIX and Linux methodologies, and there’s an expectation that you can run Bash commands on your machine. A lot of times we will get bug reports from people running on Windows systems, and our team, we all have virtual machines for running various versions of Linux and Windows, but without that sort of intimate knowledge of Windows and how to develop in Windows, it can be hard. So that’s definitely an under-represented part of the developer community now.

[57:50] I would imagine that Microsoft, with their Visual Studio Code project, would probably be able to help out, or at least be a good citizen with regards to getting you guys Windows bug reports or help with that. Have you experienced that at all?

Yeah, there’s a guy named Felix Rieseberg; he was at Microsoft for a while and just very recently moved over to work at Slack. He’s been really one of the foremost evangelists for Electron in the Windows space. Now that Slack has three or more engineers working on Electron, they’re all actually really focused on the Windows stuff, and they’re all core contributors to Electron, as well. So things are definitely getting better, and we do have access to people who work for Microsoft, or work on a Microsoft platform, but internally on our team it’s definitely a space that we are not totally comfortable with yet.

Well, you have four people on your team there at GitHub, and no doubt you all are busy working on all sorts of cool new things, so let’s talk about what you’ve been working on lately - new features coming to Electron, changes… Give us a glimpse into the future for the project.

Sure, so a new Electron version gets shipped roughly once every week, and typically this is just to get us up to running the latest version of Chromium and the latest Node. So whatever features are trickling down from Chromium, those automatically end up in Electron. Usually it’s a lot of small details that are sort of idiosyncratic little pieces of changes on various operating systems. It’s mostly stuff around native integration, like the way that trays behave, or the way that Windows behaves when you full-screen them or take them out of full-screen mode, or the transparency of Windows, and things like that. So mostly just lots of little bug fixes and maintaining the status quo.

We’ve recently improved the process for publishing to the Windows store and the Mac app store. There’s a document on the Electron website for how to publish to those stores. There’s a little bit of work you have to do and there’s some considerations that have to be made when you wanna publish for those platforms; if you’re publishing to the Mac app store you can’t use the auto-updater, or you can’t use the built-in debugging tool because it makes network requests that aren’t allowed by the app store. So there are some considerations that need to be made, but there’s definitely full support for publishing to those two stores.

Another thing that just happened is that we reached out to the owner of the Electron package on npm, and he was willing to hand us the name. Traditionally, if you wanted to start building an Electron app, you would npm install Electron Prebuilt, which is just a pre-compiled version of Electron that is the right one for your operating system. We had a lot of users who would just dive right in and type “npm install Electron” and they’d get the wrong Electron because it was some old project.

We just managed to switch over to that new name, and we will continue supporting the old name through 2016, but we’ve done a lot of work in userland to patch various popular projects so that they will work with either name. The hope there is that newcomers to the project will not be dumbfounded when they npm-install their own thing.

It’s nice to hear that the owner of the Electron name was willing to give it over to you without much trouble.

Yeah, his response was, “I knew it was just a matter of time before you would contact me.” [laughter]

You didn’t have your lawyers kicked out the door.

That’s so funny…

Yeah, we actually did the same things with the GitHub. We have the Electron Organization on GitHub as well, and there was a user named Electron, so we reached out to them too and they were happily willing to turn it over in exchange for a GitHub hoodie.

[01:02:09.13] Those GitHub hoodies are quite lucrative. [laughter]

Yeah, the power of swag.

They can pave the way for many things.

Indeed. Other things coming along, we are working on generating a JSON schema of all of Electron’s APIs. The goal there is to just have a JSON object that describes all the classes, all the modules, all their methods, arguments, events, the properties of all those events. It’s kind of open-ended what the purpose of that is for. The immediate purpose is just to have some kind of specification for APIs, so we’ve kind of gotten more detail-oriented around how we generate our documentation for Electron, but the hope is that this schema could be used to make IDEs that are more Electron-aware, so as you’re typing Electron code, it will auto-suggest the right method names and arguments and things like that. Also TypeScript is kind of blowing up in this community, so we’re looking to figure out how to get some TypeScript definitions for Electron that are always gonna be up to date.

And something else you teased me about during the break which I’d love to have you share with the listeners is that we talked about a Changelog desktop app, but that’s just conjecture. One thing that you said is definitely at least in the works is a GitHub desktop app based on Electron. Can you tell us about that?

Yeah, so the GitHub desktop app that the public knows about right now is built in - well, it’s actually two different code bases. There is the Windows version and the Mac version, and those were sort of worked on and maintained by two different teams at GitHub. Recently they decided that we should be dogfooding and actually using Electron internally for more projects, so they’ve started on a new version of GitHub Desktop which is not yet public, but I’ve been watching the activity and it’s really astounding how much work they’ve gotten done. It’s just a small team working on this app. It’s really nice, because they don’t have to… The sort of operating system-specific expertise is not really required in the same way anymore, so the team can move a lot more quickly. So stay tuned for a new version for GitHub Desktop at some point. I’m not sure when it’s expected to be opened up, but it will also be an open source app when it’s ready. The hope is that that can be an app that is exemplary of the kind of things you can do with Electron.

Is it the same team working on it, or is it a new team?

It is the same team. Josh Abernathy, who runs the team, just had a recent tweet storm about how awesome it is to be working with this set of tools where they can move so quickly, and he was sort of lamenting the fact that he spent so many years as a Cocoa developer and never would have been able to move this quickly developing in Cocoa.

Wow…

So is this application looking for feature parity with the current GitHub Desktop, or is it a rethinking and brand new app?

It’s definitely for starters seeking feature parity with the existing app, because they don’t want it to be too much of a change from what existing GitHub Desktop users are accustomed to.

Gotcha.

[01:05:51.22] I think the longer term goal is for this tool to be something that allows for deeper integration into the desktop environment for GitHub. It could also become the sort of blessed way, the canonical way of setting up GitHub on your machine. For new users who are just unfamiliar with Git, or even if they are familiar with Git, this could be the best way to just set up GitHub on your machine by just running this one installer and knowing that everything is working properly for you.

I like the idea of dogfooding it, too. Your Atom team obviously has had the pleasure of Electron, obviously with it being the starting point, but then also to look at other areas of GitHub where Electron could be used. And then dogfooding is always good, because if you continue to build the desktop app natively versus Electron, we might say “Hm, why are they doing that?” But we’re not gonna do that, because that’s not the truth.

Yeah.

Well, it’s time for some closing questions. Is there anything else you wanna share before we cut to that part of the show? Anything else you wanna share about Electron, the team, the future? Anything left unsaid?

Yeah, I have a couple notes here. One thing that’s really cool that I didn’t cover is that because Electron is based on Chromium, you get all these really nice new features that as a web developer you’re probably not accustomed to using. When you’re doing normal web development, you have to consider all the target browsers and all the sort of inadequacies of those various browsers. And when you’re just working in Chromium, you don’t have to think about all those things. Chromium has nearly complete ES6 support, so if you started to get accustomed to writing the newer style of JavaScript, you can just do that out of the box with Electron. You don’t have to set up Babel in your toolchain, you can just write ES6 and it works.

The other thing is there are a lot of really interesting new CSS features coming - or actually they’re already in existing versions of Chromium and Electron. One of them is CSS custom properties. If you’re familiar with variables from LESS or Sass, it’s essentially the same thing. You can declare a property in your CSS style sheets and reuse it in various ways.

Super cool.

Yeah, so there’s all these little things that are making regular CSS and regular JavaScript good enough, so you don’t have to spend as much time setting up an entire build process for your application. You don’t have to bring in Sass or LESS or Stylus, and transpile those on the fly. You can just write regular CSS, and in many cases it’s actually good enough.

There’s also a new thing called the CSS containment property, which lets you limit the scope of the browser’s layout and paint work. If you’re trying to get really high performance graphics in your application, this is a new sort of low-level feature that you can manipulate in CSS to get the highest performance and framerate out of the DOM. Those things are all really exciting, and it’s really nice to be able to create applications without having to set up too much boilerplate.

It’s always good not to have to jump through hoops or do so much ceremony to get the latest-greatest features. Delivering to or building to one particular browser obviously has its advantages, so it’s nice to see that Electron allows developers out there to capitalize on that advantage and even save a ton of time, because that’s the point - the less time we spend redoing work or reworking things that have already been done before, or dumping right to ES6 with the latest features of CSS, the better it is for the ending product that we deliver to end users.

[01:10:08.09] Anything else that you wanna share? Is that it for your list? Can we go onto some of our closing questions?

Yeah, I think that’s it.

Awesome. So one of the questions we like to ask, especially in this case here - GitHub is huge, we’re honored to have you on the show and to share the story of Electron and your story also with our listeners. We’re huge fans of all the work happening there, but you’ve got to be asked all the time - how can people of the open source world, how can developers step in and help the Electron mission? Is it issues, is it testing builds? Where can people step in to really help Electron be exactly what you have all dreamed it should be, and help that mission keep moving forward?

One of the things you just said is what we’ve dreamed it should be, and we have been kind of trying to work out a roadmap internally for Electron, like what do we want it to be in the future, where do we want to take it. One of the things we realized is that as an open source project with a giant community, one of our main goals should be to listen to the community and to let the community steer the development of the project. We shouldn’t be masterminding the future of this thing; in some sense it should just evolve organically, and that’s how it’s been going so far.

Most of the work we’re doing is just kind of stewarding the community contributions and helping get more and more contributors up to speed. Areas where we’re lacking are, like I said - we could always use help in the Windows department, so anyone who is a Windows developer working with Electron, we can always use your help on issues.

Another one is translations. We have our documentation which we maintain in English, and the English version is the only one that we actually programmatically lint and make sure that it’s all accurate. There’s a huge collection of translations, I think it’s in eleven languages now, and over a hundred people have helped us translate the docs into those languages, but they fall out of date. Any time we make a change, it’s not guaranteed that anybody’s gonna jump in and update the English docs to work on those eleven different languages. So multilingual people who are using Electron, we could definitely use your help, just jumping in and making sure the docs are up to date. At some point we will be doing a more large-scale effort to potentially hire translators to work on keeping various translations up to date to a degree that we’re comfortable displaying them on the website and saying, “Yes, this is definitely accurate.” But in the meantime just community contributions on documentation would be really helpful.

So the docs are actually part of the core Electron repository, right? So you’ve got Slashdocs, everything lives in there; if you need to make changes or initiate some changes, that’s the easy way to do it there. You’ve got the blogware, you’re obviously keeping people up to date, and I think you mentioned some other ways to voice the community’s opinion. Is issues the best place for that? Is there a certain tag on your issues that you’re leveraging to kind of say “Help needed” or “Help wanted”, or anything like that where somebody can kind of easily go there and see a quick list to start stepping in and helping out?

[01:13:56.01] Yeah, we do definitely use some of those labels, and thanks for outlining where the docs live. We definitely keep the repository as the canonical source of all the documentation in the docs folder, and the majority of the content on the website is actually just repurposed from the repository, aside from the blog posts. But our plan internally is to actually continue to use the repository even more as the source of documentation, because it’s in front of people’s eyes more and it’s easier for us to just agree that we have this one canonical place to keep all the docs, so don’t expect that to change any time soon. So yeah, we definitely make heavy use of issue labels as well too, so for people jumping in it’s pretty easy to find stuff to work on.

I’m seeing the label “beginner”, and then I also see a lot of “beginner” labels attached with documentation too, and even “enhancement” - are you familiar with that label by any chance, and is that something that… I also see “help wanted” too, I’ve only seen one of those, but those are two labels that are kind of like easy jump-in points.

Yeah, definitely.

That’s a good label to hit up. There’s actually two that have “help wanted” that’s an issue and it’s open, so you’ve got two “help wanted” places. We’ll link that and the “beginner” label up in the show notes; that way we can give people a direct link to the issues that could be a good place to start with.

In general - this applies to any open source project, but if you’re filing an issue, try to see if the issue already exists somewhere on the repository, instead of just opening one from scratch. Another thing is sometimes we get pull requests from people that don’t necessarily fit the bill. A good practice is to often just open an issue first to talk about what you wanna change, so that you get a little bit of conversation around it first. That way nobody wastes their time writing code and opening a PR that may not get merged.

A question we love asking is a hero question. So you’ve got somebody that’s been an influencer to you, somebody that shaped who you are over these years. It could be a programmer, it could be somebody else, but we typically frame it as “Who’s your programming hero?”, so who’s that person for you?

My programming hero is Max Ogden, known as @denormalize on Twitter and maxogden on GitHub. He’s one of the early members of the Node community, and he’s just a very prolific contributor to open source. He created a sort of methodology called OPENOpenSource.org. Basically, he was creating so many repositories, and eventually there’s only so much that one person can do to maintain his repositories, so he started handing out admin privileges to anyone who was making meaningful and valuable contributions to his projects.

The idea behind OPEN Open Source is if someone is contributing to your project and they’re doing a good job of it, let them be a part of it, give them admin access, make them an owner on the npm repository as well. This has a really profound effect on projects in my experience. As soon as you give someone admin access, they feel a sense of ownership over the project and in general they’re not going to mess it up, they’re going to take it seriously. It can be a really great way to sort of free yourself up from projects that can become burdensome, especially if you’re just producing a lot of really quality work and people start to really become dependent on these projects.

[01:17:53.09] Max Ogden was a very early contributor to a lot of Electron projects. There’s an organization on GitHub called electron-userland, and some of the most fundamental pieces of the Electron toolkit are on there. There’s one called Electron Prebuilt, which I’ve mentioned earlier, and that’s the thing that when you npm install Electron, you’re getting a precompiled version for your operating system of Electron. So Max Ogden and his partner in crime, mafintosh (Mathias Buus), they wrote that. And they also wrote another thing called Electron Packager, Electron Download, a bunch of different parts of the Electron ecosystem. Our team at GitHub has slowly started to become more involved in maintaining these projects, but we are indebted to Max Ogden for having written them in the first place.

Max is now working on a project called Dat, and the goal of Dat is to enable scientists to share data with each other. That’s been his main focus for maybe a couple years now, and he’s mostly been focusing on raising money to build up a team for this non-profit, to enable scientists to share data. In general, his mission is about improving the free exchange of information, and that’s really what is the most inspiring thing to me.

I’m not sure if you purposefully said Max Ogden or not, because on September 1st we have a new show called Request For Commits, you may have heard of it, Zeke. The listeners are definitely getting more familiar with it; we’ve got three episodes out, and as of Friday we’ll have four, when this show actually airs. We actually had Max on in episode six, which is slated to release in the month of September, September 1st, and we talked about that. And we talked about not that [unintelligible 01:19:59.14] but that, as the project that you mentioned. And we talked about grant funding, what happens when you pay for open source work… We talked about all sorts of interesting things, his process to get grant funding. Max has been very successful with getting and receiving grants, and actually executing them very well, and Dat is one of those things. He talked deeply about that project, and about the human side of open source, not so much the technical sides of Dat by any means, but this grant funding process, leading open source in the right direction. If you’re at all a fan of that, listeners, we love Request For Commits. That show is hosted by Nadia Eghbal and Mikeal Rogers, and you can find it at Changelog.com/RFC. If you have not subscribed yet, please go do it right now. September 1st is when Max’s show comes out, and it’s gonna be awesome.

Perfect.

Thank you for the perfect layup on plugging Request For Commits, it couldn’t have been any better; I really appreciate that. Anything else? Any last closing thoughts before we tail off the show?

I just feel really lucky to be working on this project, and to be part of something that people are so excited about. It’s been a really long time in the making, and we’re just now finally in this place where developing applications with open web technologies is a reality for people.

Yeah, it seems to be the perfect timing, and even more so, perfect timing for you, considering the history you shared earlier in the show, and having that designer background but also the responsibility you’ve gained over these years on the developer side to deliver such a cool to impact such a large community. I think it has got to be emotionally rewarding, as well as rewarding in general, as something you do every day. That’s a cool thing to do.

[01:21:52.04] Yeah, to be able to work on something that I really enjoy and get paid for it - that’s a - what more can you ask for?

Nothing else, that’s it. That’s where you wanna be, right there.

Yeah.

Well, Zeke, thanks so much for taking the time to share with us your story, the GitHub side of Electron’s story and how the community can begin to dream with you, and then also just the invitation to the community, because while it’s created by GitHub and maintained by GitHub, it’s not a GitHub-only steered thing. You invited the community to dream with you and to influence that change and step in where they can to make Electron what the community needs it to be. I appreciate you having that right direction, and listeners, we thank you obviously for listening to this show. We ship two emails every week - one daily, one weekly. We actually didn’t call it Daily, we called it Nightly, so if you go to Changelog.com/Nightly - and Zeke, you’re a fan of this email, right? You like the light version versus the black version - not so much the color, but the fact that it’s a little bit brighter on your eyes, I’m not sure why… But you’re a fan on Nightly, so any quick sentiment on Nightly for the listeners to chew on for that?

Yeah, it’s just a good way to keep up on things that are happening on GitHub every day.

And we love GitHub, of course. So Changelog.com/nightly for that email, subscribe to that. Jerod and I work tirelessly all week long, prepping for Weekly, which is what we call Changelog Weekly. If you go to Changelog.com/weekly, subscribe to that. It’s our editorialized take on what’s happening this week in open source, in software development, our latest shows are in there… We do a lot of writing, painstakingly writing that email every week and we love doing it, so please subscribe to that.

That’s it for this show here, so let’s call this thing done and say goodbye.

Goodbye. Thanks again, Zeke.