The Changelog: Software Development, Open Source - GitHub's Electron (Interview)

Episode Date: August 19, 2016

Zeke Sikelianos joined the show to talk about GitHub's Electron project and the future of web folks making cross platform desktop apps. We talked about the web revolution around native vs web app, where Electron is heading, who's using it, and how cool it is to enable folks like Guillermo Rauch to build HyperTerm.

Welcome back everyone. This is the Change Log and I'm your host Adam Stachowiak. This is episode 216 and today Jared and I are talking about something cool called Electron from GitHub. doing this to talk about all things for web for desktop. It was cool. We talked about cross-platform. We talked about the revolution of the web. We talked about all the cool ways that GitHub is pushing this project forward. It was extracted out of Atom, as you might know. Electron is super cool. If you know HTML, CSS, and JavaScript, you can build a desktop app. We got two sponsors today, TopTile and Rollbar.

Our first sponsor of the show is our friends at TopTile. And this message is for all those team leaders out there looking to easily add new developers and designers to their team, easily scale up when you need to. You got a big push coming. You got a new area of the product

you've got to go into. You've got more need than you thought you could. You've got to go through all this hassle of putting a job out there and hiring people to find the right people. Well, that's a bunch of hard stuff that you don't need to even deal with. Call upon my friends at TopTal. That's T-O-P-T-A-L.com. The cool thing about TopTal is that you can hire the top 3% of freelance software developers and designers. And what that means is they've got a rigorous screening process to identify the best. So when you call upon them to help you place the right kind of people into your team, then you know you're calling upon the best people out there. Once again, go to TopTal.com.

That's T-O-P-T-A-L.com. Or if you'd like a personal introduction email me adam at changelove.com and now on to the show all right we're back we got zeke sikellianos on the show today and jared this is a big show for us because like we've talked aboutron several times on the podcast. And this has been a 1.0 in the making, basically. So what's up with this show? Yeah, well, 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. One of the ways we like to start off a 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 the last part comes in, but we like to learn a bit about the guests that come on the show to kind of figure out, you know, Hey, you're on the electron team. Now you work at GitHub, you do what you do now, but what got you there? Like what inspired you to become a software developer, become a designer, or even become a home builder? So what's your story? How far do we got 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. So as a youth, I was really interested in art and design.

And I think I actually got my start doing graphic design and learning Adobe Flash, or actually it was Macromedia Flash at the time. And just wanted to create interesting things on my computer and 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. So I got 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. So 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.

So 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 eventually wanted to learn something better or something more powerful or a little bit more of a humane programming language. Ended up getting into Python and eventually Ruby. And 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. Eventually I moved out to California in 2007 and started doing Ruby on Rails development full time and moved to Silicon Valley eventually and started working for Heroku. And that was really when my career started to become really programmer focused or, you know, working primarily on developer experience stuff. So 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 those that ops sort of stuff so 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 so i kind of got involved in something that I swore to never have interest in. And it sort of continued to happen from there. So 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 of thing.

So if you're building an application and you want to provision a database for it, you go to the add-on site or use the command line interface to effectively purchase a database in the cloud. So my job there was to kind of design and build out this app store. From there, I eventually 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. And 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.

So 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 get push Heroku master with your Node app, there's basically a set of bash scripts that run that prepare your app to run on the platform. So 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.

So this was like kind of the beginning of the end for me in terms of like my design career. So this was really intriguing to me and really fun, but it was also like just a purely developer oriented project, right? Like there's just literally no aesthetic element to it. Just, um, really trying to improve developer productivity. So despite it's kind of been an identity crisis thing for me, but, um, I've embraced it because 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 5,000 developer minutes per hour. And just thinking about all the people who were having an improved development workflow because of this work. So that's that kind of working on something with that kind of reach is addictive. So from there, I NPM was forming as a company. Isaac Schluter, who created the NPM project, had just left Joyent to found NPM and so I got in touch with him and ended up leaving my very comfortable position at Heroku to help start NPM. What's the role at NPM then since your designer heart was a little crushed

