The Changelog: Software Development, Open Source - npm Origins and Node.js (Interview)

Episode Date: August 22, 2013

Andrew and Adam talk with Isaac Schlueter about the origins of npm, building an asynchronous web with Node.js, and how to get paid to open source.

Welcome back, everyone. This is The Change Log. We're a member-supported blog and podcast that covers what's fresh and what's new in open source. You can check out the blog at thechangelog.com and our past shows at 5by5.tv slash changelog. This show is hosted by myself, Adam Stukovic, and also Andrew Thorpe. Hey, what's going on? I didn't ask you to say hello this week, did I? No.

I'm winging it. Kind of threw you off a little bit. Yeah. We're always winging it around here. So to wing it even further, you can tune in live every Tuesday at 5 Central Standard Time. We're here on 5 by 5. And this is episode 101. And we're joined by Isaac Schluter.

He's the maker of NPM. He's the core maintainer of Node, and he's also a JavaScript hacker, obviously, at Joy-In. Welcome to the show, Isaac. Thanks. Happy to be here. It is. And it's been a while since we had this topic on the show, but before we dive deep into this conversation, we have a sponsor. Yeah, so real quick, I want to give a shout out

to Pete Keene for sponsoring our show today. He has a new e-book out there called Mastering Modern Payments Using Stripe with Rails. We use Stripe at the changelog. Who doesn't, right? And his book aims to help you with topics like why a simple 10-minute integration isn't enough, dealing with security, including PCI DSS,

Stripe JS, Checkout JS, subscriptions, marketpeJS, CheckoutJS, subscriptions, marketplaces, testing, and more. It's a great resource for Rails developers that want to get started with Stripe. For $29, you get the guide, which includes 116 pages and 100 code samples. For $59, you get the source code as well. And for $299, you get a team license so you can share it all with up to 50 team members. Check it out at PeteKeene.net slash mastering hyphen modern hyphen payments. Thanks a ton to Pete for sponsoring today's show. Absolutely, man. We love Stripe, man.

I absolutely love Stripe. Yeah, I think a lot of developers are kind of heading that way. It's so easy to use, and it integrates with everything, man. Jeez. Well, cool. Soates with everything, man. Jeez. Well, cool. So we've got Isaac on the show. Isaac, I hear you know something about Node. Yeah, so I've been working on Node pretty much since there's been Node,

not quite as long as a couple of other people, but I think as far as people who are actually involved in the project still, I'm one of the oldest. Why don't you give us an introduction to who you are and maybe who Joyent is and what Node is? Sure. So I actually was kind of involved with doing some stuff with server-side JS. I was a PHP developer prior to that and got more and more annoyed that I had to write

one language on the client and another on the server. And even more annoyed that the server language was not JavaScript. So I got started kind of messing around with, you know, SpiderMonkey and WebCore and JSCore and kind of like trying to figure out how to do something on the server. But I didn't actually know what I was doing. And around that time then, Google open sourced V8. And so I started playing with that. And lo and behold, this new thing showed up on the scene called Node. So the website looked really nice, and it seemed like it had a really nice api so i i you know downloaded the source

code and tried to build it checked it out from git or whatever and it didn't compile so i was like okay well this is obviously not real and never gonna go anywhere um and so i kept playing around I got kind of into Narwhal and the CommonJS stuff and then somebody I gave a talk at a meetup at Yahoo about using JavaScript on the server and you know some of these

ideas of CommonJS and the module pattern and this kind of stuff and somebody in the audience asked me if I'd ever heard of Node and kind of nudged me to go take a look at it again. I don't remember who that person was, but I'm sure it'd be nice to know who that actually was. I wonder if they're still involved with Node.

So if they're listening to this podcast now, get it done. It's at IZS on Twitter. Yeah, I think it was also one of the first projects. He pointed me at something that was one of the first projects that I ever used, a.io domain. I don't think it was Socket.io. I think it was some other like IO thing. And it was built on Node.

And so I took a look at it and I downloaded it. That was version like 0.0.6. And so that was the first one I tried that actually compiled on my Mac. And, you know, I, I immediately basically stopped what I was doing and said like, okay, this is, this is the right way to do it. Um, this is the one that I'm going to actually focus on and play with. And so, um, yeah, I was kind of hooked. And I mean, there was this, this dude in Germany had written it, this like Ryan doll guy. And then a couple months later, this video came out from him giving a talk at NodeConf EU. I knew he was going to be at NodeConf EU. I knew that he was, you know, I knew him from the IRC channel and stuff. And we'd been

sort of chatting and whatnot. And then when he, when I saw his talk, the video, I was like he was, you know, I knew him from the IRC channel and stuff, and we'd been sort of chatting and whatnot. And then when I saw his talk, the video, I was like, oh, wow, like he's not German. He's American. So that was kind of like a big shock for me early on. Everybody else was shocked by that video because that was when most people, I think, found out about Node. That's kind of the big coming out of Node as a project and being presented to the world. So, uh, yeah, you know, I was really active in the mailing list and stuff and, um, just, it was very, very small community, very tightly knit.

And, um, I got kind of sick of, uh, working at, at Yahoo and, and just being at a big company, got kind of fed up with it, so I quit my job and spent two months just messing around. I was like, I'm just going to take a few months off and see what happens. And what I found was it was really frustrating on the mailing list because people would post these things where they would post this announcement that they wrote some new project in Node, some new reusable module in Node. And, oh, God, it was always such a pain. It's always like, okay, so here's what you do. You download this thing, and you run make, and then you copy this file into this folder, and you also have to copy this other file because it depends on this thing,

