This course is out of date and does not reflect our standards or industry best practices.
Transcript from the "Electron Q&A" Lesson
>> Steve Kinney: Questions, comments, concerns, cries of outrage?
>> Speaker 2: You've covered some of, and the website shows the big use cases, the famous ones.
>> Steve Kinney: Mm-hm
>> Speaker 2: Is the slacks and the VS codes and so forth. On just a more local or grass roots-y professional level, what do you see being valid use cases for desktop software as opposed to web software that you're actually, maybe, seeing?
>> Steve Kinney: Yeah, one of the ones that we use internally is just, mostly, internal because, you ever have one of those projects where it takes 20% of the effort to have a thing that you can share with your friends, and 80% of the effort to polish it up the rest of the way to actually distribute to the world?
[00:00:46] That's a few of them. So, we have one internal that we all use. And effectively, when you're writing markdown files you want to include an image, well do you put that in the directory? So on and so forth, right? It's a pain in the butt, so we have one we just drag an image, you put in your own S3 key and stuff like that, it goes up to your bucket and then you get a URL back that you just paste right into a markdown file.
[00:01:08] I think a lot of, there are these big ones, but I think the number of small tools that you can just build, I have one we have a far too elaborate system of labels of poll requests, right? So, one of the ones I'm working on right now is simply a way to, as I move cars across a Trello board to, okay, this is now code reviewed but needs comments.
[00:01:28] Because you know in GitHub, how request changes and how mean it is so nobody uses it, so it doesn't do anything because it's red, and the big X, and stuff like that. So it can be like, more feedback needed, or work in progress, so hooking up to the GitHub API, and, just, having a user interface, so everyone can just basically throw in their cues and do something with, right?
[00:01:46] There's a lot of times, not having to actually, have, just using the AWS CLI or libraries cuz they're is a Node 1 under the hood, right? Just makes it easier to automate a lot of things, right? Especially internal things where getting, I can run these things from the command line, I just need a easier user interface for these things.
[00:02:08] I don't want to spin up an entire web app that I have to get through infosec. [LAUGH] Right? I just wanna, the same way I'd run this on the command line, I just want a slightly better tool, cuz I think a lot of those, I think are really useful.
[00:02:19] One of one I really love is this from a few years ago, my friend was working on this Kickstarter project called The Public Radio, which is a mason jar with a little Arduino in it, and it's effectively, you can tune it to one radio station, right? I assume that if you have a mason jar radio, it's tuned to NPR.
[00:02:39] But thing is, NPR is a different station wherever you are, right? And so, it was a node bot thing with Arduino and no JS power in it. But asking someone to plug it into the USB of their computer and have node installed, and run these commands in the terminal was unacceptable, right?
[00:02:59] So it was a lot easier to just make a quick Electron app that did this, ran the same node commands and did all of the same stuff, but with a user interface where someone could just download the app and double click it. I'm, personally, I think the big apps make a lot of sense.
[00:03:11] And if I was starting a startup, obviously, I wouldn't have the team for a Mac app, a Linux team, and a Windows team, right? We'd be writing, probably, an Electron app. But what I'm more interested in is the small bespoke ones, right? There was an emoji picker, right, where you can just type all the GitHub ones and get them as Unicode things.
[00:03:32] There is a bunch of really small applications that, I'm more interested in the little mini ones that kinda spring up. Again the, I have this idea for an app that I could totally build, right? Again, maybe you don't take it all the way to the fact that we're distributing on the app store, right?
[00:03:46] But it is a thing that you use or your team uses or stuff along those lines. I think that's a really interesting use case that's more inspiring for me than the next ID that we're all gonna build or something like that. I think all the smaller, for us, we're used to being able to build whatever tools we need, right?
[00:04:02] We have, a lot of us have front-end jobs, most of us can get around in Node or something like that or at least write a bash script. But if we need it, a desktop user interface, we're kinda out of luck. [LAUGH] Right? It was just, learn Swift or C sharp or whatever.
[00:04:17] But now the fact that I can just spin up a thing, opens that last door for internal tools, which is where I'm the most interested in it.
>> Speaker 2: How is pushing updates handled, then, at that point? If you do updates to your code, how do you push that out to the rest of your users?
>> Steve Kinney: So, really nicely is, that is not a web browser, despite what one might think, is this is a, just like we saw crash reporter, the only reason we didn't dig deeper into autoUpdater is because it does involve code setting. AutoUpdater, basically, is, again, you spin up another server, and every time it starts up, it pings that server with its current version, and depending on the status code it gets, it will go ahead and try to download the new version.
[00:05:06] I think a 200, don't quote me on this. The 200 will be like okay, we have the conversion of 204 as a new version. I could have that backwards. But basically it will check that every time and go ahead and pull down that application and install it. And in fact, just a month or two ago, if it is an open source app, and you're willing to use GitHub releases, they actually have a full auto-update service.
[00:05:36] So you don't even have to run your own server. Let me see if I can find it real quick. Yep. Easier auto-updating for apps here is basically, I believe it's update.electronjs.org, or something along those, Yeah, update.electronjs.org. And so you can pull in this MPM module [INAUDIBLE] Electron update app.
[00:05:56] You basically use it, and it uses their service to handle all the pushing updates for you. So you don't have to worry about that. If it's closed source and pushing your code to another party is not going to really work, however, it's private you gotta figure that stuff out yourself, but I have, the the amount of servers I'd code to push out updates is pretty tiny.
[00:06:22] It's, again, this status code. And then you know the URL for where I should pull the newest archive from, right? And it'll pull that down, it'll un-zip, it will use Squirrel to basically, this is saying, scroll and then Sparkle, I think is the Mac OS one. Please don't quote me on this.
[00:06:43] Basically, that same annoying, there's an update from this app that you see from every app, that is an open source tool. And it is built into Electron. And, basically, it does the switch in place. So it's like, install and restart. And you install and restart and you get the newest version of the box.
[00:06:59] Slack obviously uses the Mac App Store. So it's another way to do it. I don't know how they do it on Windows and Linux, but I'm sure they either use Squirrel, slash, Sparkle and stuff like that. So there's a bunch of options out there. Most of them are either open source, or so proprietary, like the Mac app store, it's taken care of for you in that sense as well.
[00:07:22] But yeah, you just need to like do all the certificate stuff and code sign it.
>> Speaker 2: It will just take some research.
>> Steve Kinney: Yeah. And like ideally with Electron Forge they're like, there's a little bit of hand-waving. They're like, set up CI that runs the build process on a Windows, on a Linux, and a Mac machine and code signs it for you, right?
[00:07:41] I am most experienced doing the code signing on Mac OS. Once you've done the code signing, basically in Electron-packager, you go in and you do, once you set up [INAUDIBLE] That's running on that computer, you do OSX-sign, and that will code sign them on built. I think it's a little trick here on trick here when it's in Linux and I don't have that enough memorized to speak and go, it's super easy.
[00:08:07] It's a thing, so yeah.
>> Speaker 2: One of the other questions I had, I was just reading a Reddit thread, which is dangerous, I suppose, but-
>> Steve Kinney: Mm-hm.
>> Speaker 2: They were just saying that one of the things about natives apps versus, maybe, Electron apps is that they're very memory intensive.
>> Steve Kinney: Yeah.
>> Speaker 2: I'm just wondering if that's just because they're not running on multiple cores, if it's just, there are multiple threads, but-
>> Steve Kinney: I mean, Chrome, itself, is not known for being polite to your battery, so now imagine running four Chromes.
>> Speaker 2: Yeah.
>> Steve Kinney: Right? It's not like Slack, and Adam, and Visual Studio code share the same Electron heart.
[00:08:51] They are all their own individual versions, right? So they're pretty large files cuz you're shipping all of Chromium, and all of Node, right? They are not particularly memory happy, right? Slack is usually the app that is pegging my CPU. Now, I don't know. Visual Studio Code feels great to me, but I know that for a while, and this might not be true, I don't use Atom anymore.
[00:09:13] But for a while Atom was a little rough, right? And so, yeah, there are tradeoffs, right? Yes, you can write web technologies to ship on multiple platforms, but it's not gonna be as small as a Swift bundle is going to be. It's not going to be as memory efficient, either, right?
[00:09:28] And that is, unfortunately, computer science. We make these trade offs, and you got to make a choice is the productivity or the fact that, especially if it's an internal tool, you are never gonna sit down and learn C sharp today, right? This app either didn't exist or it exists on Electron and maybe it's not super memory efficient.
[00:10:16] My suspicion is that in a year or two years, a lot of that stuff will get handled. I'm sure the Chromium team doesn't like the fact that they're using a lot of memory, right, and stuff along those lines. It's like, generally speaking we optimize for popularity. It's not that optimized things become popular, right?
[00:10:34] So my general thing is, what makes you the most efficient? And this is kind of the rails philosophy. Like rails is not the fastest framework in the world, but the idea that developers are more expensive than more servers, I think makes sense. In a certain sense. Yeah, I'm not gonna lie to you and say they're particular memory efficient or small in size.
[00:10:54] They're not, right? But the application might not exist. Now, we should argue, should Microsoft be linking bespoke versions of VS code for every platform? Yeah, they're Microsoft, sure, right? Slack, maybe, too. I don't know. But for the internal application you're gonna build, or something along those lines, right?
[00:11:11] It was either probably not going to happen or is gonna happen in Electron. That's my view on that. And that's it. Thank you so much.