did you get to pick it back up a little bit or did you stay on the developer side? I got a little bit of it back. So my job was to work on the website. So the website that you see now at NPM, js.org or NPM, js.com. Most of that is, is my design work. Um, we did work with an outside consultancy for some of the design, but primarily the package page was my main focus. So my goal there was to try to make the NPM package page as, as useful or more useful than a GitHub repository page.

So as a developer, when you're picking out, 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 um 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 so 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, so you're talking about like npmjs.com slash package slash blah, whatever that blah is like slash async slash npm, whatever the package is, when you hit that package page, you can see if it's public, you can start it, learn more about it. This is the page you're talking about, right? Yeah, absolutely. So it's some of the most meaningful pieces of metadata there are how recently

was, it's mostly in the sidebar, right? 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. And then also downloads are somewhat useful in registry that even if your package is not being used by any humans at all, just the mirror active 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. So it can be a little bit misleading, but 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, npm search. And we'll have it in Change.log weekly, either this week or next week, depending on when the show goes out. But I think you would like it, Zeke,

because it's trying to do what, for NPM search, what you were kind of doing for the first party package pages, which is to organize the search around quality, maintainability, and a few other metrics, which he actually scores each package. I'm not sure how the algorithm works, but he scores them on like a one to 10 on those three different metrics. And then he integrates that into the search.

So it's basically, it seems like a proof of concept. I think he probably eventually wants NPM to adopt it, you know, 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 you were trying to expose when you were working on the package pages. Yeah, so we actually, when I was at NPM,

we talked about that a lot. And I think one of the conclusions that we came to is that you can't really assign a numeric score to a package because there are so many factors that can be affecting your judgment. So one of the things is like there's a very prolific module author named Substack who was one of the early sort of members of the node. What do you want to call it? The Node Zeitgeist. Community.

Yeah. And he wrote some really sort of 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. So you may see a package and think, oh, this hasn't been touched in four years. Probably not safe. But in many cases, those packages are actually stable. Yeah. So 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 NPPMs website is very cool. I really love 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 Elasticsearch appliance that they currently have. So it was kind of like the thing that nobody wanted to touch. So it would be surprising to me if they put any real effort into search. So I would continue to expect those 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 that, you know, like Thomas Watson, I've talked to him from the NPM community as well, and he works at Opbeat now because of his influences and because of his

work on Opbeat in the open source area they're like hey you're really passionate about Node.js on Opbeat come work for us and so 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, so as far as finding ways to sort of 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. And so that's actually a third-party site called Tonic Dev.

It has a little sort of online REPL kind of console thing where you can actually sort of play with a module live. Obviously, it only works for browsers that are, or packages that are browserify-friendly, but there are many of those. And then also I think NPM's search tool has an autocomplete feature that is also powered by some third party service. And those came to, yeah, it's called constructor.io. So those came to exist just because there were people in the user space who

were really interested in getting these integrations on their, on the NPM website, just because obviously their visibility in the community is going to 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 sort of modularizing the website into some different NPM packages with separate responsibilities. The end goal being that we could solicit a lot more feedback and contribution from the community. But unfortunately, what happened is that NPM had to make some internal revisions to the registry.

So 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. And it does a bunch of work to clean up the data in the Couch database and then also to add supplementary metadata about scoped packages. Scoped packages are like at username slash package name. So this is a new way for paid users of NPM to actually, and I think free users of NPM to start to have their own namespace for packages. But for technical reasons, the registry is effectively closed source now. So when that happened, the NPM website was no longer able to be run by anyone

who doesn't work for the company. So you could still clone the website source and NPM install, but if you actually wanted to run a development version of the website um you couldn't because there was no no data store to sort of integrate with or no like mock database to to use so um this was something that was really important to me and unfortunately the the that is not the priority of the company, which 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.

That makes sense. I mean, everybody has their own motivations and we'll have to save debating that for a different show because we can go too deep there. But 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, you know, we use quite a bit to as the change organ as developers. We look at that page quite a bit just to kind of compare and contrast what's happening in a repository and who's involved in it and what their contributions are. And obviously representing and clearly defining those people, you know, for doing what they do there. But take us to GitHub. You know, you got, you know, your designer heart crushed to a degree at Heroku, but you were doing great things. You know, revived it again at NPM. And, you know, this story you've told us now. So how, you know, what's the state of things now for you personally, and then take us to what you're doing with electronic GitHub. And we're coming up close on a 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 of my life, things have changed quite a bit. I ended up leaving NPN. I got married. I conceived our second child with my wife, moved across the country to New Orleans, ended up moving back across the working for a startup in the East Bay, um, called Josephine that is trying to sort of change, um,