and it has to be this certain version, and it's always a get submodule, so you have to do get submodule update. And I was like, oh, God, this is just a nightmare. And in the four years that I'd worked at Yahoo, there's this really cool tool called YNCE. So you just type YNCE install whatever. It fetches all the dependencies. And it's a really nice sort of platform

to actually build your programs as well as distribute and install them. And it's very low bandwidth, low barrier to entry. So I kind of took some of those ideas and set about writing a package manager for Node. There was a couple of other options at the time. TJ Hollowaychuck actually wrote one called Kiwi, which was written in Bash and had a very, very pretty interface.

It's sort of like stereotype of TJ Hollowaychuck's stuff. It's always extremely, extremely polished and pretty. The thing that bugged me about it, and there was a couple others too. There was a few that were based on Git. There was two actually that I remember that were based on Git and used that as the transport mechanism, and a couple of others. And the thing that kind of bugged me about all of them was that the path to publishing

something was much, much too difficult and usually relied on either you telling everybody the, you know, the Git repo that they need to go and install or you have to um you know you had to have somebody merge in a a patch to add your thing to the to the registry of published modules and i thought this is just this is too hard so i set about basically take i took a couple months and basically wrote what ended up being NPM. And the premise of it was to basically not require any unnecessary ceremony from writing your project to actually having somebody install it. And because I had no job at the time and nothing really to do, I went around and sent pull requests to every Node project to add a package.json to them.

That's a good way to do it. Exactly. And I think the main reason why NPM ended up being the package manager everyone uses is that I didn't have a job then and everybody else did. And so it just had somebody kind of through force of will sort of pushing on it to get the community to use it. And it's a very easy – as you know, if you've ever gotten a pull request to add like a Travis CI or something, it's very easy to just say like here's one file. It's not going to be in your way. It's like one file you've got to put in there. It's short.

It's easy to read. Just accept this pull request and the world will be better um and and people very for the most part were very accepting of that because there wasn't a lot of things doing that i mean nowadays now that you have package.json and component.json and some yml thing travis yml and like some other thing it it's you, it's starting to, along with like your license, your readme, your gitignore. Yeah. So now people are a little bit more, uh, resistant to this sort of thing. But at the time it was, it was a very easy sell. So let me interject here real quick that we'll talk more about, you know, all this stuff,

NPM and all that, but it's, it's kind of striking the similarity that node and with NPM has had, like with, you know know my experience in the ruby community with ruby gems coming up and uh how much of npm would you say was influenced by you know ruby gems and just that whole environment uh roughly zero and that's not to say i mean that's not to say that they're not similar because like the similarities have been pointed out to me a lot of times but i i have almost no experience with Ruby. I've edited a few Ruby programs just because they're kind of out there, and it's kind of inescapable, right? It's just a very popular platform. But no, I think it was mostly influenced by wanting to not be pair.

Right. And wanting to kind of emulate what I saw work for Wyanst. Yeah, I mean, it's cool. I've heard, I actually listened to, I want to say it was the Node podcast that you did with two other guys, and I was listening to the first episode, I think. This was months ago. And I remember you guys were just kind of talking about how, you know, Node is, it's obviously very young

and it's kind of following in similar tracks as other, you know, modern technologies have gone. And it's always been kind of shocking to me that, you know, it's not exactly the same and the pitfalls, you know, don't look exactly the same, but you kind of have to go through the same growth problems as, you know, just package management in general is a common growth problem that these and the pitfalls don't look exactly the same, but you kind of have to go through the same growth problems as just package management in general is a common growth problem that these young frameworks have to go through. And I don't know, it's kind of striking

that they all go through the same ones. Yeah, yeah, absolutely. And I mean, the big question is like, can you evolve past those problems or not? Yeah. I think as far as like, you know, if you look at, I hate to pick on pair, but at the same time, I obviously don't hate it that much because I do it a lot. Right. Yeah. dead. Now, thankfully for the PHP community, like the PHP community as a whole wasn't really too dependent on it. And you have stuff like Packagist and Composer coming up from, with more of like a

RubyGems MTM kind of model. So it's very low, low barrier to entry and a small amount of ceremony to get started. Right. So you talked a little bit about just, you know, how you came about with NPM. So how did the, uh, I, I kind of stopped you. So if you want to keep going about just kind of how that, that brought you into the, the node JS community as a whole, and then where joint came about and all that. Sure. So, um, so I'd been a jobless for a while and, uh, got this job working for this company doing this stuff that wasn't really related to Node and kind of disappeared off the map a little bit off of that group. And I was frustrated. I wanted to get more into Node and do something that's more Node-specific.

And I was thinking about starting some kind of little startup or whatever with a couple of guys. And I mentioned this to Ryan. And he said, no, no, no, no, no. Don't do that. Come work at Joyent. You'll have health benefits and like a salary today. And I was like, oh, well, yeah, okay. Yeah, and that was basically my job interview.

And then I came here and started working on, on node and NPM, um, had joint. And you kind of have the dream job though. I mean, cause I mean, how many people are listening to the show right now, hacking on open source that would love to hack on open source and get paid to do it? Yeah. Well, that's, I mean, that's a fascinating subject actually. I think, I think a lot of people get, a lot of people really, really like working on open source. I think there's a lot of intrinsic motivation that really drives us to write software and write really good software and focus a lot of care and time and attention and feel very rewarded by this. However, the financial incentives often just aren't there. And so, yeah, I do have a dream job. And it would be really nice if there was, you know, ways for other people to be more, to do this as their job, you know, it's, it's