the, the market for home cooked food. So they're trying to enable, um, cooks to sell food out of their homes. So I was helping them kind of get their product up to up to snuff for a while but i kind of had a little bit of downtime there and and was really looking for the next place to land where i could really sink my teeth into more node related stuff so of course github was really appealing to me and um i already knew a few members of the uh the electron team having worked with them in various capacities. The NPM website's readme parser is actually powered by a piece of Atom. I had collaborated with Kevin Sawicki, who's one of the founding members of the Electron team. I had my foot in

the door a little bit there. But Electron was just really appealing to me because, you know, it's like being a kid in a 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 sort of the inadequacy of browser development life for the last 15 or 20 years. Let's go ahead and pause there. Then we'll come back and we'll, we'll dive a little deeper, obviously into the electron

team and where it came from. We got tons of stuff to cover in this show. So let's, let's break. Now, when we come back, we'll dive deeper with Zeke and an electron. We'll be right back hey everyone adams dukovic here editor-in-chief of changelog and i'm talking to a rollbar customer rollbar puts errors in their place rollbar.com slash changelog check them out get 90 days of the bootstrap plan totally for free. I had a conversation with Paul Bigger,

the founder of CircleCI, and he talked deeply about how they use Rollbar and how important that tool is to their developers. Take a listen. One of the key parts about doing continuous delivery, you don't just have to test your software, but you have to constantly keep track of it. You're going to be doing deploys 10 times a day or 20 times a day. And you have to know that each deploy works. And the way to do that is to have really good monitoring. And Rollbar is literally the thing that you need to do that monitoring. You need to make sure that every time you deploy, you're going to get an alert if something goes wrong.

And that's exactly what Rollbar does for CircleCI. So obviously CircleCI is important to your customers. You shouldn't have errors. You shouldn't have bugs. And the purpose of a CI is continuous delivery, obviously, but getting your customers code to production in a fast manner that's tested and all the necessary things a CI provides. Tell me how important Rollbar is to your team and your organization.

We operate at serious scale. And literally the first thing we do when we create a new service is we install Rollbar in it. We need to have that visibility. And without that visibility, it would be impossible to run at the scale we do. And certainly with the number of people that we have. We're a relatively small team operating a major service. And without the visibility that Rollbar gives us into our exceptions, it just wouldn't be possible. Oh, that's awesome.

Thanks, Paul. I appreciate your time. So listeners, we have a special offer for you. Go to rollbar.com slash changelog, sign sign up get the bootstrap plan for free for 90 days that's 300,000 errors tracked totally for free give rollbar trying today head over to rollbar.com slash changelog all right we're back with Zeke Sekelianos. And Zeke, you know, 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's it for? What do you tell people?

Yeah, so the gist, which I'm going to steal from the homepage, is if you can make a website, you can make a desktop app. So Electron is really just the open source core of the Chrome web browser mixed in with the Node.js runtime. And 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. Now, 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? And I won't name those, but from your perspective, what is it about Electron that just makes it be so wildly adopted? As you mentioned, the homepage, you've got applications like Slack using it. You've got WordPress.com using it, WebTorrent, which we're going to cover in a future show,

the new latest and greatest Hyperterm, which we covered most 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. I mean, so Electron, though it seems like a new thing, it's actually been worked on daily by this guy, Chang, 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 wanted to,

that he got wrong or that he wanted to redo or do differently. And so we started on Electron. So Electron has been really in development for about four years now under a different, under various names, I guess you could say. But I think really we're just at a point now where with Node having sort of come into existence about five years ago and the ecosystem having enough time to flourish and reach a much broader audience of 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. So I think it's just, uh, it's more a matter of, uh, timing than being the right product. You also have a segment here on the homepage that says the hard parts made easy, uh, as deep as you can take us into those things. You got automatic updates,

native menus and notifications. You 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. So 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 an operating system. So there's a thing called the tray API. And each operating system has its own notion of what the tray is.