definitely a passion of mine and something I hope to maybe one day figure out some way out of but so just to paint this picture a little bit for the listener. So you quit your job to work on open source, then got a job to work on open source. Yes, which is good because I couldn't do that forever. At some point, I was going to have to do something to make money, and sending people pull requests to add package.json files to their projects wasn't really paying the bills. Well, in a sense it was, though, because would you say that the success of NPM is kind of, well, I guess a better way to put it is when you came on to joint full-time to work on Node full-time, was NPM mature at that point to where it was the primary adoption for package management in Node? Oh, yeah, yeah, that was well established at that point.

Yeah, so if you think about it, like all those long nights of submitting package.json pull requests probably was paying the bills in a sense. Maybe, yeah. I mean, I think it is a good case. Yeah. It is a good example of, you know, if you do something that you're really passionate about,

I think it's a misnomer to say that, you know, it's not exactly true to say that if you do what you're passionate about, the money will come. But if you do almost anything really diligently, then the money will come. And it takes passion to have that kind of diligence. And a lot of things, like if you do almost anything really diligently, you'll figure out what parts of it you like and what parts of it you don't, and that'll help inform your choices when it comes to choosing a job or doing another thing. Right. So why don't you kind of give us an overview of just what Node is. We haven't really talked about that yet.

Oh, yeah. Sorry. So Node is a platform for writing asynchronous I.O.-based servers in JavaScript. I think the tagline is evented I.O. for V8 JavaScript is pretty straightforward. It uses the V8 JavaScript virtual machine as its way of running your program. But the nice thing about JavaScript is it doesn't actually have a built-in IO mechanism as part of the language. So whereas in Ruby or Python you have this standard library which has predefined mechanisms for reading files and stuff. In Node, or in any JavaScript program, there's a lot of stuff for doing loops and functions and what have you, but there's no way to write a file in JavaScript. Node also links to a library called libuv, which is an abstraction for doing asynchronous I.O. or non-blocking I.O. across different operating systems. So, for example, I always get wrong, like which ones have which.

So in the Unix land, there's stuff like KQ and EPOL and so forth. In Windows, there is IOCP, IO Completion Ports. And so libuv is like a bridge across these two or three or actually four very different worlds of ways of doing I.O. in a non-blocking way. So let's explain what non-blocking means. old random program, like a C program or a shell script or what have you, you open a file and you call int fd equals fopen and you give it a path name, right? And that open call, that open method will return the file descriptor. Then you pass that file descriptor to a read operation and that read operation returns, well, and see operation returns the number of bytes read. But let's say in a higher-level language,

it would just return you a string or a buffer of some sort representing the memory that it read. Well, the problem with that is that if you have a server, like an HTTP server, its job is to be serving requests, right? Now, most of the time when you're doing a read operation, you're just kind of sitting there waiting for the hard drive controller to respond. Or if you make an HTTP request, right, you send the request out,

and then you sit there and wait for the packets to get sent over the network, and then for the response to get sent back. And there might actually be multiple packets you have to receive before you can parse out the full HTTP response. So if your program is sitting there doing nothing, you're not serving new requests. And you're not actually, you're just kind of blocking on CPU, you're not actually doing anything. So Node's approach to this is a little bit different. In the case of where you make an HTTP request, what you do is you get back a request object from that HTTP request. And every time there's new data available, then when the response comes back, you pass it a function. That function gets the response object. Now every time the response object gets another chunk of data,

it's a data event. So you attach functions to these things in order to handle this stuff at some future time. In the simplest case, if you do like fs.readfile, you pass it the name of the file and a callback to get, which will get an error or the data at some future time. And so then this is like the callback hell that you've heard people talk about where you have one thing that calls another thing that calls another thing that calls another

thing and your code keeps indenting because you keep defining new inline functions. It's kind of a novice problem, but it does require you to kind of invert your thinking about how you do I.O. The blessing and or curse of Node is that you can't just ignore things that take a long time to do. So let me ask you, early on in Node, I kind of got, no, not early on, but early on for me in Node, I was on the mailing list. And I would start to see these arguments. And you just like – I hear buzzwords, and I start to see these arguments about callbacks come up. And I can't remember. I think it was like pipes and streams and callbacks and all that.

So you obviously know what I'm talking about. So elaborate on that a little bit when you, when you talk about callbacks is that, I guess just elaborate on what, what's the, I don't know, the, the, you know, the, um, standard way, the right way, the, uh, you know, how do you handle this stuff? So this is a trap. Um, there's, we can edit it out later. No, no, it's okay. It's okay. It's a trap I'm familiar with. So there's two answers to this.

There's Isaac, the person, the programmer, and what do I prefer, and then there's, like, what is the official stance of the Node project. Right. And they're not exactly the same. So basically a callback is just a function. It's a function that you pass to some other method that will be called with the results of that operation. In scheme, this would be called a continuation.

And actually, in scheme, the semantics are completely different. So if you call callbacks continuations, then certain people get really upset. Yeah, they get beards on their necks, parentheses all over the place. And oh, goodness, I'm getting an email. So anyway, a callback is just like a thing to say, okay, I want you to go read this file. And once you're done reading that file, put the data in here and then go do this other stuff. In the meantime, I'm going to go do these three other things. So you get into this situation where, like, okay,

I don't actually just want to read a file usually. I want to read a file, then I want to upload it somewhere, and then depending on the status result of the upload, whether it gave me a 2.0 whatever or a 4.09, I want to go do this other thing and read this third file and parse it and then send the results over here. Right. So if you're doing this all with a callback based system, there's a tendency to, well, you, in general, there's a tendency to put too much code in one place, right? That's kind of a universal thing. Like factoring out programs is hard. Right in node this hard this difficulty is readily apparent

because you end up six levels indented and suddenly your your code is like all the way off the right hand corner of your right hand side of your screen so there's a couple of ways to deal with this the way that isaac the person uh know, my personal preference is just factor your damn program. Like, break it up into chunks, create named functions that have, like, meaningful names and do one, like, really well-defined thing, and make those functions take a callback and just use it and just pass that callback around. It's not actually all that hard. Some alternative ways of looking at that are that you can use things like coroutines, where what you actually do is you tell the interpreter, okay, I want you to pause my program's execution at this point

because I'm going to wait for this thing to happen. But in the meantime, you can go run other stuff. Just don't keep running the rest of this one function. And then when it comes back with the results, so you flip it so that it looks like the imperative style of programming. So you do var data equals fs.readfile. That's actually kind of... So there's an implementation of this that is a little bit kludgy and dangerous, which uses long jump as a compiled add-on. There's also some ways to implement this using yield and generators in later versions of V8, newer versions of V8.

You do have to pass a flag into the binary because they're not enabled by default yet. It's a new experimental feature in ECMAScript 6, but it's there. It's one way you can structure your code, and it's not really a Node thing. It's just a JavaScript thing. A third option for this is to use something called promises. And so the promises don't require any additions to the language. What they do is you say, instead of receiving a callback, this function will instead return you a promise object. That promise object then gives you an API to say,

once this promise resolves, do this other thing. But you can write your programs in a more top-to-bottom kind of manner rather than a left-to-right kind of manner. Right. The promises is kind of just in all of JavaScript, not Node. That's kind of a growing trend that you see with a lot of different environments, I think. Yeah, yeah, exactly. And I think that there are, it's unlikely that anytime soon Node will make promises a default thing in core. A lot of people use it in their apps, and that's perfectly fine.

It's basically just another flow control mechanism. So then that brings me to the fourth possible way to manage this, which is something like the async module. And basically what that gives you is just some helper methods to thread callbacks together. So you can say, here's 10 functions. I want you to run them one after the other, and each one receives a callback.

And so that's kind of the de facto way to go about managing callback. And so that's kind of the de facto way to go about managing callback taking functions and putting them in pair, running multiples in parallel, excuse me, in parallel or synchronous or, you know, one after the other or so and so forth. Again, adds nothing to the language. It's just a, it's somewhat lighter weight than promises because it doesn't require any kind of like paradigm shift with how you think about your program. Right. So streams are something that people talk about too. What are streams and node and how are they handled? Streams represent a flow of data. So you have a thing like a, let's say, a network connection, like a TCP connection, right? TCP socket. Every time the other guy on the other side of that socket, every time they write some

data into their end, some data is going to pop out on my end. So I need some weight, some abstraction to say, look, every time there's data available, give me an indication of that and have some mechanism for pulling that data out of that stream every time it shows up. Then on the writable side, a stream represents a place where you're sending a flow of data. And then you call an end method when you're done with it. So what this gives you then is another abstraction on top of those two things where you can take a readable stream and just plug it directly into a writable stream with a pipe method. So you can do my readable dot pipe and then parens my writable and all the data that comes out will just immediately be sent into this writable stream. Right. So that's particularly handy if you want to send the contents of a file

to an HTTP response or vice versa or do things like that. Some of this stuff might be a little, I don't know, complicated for a newcomer. Especially hearing it on a podcast rather than reading on a... Yeah, totally. There's an archive of a lot of debate on that subject if you have interest in it on the Node mailing list, so you can go there for more information.

There's also pretty extensive docs on this now in the Node API docs. If you look up the streams API doc for the latest stable release, there is a pretty good discussion of what streams are and how to use them broken into three different sections. So this was pretty recent. Prior to this, it was all kind of a mishmash, and I think there was just a lot of confusion

and FUD around it. So we've broken it into three different sections. So there's streams for users, like you're consuming a stream, here's how to do it. Then there's streams for people implementing streaming APIs. For instance, if you are creating a new module that's going to send data somewhere or do some transform on it or what have you. And then there's a third section, which is like how it actually works and the history of it and how it used to work and how it's changed and so on. So most people really only need the first, you know, third of that document. And you can find that at nodejs.org slash API. Is that right?

Yep. Slash stream.html. So I kind of talked about it, but for a newcomer, well, I guess let me preface this by saying, is your target audience or are your target developers seasoned or entry-level developers or people that are in other environments and frustrated with it? Who does Node target for new developers? Yes, yes, all the developers. We target all the developers. If you're a developer, we are targeting you.

We want you developing with Node. Maybe not as your only platform, but certainly as one of them. I mean, it's kind of nice. It's kind of nice to develop in. JavaScript is not a very bad language. And I think that Node hits a pretty good, you know, a useful kind of niche between really low-level systems programming and super high-level, like, you know, Rails-y type stuff. The paradigms are very C-ish and very Unix-y. And, you