So on macOS, it's the thing in the top right that has little icons on it. And on Windows, it the the equivalent thing in the bottom right corner of the taskbar so what electron does is give you a one api with um 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 idiosyncrasies of each operating system you're just coming up with a tray interface that can work in all contexts. So I think that for me is the biggest thing in terms of making the hard parts easy. 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 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. So if you want to 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. And you're basically vendor locking yourself in. So what Electron does is allows you to build those similar kinds of tools,

but using technologies that are open. So 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 you have a cross-platform toolkit, like let's take the old one that we can all kind of all collectively roll our eyes at is Java applications on the desktop where they run cross-platform Mac, Linux, OS, or Windows. And they're just so obviously non-native, you know, whether it's they share widgets,

you know, design UI widgets that are cross-platforms that are not native to the operating system or perhaps you have new APIs, for instance, you know, Apple's rumoredly releasing a 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 going to be a brand new API.

And because, you know, Electron and those that came before it are cross-platform tools, you don't usually have access to kind of the new shiny. So you can't make it feel as native. And so I guess the question is, it doesn't seem to be slowing it down any. Like we're still all excited about it. So what Adam and I are wondering is like,

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 just momentum with the web that it doesn't matter anymore i don't know yeah so there are actually lots of apis that are specific to a certain operating system like um what would be a good example so um there's some something related to your computer sleeping um like when a sleep event occurs or a waking event occurs those events are unique to to mac os so in the electron documentation those things are are denoted with a little symbol for each operating system. So 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. So for the example you just gave of the specific keyboard functions, that would be the kind of thing 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. And we have some brave users who are installing the very newest versions of Mac OS 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. So like Jared's saying, these particular features that might be only Mac OS or whatever, you still plan to or at least have some ideas that you will want to implement the APIs for Electron where you don't have to kind of take it 80% with

Electron and then the other 20%, well, you just figure out the native stuff on your own. In general, yeah. I think that's a good blanket 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. And yet out from Atom comes Electron, arguably even more successful than Atom itself, just because it's a platform 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 electron out of Atom, the history there, decision-making, and so on. Sure. So 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.

So 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. So 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 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, you know, when when did Adam's shell become a thing and why? So was it always separate or was it always part? Was it part of Adam? 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 Adam's shell always separate or was it part of Adam? 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 Adam Shell always separate or was it part of Adam and then got separated? So I'm a little hazy on the details for the for a definitive story on the Electron blog. Chang has actually started to publish a series of posts about the history of Electron. And I think he's done two so far. But one of them outlines the very beginning from when he was first working on Node WebKit. And 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. Like it didn't entirely serve their purposes. So they reached out to Chang,

and I think GitHub for a long time was actually just contracting with Chang. Chang was a contractor for GitHub. And I think that's really where the new Atom Shell slash Electron project got some life breathed into it, was because GitHub needed it for it for adam you know as programmers we're always trying to decide the right time to extract to add a layer of abstraction and it seems like and this is a huge successful case when uh what was adam shell and became electron maybe not obvious at first to them but once it became obvious was a huge move and perhaps the

best move they made with regards to the project because like i said earlier electron uh its adoption at this point is probably far subpoena supersedes that of atoms wouldn't you say yeah i actually don't have any numbers on that but um of course, I mean, it's just a, it's a, a more general purpose tool that's sort of lower in the stack. So of course it's utility is, is more broad. I just feel like too, like with the reference to Guillermo and Hyperterm, you know, that it enables, which exactly what it says, if you can build for the web, you can build a desktop app and on the different platforms. I think it's kind of interesting to look at this perspective of these superpowers, essentially, that came out of Atom.

Jared, as you're kind of sharing the story of where Electron came from, where 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, but 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 heart, they 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? Well, I'm really excited about it. I just feel actually my coworker Jessica Lourdes described us this is the promised land, right? We've waited so long to have, like, a legitimate development life as JavaScript developers. I mean, 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. And so now that we have this thing that is a combination of the, the hottest web browser and node itself you know the ecosystem is just flourishing so i actually didn't notice i didn't know that you guys did a um an issue on uh or an episode on hyperterm i'm gonna have to listen to that but i think that's really one of the most it's that project is exemplary of the excitement behind electron in general like just within i mean the project is maybe two months old and we've already seen there's a there's a repository called awesome hyperterm that has just contributed to like