know, obviously here at Joyent, I mean, most of the engineering staff at Joyent are like super low-level, like kernel hackers and os people um and people who have been doing systems engineering for you know for years and years and node has really caught on in this crowd i think in large part because it's very um you know it's very it follows a lot of very standard unix paradigms yeah people know, there's a reason why. I think, is Node still the most popular repository on GitHub? I believe it is, right? Oh, I'm not sure.

It's the most popular repository in my list of tabs that I have open on Chrome. Yeah, I know it's up there. And I remember there was like a day where it kind of passed Ruby or sorry, Rails. And that was kind of like a big day for Node. You know, I don't know, maybe not specifically for like the Node core team, but just the community in general. So but that kind of gets back to my question. So for a newcomer, you know, let's say somebody that's like new to, well, let's say somebody that's new to just Node, like they're a developer, they know, you know, maybe they've worked with Java or Ruby or something else, and they want to try out Node. With Ruby, there's tryruby.org. There's all the code schools and Treehouse and all those. They have a lot of tutorials and lessons and how to learn Ruby for Python and things like that. What is there for Node for a newcomer to kind of get started and kind of play around with it um for a newcomer to kind of get started with node i think i mean i don't know i guess the i guess just kind of download it and install it and start messing around with some of

the examples and docs and stuff like we don't have as nice an onboarding system as i would like but um you know and i mean there's nothing like uh like pythonista for instance with python where you can like where you literally like download an ipad app and install it and you're like making games in you know 20 minutes like wow i'm super jealous but you know there's nothing quite like that for Node, but I think the actual platform itself seems to be approachable enough because we keep getting more people using it. I will say that, if you don't mind me stepping in for a second, on the getting started part, I had a hard time finding, because I actually wanted to mess with Bower a couple,

I guess four or five months ago, and to get Bower on to my system, I wanted to mess with bauer a couple like i guess four or five months ago and to get bauer on to my system i had to use npm which required me to kind of get started with node for lack of better terms i needed to have this installer to do that and i found it very hard to find out how to get it on my system in an easy way and i ended up finding uh a tutorial from robert bennett on uh installing no with homebrew on on the mac so that worked okay but it was still like had to search yeah so on nodejs.org we actually have a big green install button now yeah which will um detect whether you're on mac or windows or some other OS. If you're on some other OS it doesn't show a big green install button.

It just kind of has you download the source code because whatever, you're on Linux. You've got to figure it out. You're smart enough not on those. Exactly. You're used to being abused. But for Windows and OS X we have pretty straightforward downloaders now that will kind of put

things in the right place. So I should undo what I've done and use that? I mean, if what you've done is working for you, that's fine. I think Homebrew is, you know, it seems like people are succeeding that way. And a lot of people seem to get it in a relatively good state on their machine. I mean, I don't know. I'm probably not the best person to ask about getting started guys with Node because honestly, I read those things and I just can't see the forest for the trees a lot of the time.

And for me, the getting started is like, we'll just clone the GitHub and make install. It's hard about that. Yeah, right, right. But I mean, we're seeing really interesting things. Actually, I mean, Bower, stuff like not just Bower, but what's the other one? Grunt actually is driving a lot of node adoption, I've found, because people need to use Grunt in order to contribute to some open source front-end project,

and then they end up discovering NPM and Node and the process and kind of find, oh, like, oh, I can write, like, command line scripts in JavaScript, and I know JavaScript. Like, hey, isn't this great? You know, this is a person who might not have ever considered that they could do server-side programming. Yeah. So for somebody that does kind of want to get started with Node,

what kind of, like let's say they're sitting down, they have applications to build, or they have a specific application they want to build, and they're making the decision between, let's say they're comfortable with getting started with Node or any other environment, what kind of applications would you say thrive in Node? Or where would you say Node flourishes over Ruby, Python, PHP, et cetera?

I think Node really seems to do best as a middleware API tier, particularly if you have to talk to multiple different back-end sources and provide a web and or TCP or some other kind of front-end for those API sources. Another place where Node does really well actually is in writing command line tools because of the portability to Windows and Unix. So I think that's a big part of the reason why Grunt is so successful, because Windows developers can actually use it pretty easily. For writing, I mean, if you're going to write a relatively low, if you don't have really high scaling concerns

and you need to write a CRUD app, you know what? Rails is probably really good at that, especially if you're already familiar with Rails, especially if you're already good with Ruby and happy using it. Then by all means, it's got a lot of really nice tools

to make that successful. But if you're doing stuff that has a lot of requirements for doing a lot of streaming type of data, you know, if you're very comfortable with JavaScript, if you're comfortable writing things in JavaScript, then I think, you know, then Node really starts to make a lot of sense. Gotcha. So if you're doing, you know, event-driven non-blocking IO,

in other words. Right, in V8 JavaScript, yeah. I mean, it's also actually, so at Joyent, Joyent's a huge user. I'll talk about a few of the really big users of Node. Joyent itself, they use Node as basically the orchestration tier of their entire data center system. So everything between when you sign up for a host on joint all the way down to the actual operating system is running entirely on Node.

Now, obviously, the operating system as a whole is not entirely running on Node. That the operating system as a whole is not entirely running on node like that's got a lot of stuff that's written in c there's you know zfs and zones and d trace and so forth but like you know all of those little kind of orchestration demons and things that all need to talk to each other um you know this is this is all a big collection of node programs and and the nice thing about it is you can be writing a little daemon and be like, God, I really wish I had some easy way to see what this thing is doing. Like, oh, I know, I'll just have it spin up an HTTP server, because that's easy.

And so it opens a lot of doors, and having all of these different things all in one place makes you think about things in a little bit different way. Another example is Voxer has been using it for a long time, actually, to run their routing and their whole system. So they're basically sending JSON payloads with binary chunks of sound data, of audio data, and a little bit of metadata to know who to send it to. And that's, I mean, that's the core of their system. So they've got all of these different proxies and daemons and stuff taking this data in and stuffing it in a database and sending it to some other thing that like broadcasts it out to these other servers. And, you know, it's all this big telephony network. and they've they've written

this thing entirely in node yeah so i so little side note i wonder how exactly how many callbacks it takes for my softball team to tell me which field we're playing on in boxer i have no idea it's probably a shocking shocking number I'm sure. And it is pretty good for writing websites. I kind of like it because I like having a lot of very explicit control over that kind of stuff. And I like it just because I'm obviously extremely familiar with Node. So the first, the hammer that I grab when everything looks like a nail is Node. There's other things for building websites. It's something that we humans have gotten pretty good at doing, but I like Node for it. Cool. So I want to roll back a little bit. The original, the creator of Node, Ryan Dahl,

who is he, I think he's still at Joyent. Is that correct? That is not correct. He is not at Joyent or anywhere on the internet. He's basically retired from public life. Oh, we got another why. He seems to be doing well. 410 gone? No, I don't know if it's a 410. I think it's just temporarily unavailable.

It's a 503. The way he put it to me, he doesn't like creating permanent things on the internet anymore, so he removed his GitHub and his Twitter. I don't know if he removed his GitHub, but he definitely removed his Twitter and blog and Facebook and everything. It was Y-ish, but not completely. Basically, he got kind of tired of working on Node day in and day out for three years. As one would, I'm sure, if you got into this by hacking on new things and always wanting to try out the latest new thing. Suddenly, Trypton fell and ended up a success and uh next thing

he knew he was doing the same job for three years and went a little stir crazy yeah so how long so okay so up to speed the transition from ryan doll to yourself as kind of the maintainer of the project? What did that go like? So, yeah, so he was kind of feeling burnt out, and over a couple of months, I took over making the builds every couple weeks when we would release a new version, and gradually more and more took over more, you know, over about a, a six month or so period took over more and more of the duties of, of running the project and kind of,

um, keeping things going. And then, and he had talked about the other core committers about this, about me taking over his role in the project. Um, and then, uh, he posted a, a then he posted a message on the mailing list saying he's, you know, taking off to work on research projects and that I am the new, I forget how he phrased it, lead gatekeeper of Node and that all feature requests need to, you know, if you want any new features or have any bugs to complain to me about them, and then I'll be the one saying no to people from now on. So how's this transition been then, I guess, taking over that space considering his departure,

maybe it's just from being stir crazy on the project three years. Has it been the, have you been happy, I guess, is the way to ask that question. I have been very happy. It's extremely rewarding and it's extremely challenging. And running a project and a community, I think, is – I feel very, very lucky to be able to have found myself in a position where this is my job and this is what I'm doing. It's a ton of work and it can certainly be exhausting. But I care a lot about the success of this project and the people who are pouring time and energy into it. And I think it's also really – it's a good group of people. Like it's a good, it's a friendly community,

and I think we've done a pretty good job of trying to kind of keep some sense of positivity and not kind of devolve into too much of like, you know, turf wars or, you know, bad exclusionary, you know, sexist, heteronormative, ableist, you know, behavior or whatever, which kind of happens a lot of times in communities. I mean, you know, it doesn't take too many people to make a community a lot less welcoming to newcomers. Right. How much of your time now would you say is actually writing, you know, contributing to the Node project itself versus community engagement and, you know, kind of the maintainer role?

I think, I don't know. I mean, it's probably about 50-50. I'm certainly a lot better at writing code than I am at being a community maintainer. And I sort of always feel like I'm feeling my way out on that one. Basically, one or two days a week is just completely burned up by meetings. That's actually what today is. That's why I opted to schedule this call on a Tuesday was because this day is gone anyway. But no, I mean it's ironic though. I think as a programmer and as a person engaging with community and with people, like the more of your time and the more of yourself that you kind of like keep heaping, like just throwing at this project or throwing at a particular bit of work,

sometimes the less creative and the less insightful you can be. So I do try to carve out a large amount of my time for doing yoga and biking and just kind of like watching cartoons and doing like completely other random things. You know, because that's sort of like, that's sort of like what keeps you sane, you know, it keeps you much more grounded. And I find that I actually am much more productive writing code when I write less of it,

which is, yeah, like I said, I mean, it's completely counterintuitive, but. It's funny because I, you know, a few years ago, I kind of felt the same way and I'd started running every day. So, you know, whereas you felt the same way and I started running every day. So whereas you would do yoga and biking, I run every day. I heard – I think it was a guy at the – I can't remember now what it was called. But it was a Ruby Conference in Grapevine, Texas.

And he was talking about the importance of staying fit and just being active for your happiness. And this last week we were traveling and, you know, we were, I was doing some flying and driving and I, and I realized I hadn't run for like a week and I just felt like I was going crazy. Like I just felt like, you know, sitting at a desk and having this, you know, working on a computer all day, every day and not really getting the energy out anywhere kind of, kind of took me back to where I felt like I'd gotten, you know, before I started doing it. Yeah. Yeah. So I wanted to ask, how long have you been the maintainer of the project? When did that happen?