like mad it's like it's really unfold when i was talking to guillermo i thought like you did i thought it was out there a little longer and when i talked to guillermo uh for that show he's like we just released this like a week and a half ago i'm like okay so at the time of the show which we released it on the 29th i think it was recorded a week beforehand uh of july so last month there was around 90 repositories on GitHub that had the term Hyperterm in it that was like add-ons or packages

for Hyperterm. And then during the call, by the end of it, there was another 15 more. And so it just shows you how fast that something like that moves. But the cool thing is enabling that kind of development

because without Electron, it would have been so much harder for Gamma to actually deliver that. I'm sure he could probably have done it, but you just reduced all the barriers to entry. Yeah. No, 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 plug-in or a package for hyperterm it's a matter of publishing to npm so there's not any there's not really a bottleneck for contributing to the ecosystem because there's already something in place that works really well so i'm really excited i actually hit it i've been using hyperterm uh exclusively for about two weeks now and it's got a few little bugs but for the most part it works really well for me but i i had a bug with my uh 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 yeah because i just typed a font name wrong, but actually being able to figure out why I was

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. But just being in an environment that is basically the Chrome browser 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 or any, is there a list inside of GitHub of like, these are the kind of apps we would love to see built with Electron? Like what out there should be built with Electron?

Well, really anything that should run on the desktop. The nice thing about Electron is that, or one of the nice things I guess, 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 demon that's running in the background. So 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 P list 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 with electron. You can actually just it has built in APIs for launching itself at startup. So if you wanted to run some kind of daemon, like 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 that's just for my own amusement. But 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 mean, I think that's really only limited by our imagination. So we're getting lots of really interesting apps coming in on the Electron website. So that's an open source website. And people who build apps can submit them with like an icon and a little bit of a description and link to the repository if it's open source and things like that. So we're seeing a lot of things come in. And it's a mixed bag.

It's not like a specific kind of application. I'd say the most notable apps that are built with Electron are probably Atom, Slack. Slack uses Electron for their Windows and Linux clients. And they're in the process of using it for the Mac client as well. And 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 just a web torrenting, an app for downloading torrents, which is really simple and straightforward. And then I've been using one called SimpleNote, which is created by Automatic, the WordPress people. And 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.

So it's just a note-taking app that kind of syncs across all the devices. My personal favorite Electron app ever is called Mojipar, and it's just an app for pulling up a little search tool for finding emoji. And it's nice because if you don't know the name of the emoji that you're looking for, you can type in a keyword and Ansari will be able to find it. So that was created by Mouan, who works on the design team at GitHub. She's produced some really elegant, simple Electron apps. And 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 nice place to start yeah a good good starting point there yeah it sounds like to me it's it this kind of reminds me of the of the renaissance that's i guess maybe more like the revolution less renaissance that's happening on mobile you know where you have ios that doesn't seem to play well with like web apps right they want a native app and then you got this uh just this renaissance of like renaissance again 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 right like adding a web app to your home screen in ios is not as common as it is on android and so forth 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 allow you to launch it. Yeah. And 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?

And would Electron add more, like we said earlier, does it add more to it than building it in the native web browser? You know what I mean? 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 of the example of Emojibar seems like you could probably go to a website, Emojibar.com, and search for those just as well. Why make it in the system tray you know so interestingly uh moji bar has a website counterpart part which is called emoji search.info or something like that i can't remember it offhand but um for me it's about um

productivity so it's a lot easier for me to invoke a keyboard command that opens the emoji bar search with the thing emphasized, and I don't have to make any network requests. So 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 or an issue on GitHub, and I want to use an emoji. I don't really want to open a new browser tab, type in a web address, focus the input, search, click. So it's really just about being able to move more adeptly or get things done more adeptly, especially with, like, keyboard shortcuts.

So in the case of Mojibar, really, it's just about the convenience convenience and the speed this is making me think i mean on the same note here i mean it's jared i don't know if this is appropriate for the show to dream like this but it's really making me think like that the changelog could potentially have you know something to do with electron and ship a version that essentially just easily adds like 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 is or the many shows we have coming out is a key command just like zk just

said and now you can access your playlist and put 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 like that type of behavior using Electron. Yeah. I mean, I think that changelog would be a great candidate for that. So if you have these episode files, which are, I don't know how big one is on average, but you know, a considerable number of megabytes. Yeah.

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 mean, i think anybody who has a

website that is web app-ish you know i'm sitting here using google docs thinking you know this kind of reminds me of the days of fluid and the other tools adam back when we used to wrap you know 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. And I guess my question around that, obviously for changelog, we could build an Electron style changelog thing that ships as an app, but does it give you the, like, does it let, does it empower users or just app developers?

So I love Google Docs. And so could I build with Electron, you know, a desktop version of Google Docs without having to run Google Docs itself? Can I wrap it and provide some integrations with my, yeah? Yeah. So the really easy way to do that would be to use a tool called Native Fire, which is kind of a weird name, but it's essentially like Fluid App, but it's an electron thing and it's a command line tool where you just call native refire 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'll be executed in the window context of that app. So 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 behave differently. Like you don't want to see the menu bar at the top of the screen. So you could just write a tiny little JavaScript that is like, you know, document.find this element.remove this element. So you have a lot of flexibility there, and you don't actually have to do a lot of work. So in that case, you don't really need to know anything about Electron. If you know a little bit about how to work with the dom and like um if you want to drop in jquery or whatever um that's all doable so that's like the easiest way to do it but if you want to go 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. So 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. 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 farther. I've done I have a couple of them that I run for. Like I have one for inbox Google, like Gmail inbox that that I use just to keep it so I don't have to have a pin tab in my browser.

But I think it's 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's it a bad idea to use? Those kind of things. So we'll break here and we'll talk email called ChangeLog Weekly. It's our editorialized take on what happened this week in open source and software development. It's not generated by a machine. There's no algorithms involved. It's me. It's Jared. And curating this email, keeping up to date with the latest headlines, links, videos, projects, and repos.

And to get this awesome email in your inbox every single week, head to changelog.com slash weekly and subscribe. All right, we're back with Zeke talking about Electron and 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. Let's talk. That'd be super cool. Let's talk. That'd be super cool. Let's talk about the downside of like, let's talk about a little bit of places

where maybe Electron doesn't quite fit in or it's not optimal cases where somebody might pick it up and then say, Hmm, this is not the tool for the job that I need solving. So Zeke, I know it's tough because you're, you're an Electron guy, so you got all the good sides, but surely there's some places where it doesn't quite fit. Can you share some insight there? Sure. So the biggest one that stands out to me is that Electron doesn't work for making mobile apps.

So that's one of the questions we get a lot is like, why doesn't it support mobile? When will it support mobile? And the best answer we have for that right now is, you know, 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 could be used by your mobile app and your desktop app, or you can write small NPM modules that can be shared between your applications. So 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. I mean, 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, in general, Windows developers are underrepresented. So a lot of the web development world is focused around Unix

and Linux kind of methodologies. And there's an expectation that you can run bash commands on your machine. So 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 underrepresented part of the developer community now. I would imagine that Microsoft with their Visual Studio Code project would probably be able to help out or at least be a good you know citizen

with regards to getting you guys windows bug reports or help that have you experienced that at all yeah there's a guy named felix reisenberg or reisenberg i'm not sure how to say it but he just uh he was at microsoft for a while and just very recently uh moved over to work at Slack. And he's been really one of the sort of foremost evangelists for Electron in the Windows space. And 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 well so things are definitely getting better and we do have access to people who um work for microsoft or work on microsoft platform but um 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 y'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, and then give us a glimpse into the future for the project. Sure. So Electron gets shipped about, a new 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, you know, sort of idiosyncratic little pieces of changes on various operating systems. It's mostly stuff around native integration, like the way that trades behave or the way that windows behave when you fullscreen them or take them out of fullscreen 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. So 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 want to publish for those platforms. Like if you're publishing to the

Mac App Store, you can't use the auto updater, or you can't use the debugger, 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 is 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. So traditionally, if you wanted to start building an Electron app, you would npm install Electron prebuilt, which is just a precompiled version of Electron that is the right one for your operating system.