So when did that happen? Was it at the start of 2012, I think, if I'm remembering correctly? So it's been about a year and a half now. So burnout is the thing that we like to kind of talk about. And if we could, you know, package up how to solve burnout and sell it to everyone, we'd be bajillionaires. But it took Ryan about three years to burn out. And would you say that? I think it took him, I think arguably it took him two and a half years to burn out. It took him about six months to recognize it. To actually accept it.

Yeah. What are you doing to kind of prevent that from happening? Obviously, you said the yoga and cycling, but what else would you say you're kind of doing to help prevent that burnout from coming upon yourself? also a big part of it is to try and work on things that aren't your main job, but are maybe more of, but are still in line with your craft. Node

core is not the only thing I'm writing code for. NPM is not the only thing I'm writing code for. I think, other than that that just being more than a programmer is a really important thing it's very easy and typical for us to identify ourselves with our job or with whatever it is we do to make money

and forget that we're also supposed to be whole people and so obviously and kind of forget that we're also supposed to be whole people. You know, and so obviously, you know, if you spend a lot of your time on your craft or your job, like a lot of your friends are going to be friends you've met through work or through, you know, open source projects or what have you. And certainly most of my best friends are all Node people at this point in my life. But, um, you know, I, I try to, I try to have a little bit of a sense of a community outside of work or outside of just, you know, node. Um, and I think that, you know, doing yoga regularly has made a huge impact on my life and my health, but also just, you know, hacking on things occasionally that are not, you know, as obviously node-ish. Like, even if it is a node program, it's like, if I have a lot of, like, random little node

modules that I've written that people like and they use, and it's kind of nice every once in a while to spend a day just kind of, like, fixing bugs in those or, like, you know, accepting pull requests or whatever just because, like, that's what I'm actually passionate about. That's how I got into this. It's important to not get too caught up in where you're at now that you forget why it was you started out wanting to do this in the first place. You might have said it, I guess, in there in a winded way, but if you were talking to people, which might quite possibly be the thing happening here, but if you're talking to people, which might quite, quite possibly be the, the, the thing

happening here, but if you're talking to a bunch of people that were maintaining, I guess, semi or, you know, highly adopted, uh, open source projects, what advice would you give them? I guess to not, um, over, over, I guess, commit themselves and get themselves into a position where they do burn out. Um, so a good first step is to trick a company into paying you to do it. themselves and get themselves into a position where they do burn out? So a good first step is to trick a company into paying you to do it. There you go.

Because, no, and I mean, I'm really, really serious. Like, if I had a job doing something other than Node and I was also doing all this stuff, like, oh, my goodness, forget about it. Like, I would have no life. Um, you know, if you can't, if you can't kind of make it your job, then you can't expect to keep devoting a fair amount of your waking hours on it and, and continue to feel rewarded by that. Um, and I, I see this happen a lot, you know, where people have a job with some random company and they also have some open source thing and their company says, well, we'll let you work on this in your free time, or we'll give you 20% time, which is really 120% time.

And that's just really not sustainable. So at some point, with the success of an open source project that's successful, you have to either accept that it's never going to be much more than a hobby and that that's going to, you know, necessarily limit how far the project can go. Or, and that ends in some, in the cases of some projects, like that's perfectly fine. I have some projects that are just purely like hobbies and labors of love and I don't get as much time to work on them as I'd like, but that's just how the cookie crumbles. Or find some way to make that thing be your job so that you can actually have time and energy to devote to it

and not have to be stealing it from somewhere else. Are you a fan of potentially, I guess in some cases, we've had people on the show, Andrew, where they've turned their project into some sort of commercial way of making money. I guess if you can't trick a company like Node or join it into paying you full time to do your thing like you're doing, would you have considered, I guess you didn't create Node, but I guess would you advise to find a way to monetize it in some sort of way that makes sense for the community? Yes. I mean, if you can do that in such a way that it actually doesn't destroy the goodwill that you've created. And this is another huge pitfall, right? A lot of paths to monetization, and just to pick one example of my SQL.

If you try to go kind of the dual licensing route where you have this crippled for commercial use license, a GPL license, and then you have a proprietary but not crippled for corporate use license, that's one way that you can monetize because anybody in the community can use the GPL one, but if you need to use it for closed source stuff or proprietary stuff, you have to purchase this other license. In the long run, I think that that obviously doesn't

really work as well because what can very easily end up happening is you get purchased by a company like Oracle that says, you know what, actually we don't want to do this GPL stupid thing anymore, so we're just going to do the proprietary one. And now your users are over a barrel. Another way to go about this is with heavy-handed marketing type stuff, and nobody likes being sold something they don't want right so um if if there's some way to go about monetizing your your project perhaps by uh by providing some additional service or you know whatever like you know services or products around it that that can often be very, very successful.

I wanted to ask you, you know, kind of running short on time, but one of the things I wanted to kind of get to is Node has some pretty cool branding. And I just wanted to ask, who controls the brand of Node? Oh, so when he, I don't know exactly when it was, but at some point Ryan sold the trademark to the Node mark and name to Joyent. And so Joyent actually owns the IP of Node. They own the copyright on the code and the trademark and word mark of Node.js. So the logo and stuff, that was all commissioned by

Joyent. Gotcha. And basically all the branding and everything, that's Joyent's thing. There was a logo before this one that was contributed by the community with the little cloud and the bubbly letters, but it didn't work out so well for Joyent because it had, I guess, rather dubious intellectual property ownership. We weren't sure who actually owned it