So 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. So 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 user land to patch various popular projects so that they will work with either name. But the hope there is that newcomers to the project

will not be dumbfounded when they NPM install the wrong 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. You didn't have your lawyers kick down the door. That's so funny. Yeah, we actually did the same thing with the GitHub. So 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. Those GitHub hoodies are quite lucrative. 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. So 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. And it's kind of open-ended what the purpose of that is for. Immediately, the immediate purpose is just to have some kind of specification for our APIs. And 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'll auto-suggest the right method names and arguments and things like that.

And 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 going to be up to date. 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 it's built in, well, it's actually two different code bases. So there's the Windows version and the Mac version, and those were sort of worked on and maintained by two different teams at GitHub.

And 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. So 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 but um yeah stay tuned for um a new version of github desktop at some point i'm not sure when it's expected to

be um opened up but it will also be an open source app so um when it's when it's ready so the hope is that that can be a nap 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. And, uh, so Josh Abernathy who runs the team was just had a recent tweet stream about, uh, or tweet storm about how, how awesome it is to be working in this, um, 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 coco developer and that never would have been able to move this quickly wow developing in coco so so is this application is it kind of a a feature 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 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. So gotcha. I think the lot, the larger,

the longer term goal is for this tool to be something that allows for deeper integration into the desktop environment for GitHub. So it could also become the sort of blessed way, the canonical way of setting up GitHub on your machine. So 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. had the pleasure of Electron obviously with it being a starting point but then also to look at other areas of github where Electron can be used and then dog voting is always good because if you continue to build the desktop app natively versus Electron we might say hmm why are they doing that but we're

not gonna do that because that's not the truth yeah let's talk for some closing questions is there anything else you want to share before we cut to that part of the show? Anything else you want to 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 on Chromium, it's like you don't have to think about all those things. So Chromium has nearly complete ES6 support. So if you've 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 tool chain. You can just write ES6 and it works. The other thing is like, there are a lot of really interesting new CSS features coming, or actually they're already in existing versions of Chromium and Electron. So one of them is CSS properties,

custom properties. They're like, if you're familiar with variables from Less or Sass or Stylus, it's essentially the same thing. It's, you can declare a property in your CSS style sheets and reuse it in various ways. So super cool. Yeah. So there's like all these little things that are making regular CSS and regular JavaScript good enough.

So you don't, the, 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 Lesser 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.

So 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 frame rate out of the DOM. So 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, right? The less time we spend redoing work or reworking things that has already been done before, or jumping right to ES6 with the latest features of CSS, the better it is for the ending product that we deliver to end users. So anything else you want to share? Is that it for your list, or can we go on to 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, like 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. And we're huge fans of all the work happening there. But you've got to be asked all the time, like how can people of the open source world, how can developers step in and help the Electron mission?

So is it issues? Is it testing builds? Like 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? So one of the things you just said is what we've dreamed it should be and help that mission keep moving forward. So one of the things you just said is what we've dreamed it should be. And we've 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? And 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 so we shouldn't be like masterminding the future of this thing and in some sense it should just evolve organically and that's how it's been going so far so most of the work we're doing is doing is just kind of stewarding the community contributions and helping get more and more contributors up to speed. But 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. But another one is translations. So 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. And there's a huge collection of translations in, I think it's 11 languages now, and over 100 people have helped us translate the docs into those languages, but they fall out of date. So anytime we make a change, it's not

guaranteed that anybody's going to jump in and update the English docs to work on those 11 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 a version, various translations up to date to a degree that we're comfortable displaying them on the website saying that yes this is definitely accurate. But in the meantime, yeah, just community contribution on documentation would be really helpful. So the docs are actually part of the

core Electron repository, right? So you got slash docs, everything lives in there. So if you need to make changes or initiate some changes, that's the easy way to do it there. You've got the blog where you're obviously keeping people up to date. And I think you mentioned some other ways to kind of 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, you know,

help need or to 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? Yeah, we do definitely use some of those labels. And thanks for outlining where the docs live. Yeah, we definitely keep the repository as the canonical source of all the documentation in the docs folder. And the website, the majority of the content on the website is actually just repurposed