or what the rights were or under what conditions it was given to the Node project. It was Ryan at the time and not Joyent, so it was tricky to work that all out. So they just went back to the drawing board and created a brand new logo, which was hated at the time. Let me tell you,

like people, people could not, I am not joking. People threatened to like fork the project and rename it just so that they wouldn't have to look at that logo, you know, which is a total, like it's a total, like,

well, if the, if the Republicans get elected, I'm moving to Canada. Like, no, you're not going to do that. You're not going to uproot your family and move to another country because of who got

elected. Come on. So, yeah. And so some time passed and now it's like, now everybody loves the logo. Now everybody wants to put everything in a hexagon and hexagons are great. And it's, it's kind of funny how that's, how that's worked out. Cool. So we'll definitely, uh, I feel like we could talk about this forever. Kind of happens with most of the things we talk about because, well, we bring interesting topics on the show mostly. But for those of you that are kind of – sorry, go ahead. I said it seems that way from your past topics. I'm very honored to be here. Oh, no. We've definitely had demand to have you guys on here, so it goes both ways. Yes. Doors are being beaten down. So to those of you that are kind of new to the show,

we ask our guests kind of a set of three questions at the end. And the first question, Isaac, is for kind of a call to arms. So for the community to get involved and what you would like to see them kind of contribute or work on. I think the main thing that we need right now is just more people using Node, advocating for it, and helping new users in the various channels, like in the IRC channels and in GitHub and the mailing list.

You know, we're growing fast, and if you look at all the numbers, I mean, it's like we're still hockey sticking, but we're still quite a small community. And, um, you know, it really, the more positivity that everybody brings to it, the more successful newcomers will be. And, and the more it'll keep kind of compounding this, this growing system. Right. Maybe something like a try node.org or something. Yeah. Yeah, sure. I mean, that would be, that would be lovely. I think. Maybe something like a try node.org or something. Yeah. Yeah, sure. I mean, that would be, that would be lovely. I think there is something like that. There's a learn you a node. Uh, I don't remember, uh, like, I think it's kind of like a play on the learn you a Haskell for

great good. Yep. But, uh, yeah, I mean, there's some, there's some resources out there, I think just, uh, continuing to, um to help new people be successful and guide them towards success is extremely useful. Gotcha. If you weren't doing what you're doing now, whether it be a different environment, programming language, or just personally something different, what would you like to do? I would really like to take, and this is probably going to happen eventually, but I would really like to take a good couple years off from software in general and just kind of see what happens. I did a few months and NPM happened,

and that has been extremely beneficial for myself and I think a lot of other people. And, yeah, I don't know. There's this co-op bakery near my house that every time I go in there, I fantasize about just like being like, ah, screw technology. I'm just going to like do yoga and bake and sell pizza

and that's going to be my whole life. It just seems so simple. It's funny because I think that the common, you know, I don't know why, but for some reason the trendy things that you hear a lot about in the developer world are woodworking, cooking or baking of some sort, and music. Those are kind of the three things that people seem to gravitate towards. And I think it just kind of speaks to creating something physical with your hands. You know what I mean? Yeah, yeah.

I mean there's a real – when you make like a perfect pastry, I mean that is like so, so satisfying. And it's difficult. You know, you can't do it at home because you need like the chilled table and massive amounts. I mean you need – in order to make a really good croissant, you have to make a hundred of them. Yeah. So kind of opportunity to give you a shout out to a hero of yours. Um, we call it a programmer hero who, who's somebody that's kind of impacted you in your life. Um, I, you know, I, you told me that you were going to ask me this question and I, all I could think of is a lot of people who I would want to uh to shout out to but i i think um if i had to pick one i mean honestly i'd have to say ryan uh and it might sound kind of cheesy but uh you know like i said

is um his aesthetic with node really um called out to me and I think that he has a really good view of what's important when it comes to writing software, that it needs to be fast, it needs to delight the user, and it just needs to work really well. cursing him because I've inherited a bunch of his code and frequently find bugs in it. You know, I think that in any platform or any like significantly sized programming project, you see a lot of the aesthetic of the original creator in everything. It kind of permeates the entire thing. And I think, you know, NPM is very much my aesthetic and, and node still is very much Ryan's. I think that a lot of that has, uh, has been maintained. And so I think, um, it's, it's definitely been an inspiration to keep working on node. I really like it a lot. Awesome. Well, yeah, like I said, I, you know, we could talk about this forever, but we're coming up on that, that, on that hour time limit. So I just wanted to say thanks so much for coming on the show, man.

I mean, hearing about, I don't know, just Node and the community that's coming up under it is really kind of exciting. So I just wanted to say thanks for all the hard work and the work you put into yourself to prevent burnout so you can keep this train going, man. All right. Thanks. Real quick before we go, I want to mention that we are member supported. So you can head to the changelog.com slash membership to show some love. If you'd like to get updates every Thursday in your inbox from the changelog, you can sign up for our newsletter at the changangelog.com slash weekly. That's right. And now you can hack and style with your very own Changelog t-shirt. You can get yours at thechangelog.com slash store. If you're a member, you get 20% off.

Once again, you can check out Pete Keen's e-book at petekeen.net slash mastering dash modern dash payments. That's it for today's show. How do you spell Pete King? Pete Keene. It's P-E-T-E-K-E-E-N dot net. It's a lot of E's. Pete Keene.

That's what I would have guessed. Yeah. So that's it for today's show. Thanks again to Isaac Schluter for joining us. And until next week, guys, let's say goodbye. Later. Later. Bye. you