from the repository 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 it's in 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 anytime soon. But 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. So is that and then I also see a lot of beginner labels attached with documentation, too.

And even enhanced. And is that are you familiar I also see a lot of beginner labels attached with documentation too. And even enhanced. And is that, are you familiar with that label by any chance? And is that something that I also see help on it too. So I've only seen one of those I think is under help on it. But those are two labels I think are kind of like easy jump in points. Yeah, definitely. Yeah, there's like one, I don't know. There's more than that.

Anyways, 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. So 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, I mean, 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. And another thing is, you know, 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 want to change. So 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. And 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 Max Ogden on GitHub. And he's one of the early sort of 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. And it's basically, you know, he was creating so many repositories and eventually there's only so much that one person can do

to maintain these repositories. So he started handing out admin privileges to anyone who was making meaningful and valuable contributions to his project. So the idea behind open open source is if someone's 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. And 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. So 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. Max Ogden was a very, very early contributor to a lot of Electron projects. So 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 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, Mathintosh Matias Boos, I think is his name. They wrote that. And they also wrote another thing called Electron Packager, Electron Download, a bunch of different parts of the Electron ecosystem. And GitHub, our team, 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. So Max is now working on a project called DAT.

And the goal of DAT is to enable scientists to share data with each other. So that's been his main focus for maybe a couple of years now. And he's mostly been focusing on raising money to build up a team for this nonprofit to enable scientists to share data. And 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 Commit. You may have heard of it, Zeke, but the listeners are definitely getting more familiar with

it. We've got three episodes out. As of Friday, we'll have four when this show actually airs. So we actually had Max on in episode, I believe it's six, which is slated to release in the month of September. So September 1st. And we talked about that and we talked about not that set in slang, but that is 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. So Max has been very successful with getting and receiving grants and actually executing them very well.

And that's one of those things. And talk deeply about that project and about the human side of open source, not so much the technical sides of that by any means, but this grant funding process, leading open source in the right direction. So if you're at all a fan of that, listeners, you know, we love requests for commits. That show is hosted by Nadia Ekbal and Michael Rogers, and you can find it at changelog.com slash RFC. If you have not subscribed yet, please go do it right now. And September 1st is when Max's show comes out and it's going to be awesome. So perfect. Thank you for the perfect layup on

plugging request for commits because that's it couldn't have been any better i really appreciate that um anything else any last closing thoughts before we tell off the show i just feel really lucky to be working on this project and um to be part of something that people are so excited about i feel like 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 early in the show and, uh, you know, having that designer background, but also the, the responsibility you've gained over these years on the developer side to deliver such a, a cool thing to impact such a large community,

I think is, has got to be emotionally rewarding as well as, you know, just rewarding in general as, as something you do every day. And that's, that's a cool thing to do. Yeah.

I mean, just to be able to work on something that I really enjoy and get paid for it, that's what more can you ask for? Nothing else. That's it, man. That's where you want to 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 of the community saying that this isn't, you know, while it's created by GitHub and maintained by GitHub, it's not a GitHub only steered thing that you invited the community to dream with you and to influence that change, step in where

they can to make Electron what the community needs it to be. So I appreciate you having that direction. And listeners, we thank you, obviously, for listening to the show. We ship two emails every week, one daily, one weekly. And we actually didn't call it daily. We called it nightly. So if you go to changelaw.com slash nightly. And Zeke, you're a fan of this email, right?

You like the white 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, uh, you're a fan of nightly. So any, any quick sentiment on nightly for the listeners to, to, uh, chew on for that? Yeah, it's just a good way to keep up on things that are happening on GitHub every day. We love GitHub, of course. So, uh, changewell.com slash nightly for that email, subscribe to that. And, uh, Jared and I, we work tirelessly changelog.com slash nightly for that email. Subscribe to that. And Jared and I, we work tirelessly all week long prepping for weekly, which is what we call ChangeLog Weekly. You go to changelog.com slash weekly.

Subscribe to that. It's our editorialized take on what's happening this week in open source and soft development. Our latest shows are in there. We do a lot of writing, painstakingly writing that email every single week, and love doing it. So please subscribe to that, but that's a, that's it for this show here. So let's call this one done and say goodbye. Bye. Thanks again, Zeke. Thank you next time.