The panelists talk to Isaac Schleuter and Mikeal Rogers about io.js.

Special Guests: Isaac Schleuter and Mikeal Rogers.

 

Nice.

Right, so that’s what we’re doing, right? We’re going to theatrically read the io.js source code.

Hey everybody and welcome to episode 147 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames.

Hey everybody.

Jamison Dance.

Hello friends.

AJ O’Neal.

Yo, yo, yo, coming at you live from grandma’s house in Lanexa, Virginia.

I’m Charles Max Wood from DevChat.TV. And this week we have two special guests. We have Isaac Schlueter.

Hello.

And Mikeal Rogers.

Hello.

Do you gentlemen want to introduce yourselves really quickly? I know we’ve had…

Like they need any introduction.

I know. And I think we’ve had both of you guys on the show before. But…

But you should still do an intro.

Yeah.

Yeah.

[Chuckles] Yeah, yeah. I don’t think that everybody listens to the show. I know that you guys are popular. But [laughs] I don’t know any podcast that…

We haven’t reached 100%.

That’s right.

Saturation with the whole earth yet.

Soon.

Alright. I’ll start. I’m Mikeal Rogers. I do lots of Node stuff and I run NodeConf.

Awesome.

And I’m Isaac Schlueter. Yes, I’m that isaacs. I ran the Node project for a little while, wrote npm, hired a bunch of people at npm, Inc. where I’m now the CEO, and that keeps me very busy.

Awesome.

Alright.

It’s really awesome to have you two guys on the show today, by the way.

Thanks for having us.

Yeah, we’re big fans.

Thanks.

As far as our listenership goes, if you haven’t listened to any JavaScript Jabbers ever, any part of any show, actually you probably have if you’ve gotten this far, then shame on you I guess. I’m just kidding. [Chuckles]

So anyway, we brought you on to talk about io.js. Do you want to give us the thumbnail sketch of why JavaScript people should care or what it is?

[Chuckles] Okay. Io.js is a [inaudible] I guess Fedor technically started back in around thanksgiving weekend. Since he started it, very quickly all of the primary contributors to Node except for those that worked on Joyent came on board. We started an open governance process, set an open technical committee, and we’ve done everything really publicly and in a way that tries to bring in the community. [Inaudible] we built out. A build group, a distributed build system. We’ve done several releases at this point. We’ve attracted more active contributors to the project than we’ve actually ever had in its history. And yeah, things are going awesome as far [chuckles] as the development of, well of Node or of io.js.

More of that backstory, it actually started out as Node Forward. A bunch of us wanted to move away from the BDFL model and towards a more open governance consensus seeking model. And Joyent wasn’t opposed to this but certainly didn’t jump on that bandwagon quite as fast as a lot of folks would like. It’s definitely tricky to move a company from one position to another, obviously. So, we had this Node Forward thing going for a while. But that’s confusing because now we had two things called Node and they were sort of different and sort of related. And so, we made Node Forward private, the Node Forward fork of Node private.

And then after a few weeks of Node Forward being private, Fedor got really sort of frustrated and was saying, “Well, why don’t we just rename it?” And then nobody replied to him. And it was like, “No, I’ll just pick a new name and I’ll just do it. It’ll be fine.” And nobody replied to him. And he was like, “Fine, I’ll do it on my own.” And that was the Thursday of thanksgiving. So, basically that’s why…

That’s why no one replied to him? [Chuckles]

That’s why nobody was replying to him.

[He] was very single-minded. But apparently I heard from Ryan Dahl himself that io.js is a much better name.

Really?

You know, if I want to make any decisions on this show, I think that’s what I’ll do. I’ll just pick a long weekend. Hey guys, I need your input on this. Okay. I’m just going to do what I want to do. [Chuckles]

Okay, if anybody has a problem with it, speak up now.

[Chuckles] Nobody said anything. Sorry, guys.

Yeah, exactly.

But that’s awesome.

Pro tip. [Inaudible]

I actually really like the name.

Yeah. It’s worked out really well. If you look at the tagline, it’s asynchronous I/O on V8 JavaScript. Io.js is such a natural name for it. I don’t know why nobody thought of that beforehand. I was really surprised that the domain was available and everything. It is a little confusing because there’s a programming language called IO that no one’s ever heard of. But it’s actually a pretty great programming language. It’s [inaudible].

Oh yeah.

It’s actually really neat. And I had never, would never have found out about it except for this name collision.

It’s featured in the book, ‘8 languages in 8 weeks’ or ’10 languages in 10 weeks’. I can’t remember what the name of the book is.

Seven Languages…

N languages in N weeks?

There you go, ‘Seven Languages in Seven Weeks’. That must be it. Yeah, it’s featured in that.

Or seven languages in seven days, is it?

Yeah, I went through it and it’s super hard to just get it installed anywhere. But it is a cool language.

So, I wanted to ask a little bit about some of the technical differences between Node and IO. I started using Node [in ‘04] and it seemed like new versions were released fairly regularly. But I wasn’t, it was still all so new to me that I didn’t really notice the new things in them. But I feel like we’ve been on version 10 for a while. Is that part of the motivation for forking it, is to get more regular releases out? Or is that a side-effect?

It was definitely both a cause and effect. So, on the one hand there’s this interesting paradox where the faster you move, the faster you can fix things and the more ability you have to actually deliver stability. And I think that that’s really the problem that we were running into, was Node 0.10 is using a version of V8 which is so old that Google is not even releasing security patches for it anymore. It’s fallen off of their support wagon. So, our thought was like, “Well, we need to get 0.12 out the door or something else. We just need to get on a modern V8.”

Additionally, there’s a lot of frustration because people would land patches. And when you don’t have that steady cadence of a release process, what happens is people start to lose their motivation to get involved with the project. And we saw contributions and involvement falling off a little bit. So, that’s what Node Forward started out. And it started out as a conversation and a way to talk about how we’re going to address this problem and what needs to happen in order to move us forward faster.

Like I said, Node Forward rebranded as io.js in Fedor’s fit of frustration. And [laughs] as a result we were able to open the doors on that. And what we found was there’s actually a huge floodgate of just people who were waiting in the wings to get involved in the project. So, we have a record number of official logos. We have… [Laughter]

A lot of folks who actually have been added as committers. The TC has grown up to… Mikeal, how many people are on it today?

Well, so there are I think seven members and then three non-voting persistents?

Yeah, wasn’t the three non-voting members just added recently?

Yeah, so one of those is Rod Vagg who’s been working on the build infrastructure stuff and is also just a fantastic project manager, getting everybody to get these test systems to be producing green builds and making sure that stuff that is blocking the build gets addressed. And there’s also Domenic Denicola from Google who works very tightly with the Chrome team and the V8 team and has been giving us a lot of insight there about keeping in touch with JavaScript the language and the implementation we’re using. And the third one, oh I guess the third one’s Mikeal. [Chuckles]

Too humble to name himself.

So, can I just see if I’m understanding rightly the way that things have gone here. So, Ryan Dahl created Node.js and Joyent sponsored it in a lot of different ways for a long time. And anyway, it just got to the point where the model that you were using to manage the Node.js wasn’t really working. And so, you forked it so that you could get a different model around managing the project so that you [inaudible] us as the community so that we could all push it forward in the way that we wanted, maybe a little bit more collaboratively?

Yeah. It was like this fork and experiment and then bring back thing that we’re all used to doing with GitHub. It’s one thing to say, “Well, we want your governance model to change.” But the natural response is, “Okay, well change how? We want to make you happy but we don’t know what you’re asking for.”

Right.

So, we didn’t actually have a good answer for that. And Node Forward was about figuring out, what changes do we want to see? And that’s really materialized in an effective way in io.js. And that’s what we’ve seen, is we’ve seen this iteration on a governance model that is very open, very collaborative, and actually has made a ton of forward progress. And it’s not like the first idea we had was the one that actually ended up being the one that we’re using now. And it’s a continually evolving process, because through that technical committee and voting process and consensus seeking governance, we can actually change what the rules are as we’re moving. So, it’s actually very iterative. And my hope is that a lot of this feeds back into the mainline Node project eventually.

That was going to be m y next question anyway. How much of this do you see getting pushed back to Node?

Well, ideally all of it, both in the technical work, the governance, and the community engagement. So, there are certainly some folks who are very excited about a rebrand and they want to start sharing about the new name and stuff. And I think it’s actually a better name. But what it lacks is several years of investment and a bunch of companies putting their weight behind it. And a lot of people still don’t really know what io.js is, except as some Node thing. So, I think there’s also some very real costs involved in rebranding. So, it’s clearly in the interest of Node and Joyent and everyone involved with Node to get that momentum folded back in. And it’s very much in the interest of io.js to be able to go back to the original, mainline brand that people know.

So, it seems to me like perhaps Node.js will become more like the enterprise, really solid, slowmoving target. And io.js will become the more, if you need the latest features six months ahead of schedule, that’s what you want to use. Is that what you think will be the case? Or how do you think that will play out?

No, absolutely not. [Laughs] And I’ll tell you why. Because the way that you do stability in software, this idea that we need a very slow-moving waterfall process, it’s antiquated. It’s an accident of history that it ever worked that way. And it’s because of the limitations of recasting hardware. We don’t have those limitations in software. We can actually iterate very quickly. And the best way in fact to build very, very stable, very resilient software, is to be iterating very quickly and feeding all of those changes and keeping everybody very engaged, and feeding those changes back into a mainline stable branch.

So, I think what’s going to happen, what I don’t want to see is like, “Oh io.js is bleeding edge and Node is stable.” In fact, io.js is extremely stable. We’re looking at deploying it now in production at npm, Inc. And there’s also Yandex and Google and a bunch of other folks who have, I don’t think anybody’s come out as, “We are shipping in io.js,” but they’ve certainly said, “Oh we’re looking at it. It seems fine.” It’s the same TC that blocked any new features coming into Node for years. [Chuckles] It’s the same bunch of us stick in the muds who are all saying, “Do this in user land,” and stuff. So, it’s going to be exactly as stable. It’s still very much a no batteries included kind of approach. So, I want to hear Mikeal’s additions to this as well.

Well, all I’ll say in addition to that, that is definitely all true. But it’s also not, there’s nothing stable about shipping dependencies that have been end-of-lifed, right? So, there’s a huge advantage to staying not just up to date but at least up to date with what is still being supported in your dependencies. Joyent just shipped 0.12 today, finally, after two years. We’re all very excited. But if you go and look at it, it’s using both the V8 and libuv that aren’t really being maintained. The V8 is about six months old, which is a long time in V8 time. And the libuv isn’t being maintained anymore either. So, there’s nothing more stable about that. If it were a little bit older but still being maintained and patched and at least getting security updates, then that would be, that might be more stable. But it’s certainly not more stable to take something that is literally end-of-lifed.

What was that second library, not V8? The other library you talk about?

Libuv.

Can you explain that a little bit?

Libuv is actually where most of the magic happens in Node. It’s the underlying asynchronous I/O library that straddles the world between Linux and BSD and Windows and all these different operating systems. It does a lot of the hard work. And it’s used in a couple other programming languages as well, including Luvit which is a LUA widget. But yeah, it’s a fantastic project. And a lot of the main contributors to libuv are also Node core contributors, like Fedor Indutny and ben Noordhuis and Bert Belder.

So, we’ve talked obliquely about the governance model of io.js and how it differs from Node. But do you mind, Mikeal, just giving a rundown of what exactly the governance model is right now?

Sure. So, essentially there is a technical committee, which is basically the people that we trust to make a lot of the underlying technical decisions. Anything that gets very contentious, anything that we’re really worried about like a giant code change or anything where a bunch of contributors can’t agree, that decision ends up in that technical committee. And that’s what’s under what’s called a consensus seeking model. So, it’s not a peer consensus model. You can take things to a vote if they remain contentious. But in practicality what you end up doing is working [inaudible] goal is to reach a [consensus] [inaudible] take anything to a vote. We’ve [inaudible] disagreements in the TC. And then we table an issue for a week. And we all end up getting creative in coming up with a solution that everybody can agree to. So, we haven’t actually quite had to do that.

But yeah, so the TC meets every week. It’s all very transparent. And then in addition to the TC we have a bunch of people who are committers on the project who have a commit bit who are collaborators. And they land code at will, provided that it’s not a contentious commit.

Yeah. And ultimately, the release is owned by the technical committee. So, if there’s something that goes in that people have very strong passionate feelings about, it can be brought up to the TC. We can either roll it back or we can sign off on it before it goes out as an official part of the release. So, we still, we’ve moved from a single gatekeeper that everything blocks on to a team of people who only block on the things that are actually, need blocking.

Yeah. And I should also mention that we have several working groups which are essentially autonomous. And they tackle a bunch of other additional tasks. And they have their own working group membership. And that’s everything from streams and tracing to dealing with the website.

That makes a lot of sense. Thanks for explaining. I know AJ had some technical questions about some of the new io.js stuff. Is that true?

Well, yeah. First and foremost, oh I don’t know. There’s a couple of first and foremost. But let’s start with stable, beta, unstable. What do version numbers mean now? Because Node was odd is moving forward and even is security updates only, kind of.

I have so many feels about version numbers. You have no idea.

[Laughs] It’s like it’s important to your life or something.

[Laughs] I know, I know.

1.0, yay!

Yeah.

So, let us feel the feels here.

So, we’re at 1.what, 1.2 now. 1.1? I forget.

1.1 is what I saw the other day, as in yesterday.

Yeah, yeah. 1.1. We were talking about what’s going to be in 1.2. Here’s the thing. We’re not tying version numbers to timing. And we’re not tying version numbers to stability. What we’re doing is we’re following the pattern which has been set by literally every project in the Node ecosystem except Node itself, which is to use SemVer and increment your version numbers based on what changes went into the API.

So, what that means. You have major, minor, and patch versions. We bump the patch version every time there’s any change whatsoever. We bump the minor version for every release that includes any new feature, whether it’s, any API addition. So, if you’re using 1.0 it should be safe to upgrade to 1.1. But there may be new things added. And then we bump the major version for anything that’s a breaking change. So, if you’re using 1.7.4 then upgrading to 2.0 might actually break your code. You have to be careful with that. Anything that is a complete, like a full release, anything that’s like, “This is the release of io.js. This is the one you should download and use,” that should always be stable.

Now in terms of, we’ve traditionally drawn this line between binary API versus JS API. And we’re just applying the exact same SemVer rules to that. So, our binary compatibility should be stable within a major release cycle. And there may be additions to the binary API that happen on the minor version upgrade. There may be bug fixes which don’t change binary compatibility on the patch version.

So, that brings up the question obviously, what about, “Well I was depending on that bug.” [Chuckles]

We have, Mikeal do you remember what exactly the issue… oh, it was…

Assert.

Yeah, assert.deepEqual. There was this weird situation where if you do assert.deepEqual there’s something in there which is clearly a bug where it was checking Object.prototype. So, they astute listeners in your audience, and all of your audience listeners are astute I’m sure, will know that Object.prototype is not a thing. That’s not a magic property. The magic property is Object.constructor.prototype. So, we were checking if Object.prototype equals, A.prototype equals B.prototype. And what it should have been is checking if Object.getPrototypeOf(A) equals Object.getPrototypeOf(B). Okay.

So yeah, that dates back to before 0.10 I believe. I think that dates back all the way to the introduction of the assert module. So yeah, it’s just obviously a bug. So, what are the ways that we could fix that bug? Well, we can remove that line of code because it doesn’t do anything. Great. Or, we could change it to be what the intent of that code was. So right now, if you do assert.deepEqual and you pass it an object literal with no keys and you pass it an array with not entries, it’s going to say true. It’s going to say, “Yes these things are deepEqual because all of their keys, including their prototype property (as if that was a thing) are equal.”

So, we can’t fix it by changing the way that the prototype is checked unless we accept that that’s a breaking change. We decided that wasn’t worth it. And so, we just removed that code. Otherwise we would have had to bump to version 2.0. Then we also added or we are in the process of adding Object.deepStrictEqual, or was it strictDeepEqual. I can never remember. And what that is doing is that’s a new function, a new method now which does a strict equality check of all of the properties and also checks the prototype using Object.getPrototypeOf.

So, what this is all a very longwinded way of saying as one example of we are really, really committed to the semantics of SemVer and maintaining that moving forward and making sure that all of our version numbers actually are meaningful in the way that the Node community has decided version numbers should be used. And additionally we are really hesitant to do anything that breaks anybody. We’re still very, very, very stable.

So, why did you go for 1.0?

I think there were breaking changes between the most recent release of Node and the release of io.js. Now according to Node’s more, what is it called, not semantic version but romantic versioning system or something? [Chuckles]

According to the older Node-style versioning system which predates SemVer, you bump the minor version for each of those breaking changes. However we’re sticking with SemVer. That means when you go from 0.10 to the next version, if the next version has breaking changes then that’s 1.0. If we look at things from a SemVer point of view, Node 0.10 should really be Node 5.0. There have been five breaking change release sets in Node. And from this older mentality of using even/odd like the Linux kernel and using 0.x to imply a certain level of stability, and I think that that’s just really not… what we decided as a community is that’s just not really what version numbers are for. Version numbers are for communicating what has changed in the API. And so, in io.js we’re very committed to that. And that’s one change that we would actually like to see in the way that Node is run as well.

So, if I have, say my application depends on 1.x, io.js 1.x. And currently you’re a year into 2.x. And there is, let’s say I’m running 1.1 and there’s a security update that needs to be applied. Does that mean that I would need to update to whatever the latest 1.x is to get that security update and I have a guarantee there’s no breaking changes? Or would a security update that’s major be applied also to minor versions as well?

So, this is always the edge case when you’re having SemVer discussions that is usually tricky. What if there’s a security update and the security updates requires that we actually make some kind of breaking change. Something that was allowed is now no longer going to be allowed. And if you’re application depended on the security vulnerability then we’re going to break your app, right?

Well, I’m not even thinking that edgy of a case. I’m just thinking…

Oh, okay. [Chuckles]

Because a lot of people, they want to stick… think in the IT world. They want to stick with 1.1. They don’t want to update to 1.2. They want as few changes as possible. So, if there’s an absolute security update, they sometimes will expect that that will be backported into a couple of the minor releases. So, 1.1.26 becomes 1.1.27. And 1.2.10 becomes 1.2.11.

Sure. Yeah, I think we’ll do that when the severity and the priority of it merits that sort of a consideration. Without a specific example, it’s hard to say. And we’re also predicting quite a ways into the future since io.js is still about a month old. But I think we’re planning on, and this is still in early discussions, we are planning on having a bleeding edge latest and a stable release trains mirroring the way that V8 does things. And we’ll probably add onto that a supported but legacy train as well, which is like yeah, we’ll land the really big security type things. But we’re not going to just add new features, or even really fix bugs that aren’t super high priority.

Cool.

So, I’m wondering. I’ve done a little bit with Node. And I want to go install io.js. Do they run side by side? And the things that depend on them like npm and stuff, is that going to mess up my world when I try to do an npm install and it’s going, “Okay, do I use IO or Node?”

If you want to run multiple versions of Node, you should use nvm which is Node Version Manager. It’s fantastic. And you should do the same thing if you want to run io.js and Node, because it will replace the Node install just like every other major Node release.

Okay.

So, that’s a good way to run both of them. And then when you switch it out it’ll switch out the one that npm, is using as well. So, no modules should break that are pure JavaScript. Some modules will break that are native, that use C++ add-ons. Most of those add-ons use this library called nan by Rod Vagg which straddles the world between different V8 releases when they break API. And there are pull requests out on virtually every module that broke to update to work with io.js. Now, it’s just a matter of those getting tested and merged and then released so that you don’t have breakage in some of those modules. But [that’s] relatively rare. And all the big ones that I know of had been merged now.

Npm and most modules will just use whatever is the Node that’s in your path. So, io.js creates a binary called io.js and then symlinks it to Node just to have backwards compatibility for that reason. I would recommend using nave rather than nvm because I like nave better because I wrote it. But it has my pheromones on it. [Laughter]

Also, I just, I don’t like things that put stuff in my .bashrc file. I feel like that’s a little bit too personal.

Nave uses subshells. Anyway, subject for another talk.

But your pheromones aren’t too personal. [Laughter]

No. Actually, as far as the actual code goes, it’s a bash program that I’ve since upgraded my bash skills since I originally wrote it. And it kind of bugs me the way that it’s written.

So, back to the breaking changes thing for just a moment. So, I’ve seen a lot of node-gyp errors. And they’re packages that were fine on Node 11 which I think is a lot of the work of Node, I mean io.js 1, right? Or are these packages breaking because it’s renamed to io.js and all the URLs are io.js or are they breaking because there are V8 incompatibilities?

Yeah, it’s the V8 change. So, gyp is a tool that compiles for a native add-on. And so, it’s trying to do something in the new V8 API that it can’t do, that it used to be able to do in the old V8 API. So, it’s trying to do them in the nan API and [inaudible] the new nan API could do that.

Then, what’s pangyp?

Maybe Isaac knows. I don’t know.

Pangyp I think is the new gyp that’s written in Node or something. I forget. I don’t actually know. I haven’t been following it that closely.

Okay, because I thought pangyp was to bridge the gap between io.js and Node.js but I must have misunderstood.

You know, you might not have misunderstood. You know at least as much as I do.

Chuck says that it’s when you mix Japan with Egypt.

That’s probably it. I didn’t know we had the technology to do that in code. But, it’s pretty cool.

Yeah. Now you know.

If you [inaudible] errors with gyp compiling for new V8 you’re going to have the same problem upgrading to 0.12, Node 0.12 that came out today, because it also takes a new V8. We just took a newer V8. And there are probably more modules now that have been adjusted for io.js than just for 0.12. Although many of those adjustments will work for 0.12 as well.

I was going to say, when we encounter these changes, what’s the protocol? Do we post to that project or do we post in io.js? What’s… how do we…?

You complain on Twitter.

We complain on Twitter. Yeah, what’s the best way to manage those issues and help those authors that, I don’t know, maybe they’re done with that module. They don’t really want to go back and fix it. I don’t know. Read my mind and answer all my questions.

So, maybe a better question is, not a better question. I don’t mean to insult your question, AJ. A different to ask that is, do updates to make things work in io.js, will that break backwards compatibility with, if I update my binary module or some module that’s broken now in 1.0 in io.js, will it not work in old Node?

Use the nan library. That bridges the gap. So, use nan. You do have to port your C++ code. It’s not

a zero-code change. But there’s a module called nan, N-A-N, like the not a number value in IEEE floats. And that will, I don’t know. Do you know what nan is supposed to stand for?

It’s like native abstraction for Node or something, native abstractions for Node.

Ah, okay.

Okay, I misunderstood what you were saying about nan earlier then. So, that’s what it does.

Right. So basically, you code against the nan API which then figures out what version of V8 you’re linking against and splits it up. So, your code will continue to work.

Cool. Another question I have is who is the audience for io.js? You mentioned already how the project was created in some ways to try and influence Node by putting your money where your mouth is and demonstrating the changes you’d like to see. But what about the actual user level? Do you want everyone that uses Node to switch to IO? Is it just for the hipsters? You mentioned, so there are big companies using I already. So, it’s not a stability thing. But are you trying to get more people to use it or is it like, “Here’s this thing we’re making to try something different and it’s good.

So, if you want to use it jump on”?

It’s literally the future of the project, or the replacement for the project. There’s not… we’re doing a lot of really good work. We’re just as conservative and stable as Node has always been. We’re just actually shipping and we actually have a big community behind us. And most importantly, I think we’re actually out there doing a lot of work to bring in the larger community using Node already that really hasn’t had their voice heard on where they want to see the project go. So really, the audience is everybody.

Cool.

It’s like always with upgrading the version of Node that you’re using, right? Either you’re ready to upgrade or you’re not. There are folks who are using 0.8 and they’re fine. There’s going to be people using outdated versions of Node forever. If you’re developing things in this modern Node-y way, where you have a lot of small services that you plug in, it almost doesn’t matter. You can just start building your new services in the new thing and deploy them however you’re deploying them. And it’ll just work.

If upgrading is a huge pain and you have to upgrade this gigantic set, this gigantic monolithic application, I’m sorry. You’ve made bigger mistakes. Upgrading Node’s not going to fix them. Start looking at splitting things up in SOA bite-size pieces that’ll talk to each other. And then yeah, as you write new things, write them in the newer version of Node and upgrade when you need to.

So, I’d like to go back just a little tiny bit when talking about installation and stuff. I know that Microsoft did a ton of work to make sure that Node ran really well on Windows. When io.js came out and released some slightly breaking changes, did Microsoft get involved at all? Or did everything just, did it not really affect the Windows story for io.js?

I don’t think it really affected the Windows story. Io.js still, it also works on Windows. I’m not really in the business of being answerable for that anymore. So, I don’t have a really great answer. But I think…

I feel like Domenic would be yelling a lot if it didn’t work.

Yeah, yeah. So, Domenic’s very involved. Bert Belder obviously is super involved and he’s the one who did a ton of the original Windows work. So, the move that we made that Microsoft was a big part of was making sure that libuv worked on Windows. And that’s a part of why libuv was abstracted out of Node in the first place. So, we’re still using the same basic principles. There’s very little actual Windows or Unix-specific stuff in Node itself. So, it’s fine.

That’s good to hear. I have a lot of interest in that just because I end up teaching a lot of people who are on Windows. And it’s hard when they have any kind of problems with Node because lots of Windows developers just don’t understand. It’s hard to explain to them why Node becomes relevant to them even if they’re not necessarily using it as a web server. You want to say, “Look, Node is awesome. You really should be doing Node, even if you’re not using it as your web server.” And it was awesome that Microsoft spent all that time to make it work smooth.

Yeah, yeah, absolutely.

Now, are there any other, I guess what I’m wondering about is API changes between Node and IO. Because you did say that you changed the version to 1.0 because there are breaking changes.

Well, it’s the same breaking changes that are in Node 0.12, right? It’s all the stuff that was done in the 0.11 process and that whole unstable family of releases. And so, yeah there are some API breakages and there are some API changes. I don’t want to say breakages. That sounds a lot harsh. [Chuckles] But the success here is basically that we’ve taken the stuff that was just sitting around and not getting released and pushed it out the door. So, there’s a ton of stuff. If you look at the release notes you’ll see there are some things where there was really no way to change it without changing the API. There was no way to deliver the feature without changing the API.

Through the magic of typing in chat, AJ it sounds like you have a question about ARM and Raspberry Pi stuff and running Node on that?

Yeah. So, back around Node version 10.2.6 or so, because it’s not like… I’m not into Raspberry Pi in the way that I update Node on it constantly. But I have these little projects here and there. And then I went back to update Node on my Raspberry Pi and realized that it’s no longer supported in Node proper. And I also noticed that it’s not supported yet in io.js from…

That is not true. [Laughs]

Okay. So…

I might have done something wrong.

No, no, no, no. You probably came earlier. So, a couple of things with that. So, one is that I don’t know why it broke in 0.10 but it was never really that officially supported. People were able to get it running and they were running builds somewhere else. But you couldn’t go to NodeJS.org and get a build for ARM. There were…

You could.

Okay, for like a minute maybe. [Chuckles] And then it started failing for some reason. I don’t even remember that amount of time. So, when we stood up the new build farm for io.js we couldn’t get ARM going. And then we found out that actually the newer, somewhere between two years ago, the V8 that was shipping in 0.10 and now, there were a bunch of V8 breakages on ARM. And you can imagine, for some reason the V8 team wasn’t really testing this or something. So, people form the Node.js community hopped in to work on V8 basically and get it working on ARM. So, a couple of commits later they get the patch in and then we get to take a new version of V8. And it’s out and it works. And it’s part of our builds now and it’s in all the binaries for the releases as of 1.0.2 or 1.0.3, something like that.

And the reason why this was able to happen so quickly is because we’re now aligned with V8’s release cycle. So, we actually take the V8 that they said was stable for Chrome and then we ship that. And then we’re working on new code and contributing to the V8 codebase that the V8 team is actually working on. And so, now we have a tighter collaboration and a better relationship with the V8 team than we’ve ever had before. And we can actually get stuff like this fixed and out and working really quickly.

So, you’re saying with my Raspberry Pi B or B+ that’s ARM 5 or ARM 6 I should be able to get that compiled and installed now?

I have no idea what the differences are between different ARMs because I’m not that much of a robot nerd. But I do know that we have ARM build that are shipping and are part of our regular build process. [Chuckles]

Yeah. Well, I saw ARM 7 which is Raspberry Pi 2.

I see. I see. I’m not sure about the prior ones, then. You may just have to try and build it yourself. I think another thing, another hard part about the building of all this stuff is the build system needs to have this really fast ARM box. And we’ve seen them actually getting behind in some of the nightly builds and stuff like that, because they’re not quite as fast as everything else.

Yeah. It takes two hours to build on a Raspberry Pi B.

Yeah, yeah. But you can buy [inaudible] that will do it quicker than our other builds go, right?

Okay, cool. So, just out of curiosity, who would be a person to ping to help me debug those problems? Because I’m not necessarily an ARM guy but I think… well, with the Raspberry Pi 2 io.js isn’t a problem because you’ve got ARM 7 support already. But is there somebody that for those of us that have that Raspberry Pi and we want to upgrade, even if we’re not ARM experts we could get a little help? Do you know?

So, I think the best place… so if you try to build it and then you see the build failure and it’s an io.js build failure [chuckles] you could go to iojs/build, so the build repo, and log an issue there. And then…

Okay.

[Inaudible] hop in to help out and fix it over there.

Okay, cool. Thanks.

I want to go back to the community thing a little bit. With the different governance policies and things like that, is there any worry that io.js and Node may deviate more than they collaborate?

That seems unlikely. There are talks. People are talking about things. It’s all very collaborative but not yet as open as I think I would like. And so, that’s why I’m not talking much about it. But yeah, we all want to get to that place, including the folks at Joyent. We remain confident that there’s some good stuff coming up in the future. Our hope is that the future of both projects is to be together.

Also, we’ve pulled in a couple of fixes that have into joyent/node. Granted a lot of those were committed to that repo by people that are on io.js. But we have been pulling in code here and there. We’ve just taken a lot more and we have a lot more contributions coming in. If you look at the pulse, GitHub has that great pulse thing that shows you how active a project is, and you can just compare joyent/node right now to iojs. And we just have so many more people sending us patches and us working with them to get those patches in. So, a lot of the… you could think of io.js as being the work that’s happening over in Node plus a bunch of other stuff. So, if there are divergences, they’re really just additions in one direction, right?

I was just going to say, it’s like the difference between a unicorn and a Pegasus unicorn.

Wait, so one is Django and the other’s io.js? [Laughter]

Yeah, I guess all I was wondering about was that with the different governance strategies, that the priorities for one may change from the other. But at this point I can definitely see that io.js is really just thinking of itself as maybe a little bit further along version of Node.js. And so, at this point they’re almost still the same thing with one maybe being a little bit ahead of the other in one area or another.

Yeah. It’s a fork in the GitHub fork button sense of the fork, really. And that’s really where we… that’s how we all see it. That’s certainly not how it’s portrayed entirely in the tech press. And it’s tricky to make that happen when you don’t have a proper PR budget. But it’s tricky to get the message out without some professionals who know who to talk to and how to spin the story or whatever. So, it’s that side of things I think has been done, has been a little bit amateurish.

And I think it’s on, well on me and Mikeal. Here we are telling the story, right? [Chuckles] So, if I’m complaining about that not being done in an expert way, it’s because I haven’t done it in an expert way. But no, that aside, what everybody wants is a good, stable, fast, secure enterprise-grade, embassy-class, whatever, whatever, reliable thing to run your JavaScript programs on the server and on your robots and on whatever, in your cloud, in your containers, in your web 2.0, china market buzzword, Hadoop robots, et cetera. [Laughter]

I love how you’re just reading our Skype chat out loud.

Epic.

That should be the tagline for io.js.

Web 3.0 Hadoop robots. [Chuckles]

Yeah. I do want to respond a little bit. There’s been a lot of weird speculation. And I hear it a lot from big companies, enterprises, that they’re very worried about these two projects diverging in different directions. And it’s because you get a lot of rhetoric on the Node.js side that they believe different things than the other project. But the reality is that io.js was started and is still really being technically governed by the people that have been building Node for the last five years. So, there isn’t huge difference. We’re really stable. We’re really reliable. And they’re not, when you aren’t shipping and when you haven’t been putting out software enough. That’s the only thing that you can do to really put a positive spin on it. So, it’s fine that they want to say that. But we certainly don’t think that we’re any less stable than a two-year old version of V8 [inaudible].

So, I have a very vague and broad question. And I hope you can provide fantastic insight out of this weird thing. Do you think there’s something to be learned about open source in general from this fork? When I first started getting more into web development it was around the Merb/Rails thing. And to me, it seems like that was better overall for Rails that it forked and then came back together. Does this just happen periodically in open source projects and it works out well? Is there something… would it be better to avoid this kind of thing and resolve it in a different way? Does that make sense at all?

Yeah. It’s a great question. And I think that, I’m not a Rubyist and I never really got into Ruby. And I don’t actually like using Ruby. It’s my not-so-secret shame, I guess.

And people usually get mad at me when I say that and they’re like, “Why do you hate us?” And I don’t hate them. I just hate the thing they’re using. [Laughter]

Well said.

But no, I love them. Some of my best friends are Rubyists. [Laughter]

Anyway, from what I’ve heard, from what I’ve heard about that whole story, the Merb/Rails splitting apart and coming together, actually it’s hopefully in the fullness of time pretty similar and I think was probably what was best for everybody involved in the community. Now, the best thing that could possibly happen is you very quietly plod along and everybody is very much on the same page and you don’t need to fork and then come back. Yeah. That’s cheapest and easiest, right?

That’s the thing that gets the best software out the door.

That being said, that isn’t always how it works out, because humans are real people and sometimes have differences of opinion and get frustrated and want to make some forward progress. And you know what’s amazing about software is we can just, we have an infinite amount of space in which to experiment, right? There are thousands of Node forks where people have tried out a little thing that maybe did or didn’t work out. And nobody needed to, there’s a lot of handwringing and fretting over this stuff. And really, it’s very, very, it’s actually very low-risk to do stuff like this. The biggest risk is that you look like a little bit of a jerk if you’re not making it clear that we’re all trying to do the right thing and trying to help each other out. And maybe if you’re not trying to work it out then you are a jerk. But that’s not what this is.

This is actually the system working. And not in the sense of some evil actor came in and the system worked because we got to say, “Screw you,” and we left. That does happen. That happens a lot in open source. But this isn’t really that case. This is a case of everybody really wants the same thing. We had some diverging opinions and priorities about the best and most expedient way to get that done. We very peacefully stepped aside to experiment on a new thing so that we could advance that discussion further. And I hope that that process just keeps continuing. I don’t want to sound like I’m trying to hide or downplay any of the frustrations involved. Certainly there are a lot of folks for whom this is their livelihood and they’re very involved and feel very passionately about it. But it’s a JavaScript runtime. And we’ve been making these for the last 20 years. Yeah, Node is the biggest and most popular and most awesome, one of those. [Chuckles]

And io.js is the next phase in that evolution. But what is the phase after that? I don’t know. Probably they’re going to come together. And all of those logo t-shirts will be collectors’’ items.

Or maybe it will be like MVC frameworks and we’ll have 20 of them.

Yeah. You know, I don’t see that happening because it’s just, it’s not the kind of thing that you can reasonably have 20 of. Otherwise we would have lots of other server-side JavaScript frameworks. That was the plan for CommonJS. And what very quickly came out of CommonJS was Node. And we discovered it and we were like, “Oh, okay. This is what we need to do. Not argue about specs all day but actually just have one implementation that works really, really well and we can all put our weight behind.”

So, I think that there are cases like MVC frameworks where spinning up a new completely radical different idea is very, very easy and cheap. And so, it’s worth iterating on that a whole bunch and letting a million flowers bloom and deciding which one is the best once you see it. But with Node, we have this very tight, small kernel of functionality that people can use to bootstrap a module ecosystem and a community. And people can use that to be the baseline bit of functionality. And then in all of the 130,000 npm modules, by the time this airs, it’ll probably be even more than that, that’s where the real value is.

So, basically the value of Node is not in the runtime itself. And in fact we’re really making sure to keep the changes in that really modest. We’re not pulling Express into Node, for example. This is not what we’re talking about. What we’re talking about is just the core runtime that really enables npm and the ecosystem of modules. And we want to facilitate that ecosystem as effectively as possible, because that’s actually what is taking Node to all these different places. And of course I’m biased since npm is my baby and is the thing that I work on. So, of course I’m going to give it all the credit. But I think that that’s where people live. That’s where Node developers are actually spending their time and energy. They’re not spending it upgrading Node.

Very well said.

Alright. I need to start heading toward picks. I’m the one that has the hard stop today.

Boo.

Yeah.

I actually do too, so I appreciate you calling that out right now.

Is there anything else that we really haven’t talked about that we need to at least mention before we get to the picks?

Eh, I think we’re good.

Yeah, that’s fine.

[Inaudible] questions.

If the community wants to get involved with io.js or know what’s going on with the tech council, committee, whatever you call it, or just in general ask other questions about io.js, what are the best ways to do that?

You can go to the GitHub repo, which is github.com/iojs/io.js. Also, we have a pretty active Twitter account where we post out updates each week and anything really cool, or people moving to io.js.

Atom Editor moved to io.js last week, so we were tweeting about that a bit.

Oh, cool.

Yeah, so that account is official_iojs.

Alright. Let’s go ahead and do picks then. AJ, do you want to start us off?

So, I’ve got two things picked this week. One, I found out about the Raspberry Pi 2 and I’m super excited. It’s a quad-core ARM 7 processor with 1 gigabyte of RAM. The form factor is exactly the same. So, any of the cases that you have for the B+, the B+ and the B are different, but anything that you’ve got for the B+ or the A+ should fit the two.

And I’m also going to pick, now one of you guys, Isaac, Mikeal, is going to help me pronounce this.

How do you pronounce Fedor’s name? Fiya-dor, Fay-dor?

It’s like few…

Few-dor.

Like there are not a lot of doors. There are a few door.

Few-dor?

Few-dor.

And how do you say his last name? Indutny?

I’m not sure.

Alright.

But I believe it’s in-dyut-ni.

Okay. Well, I’m just going to go with Fedor. I’m going to pick Fedor because this week I ran into a bug in io.js and also in Node 11 and probably in Node 12 because I doubt it got pulled in from io.js yet. That is, with reading SSL certificates that somehow occurs when you’re using SSL certificates. So, if you’re using the HTTPS module to server and you’re also reading SSL certificates, say with the request module, connect to Facebook’s API or something like that, there are certain certificates that have read errors. And I don’t understand what happened but I was able to explain it to him and show him some code and stuff. And I had a patch from him within 12 hours and my code was working. And I was so happy. So, I’m picking that man because he is the man.

Oh, man.

Fedor’s amazing. He did all the OpenSSL binding work and he also works on libuv and he’s also a FreeBSD kernel contributor and did a lot of their dtrace probe work. And also when heartbleed happened, he won that little contest that was like, “Hey, prove that you can do this with that.” And he did.

Oh, and he wrote the nat-upnp module so that you can get your Raspberry Pi to get its ports forwarded to itself. So, this work that I was doing, I came across his work two or three times.

So, does he [sleep]?

Are there Chuck Norris jokes about Fedor?

He definitely is one of those developers that if you get into the weeds on some of these projects, you’re like, “Oh hey, he wrote that.” And you’re chugging along, hacking along. Oh, I need a thing that does… oh, yep, he wrote that, too. And like, oh, I found this bug. I wonder if there’s a fix anywhere. Hmm, yup. It’s like it says if you’ve done this before. [Chuckles]

Alright. Joe, what are your picks?

Alright. So, I got three picks today. The first one is the book that we talked about earlier. I totally want to pick that book, ‘Seven Languages in Seven Weeks’. Awesome book. Anybody who’s a developer should absolutely read it just to open up your mind to the fact that there’s a lot more ways to skin the programming cat than simple closures in JavaScript. So, I definitely want to pick that book.

I also stayed up way, way, way too late last night. Running on three-and-a-half hours sleep today because of the game Legendary Encounters which is a card board game set in the Aliens universe which I absolutely love, the Aliens movie. Not the other ones, just that one. But it’s a super fun card game. I had a lot of fun with my friends. Super, super hard to beat. It’s a coop game, just tons and tons of fun.

And finally I want to pick a Pluralsight course in stable [inaudible]. It’s not mine. It’s called ‘The Dark side of Technology Careers’ which was done by Dan Appleman. And it’s really awesome. It has modules like, ‘Newer isn’t always better but is definitely more profitable’ and ‘if it ain’t broke, throw it out anyway’ and many other awesome topics covered in this course. So, if you have time I highly recommend you go and check out his course. And when you’re done with that you can go check out mine.

It’s like if your heart isn’t shriveled into a cold pit of cynicism already.

[Chuckles] Exactly.

Have you seen mine?

It’ll open your eyes.

[Chuckles] Your heart?

Yeah, it’s already shriveled.

Already shriveled.

It’s too shriveled, I can’t see it.

Does it look like an apricot pit, Chuck?

Worse.

Alright. Jamison, what are your picks?

I have two picks. The first one is the CodeNewbie Podcast. It’s a podcast by somebody named Saron. She interviews developers. Sometimes they’re newer developers. Sometimes they’re more experienced. But the audience for the developers is, or for the podcast (excuse me), is newer developers or people looking to get into software development. So, it’s a very different perspective than most of the technical podcasts I listen to, which are usually finding people that are experts like Isaacs and Mikeal and you talk to them about some subject in-depth. It’s still really valuable to me though as someone who kind of already knows how to code. It’s really well made and they talk about things that I don’t hear about in other places.

The next pick is an album called ‘We Are Rising’ by a group called Son Lux. It’s like post-rock with vocals. So, it’s mellow instrumental with these dramatic dynamic changes. If that sounds like your thing, it’s really well done. And I really like it. It’s been my programming soundtrack for the last few days. Those are my picks.

Alright. I’ve got a couple of picks this week. I did get an iPad Mini. It’s an iPad Mini 3 and I absolutely love it. So, I am going to pick that. I also got the OtterBox Defender case and I’m going to pick that as well, because it’s super awesome.

And then one thing that I’ve been doing lately that… so my kids especially my little girls, they get really upset when my wife tries to do their hair in the morning when they’re going to school. And so, the two things that really help with that are I have a JAM pop speaker and I’ll put a link to that in the show notes. But it’s about as big around as a can of soda and about half as tall.

And the other pick I have is the Frozen soundtrack, because I start playing songs off there and they stop yelling and screaming and crying and fighting with their mother.

So anyway, so those are my picks. Isaac, what are your picks?

So, my first pic is nan which we mentioned before. It’s Rod Vagg, rvagg/nan on GitHub. That is how you make binary modules that work on all versions of Node that matter, including io.js. And it’s named after an Indian bread and one over zero. Sorry, not one over zero, zero over zero. Anyway, so that’s great. Or if you do plus ‘asdf’ in JavaScript, plus and then the string ‘asdf’ it will tell you

NaN.

My second pick is an event that I’m very excited about. It’s the second of its kind but it’s the first to be announced in this way and sort of official, which is Karaoke JS. That’s happening this Sunday. So, I don’t know. It’s probably going to go out before this podcast hits the air. So, sorry everybody. You missed it. But hopefully there will be another one if you’re lucky. So, go to karaokeJS.club. That’s the website. And you can go and sing karaoke with other JS people. And there are no talks or business stuff. It’s not for work. It’s just for fun.

My last pick is if you go to npmJS.com/jobs, we are currently hiring. We’re looking for a registry engineer, which is sort of server-side dev ops-y supporting the thing that supports the Node community. So, that’s really fun. And the…

Aren’t you looking for Ruby developers, too?

You know, I’m not going to hold it against somebody if they’re a Ruby developer. [Laughter]

That’s a perfectly fine way to spend part of your time. It’s a great hobby. [Laughter]

Oh my god. I’m going to get so much email. So, the other thing that we’re hiring for right now, we’re actually building out a dedicated support organization. Right now, up until now originally tech support for npm was just, I put my email address in the error messages and I got lots of emails about it. And then we’ve since grown that to having some engineers spend a portion of their time on doing tech support. And now we’re actually at the point where we’re like, “Okay. We need, this task is outgrowing being a side project.” So, we’re hiring fulltime support people to do tech support. And I’m actually really excited about that. It’s one of the first jobs in tech that I ever had, was doing tech support. And now I’m going to be back to managing a support department. And I’m really looking forward to it. I think that it’s a good opportunity to really make a huge impact and get a lot of understanding of how Node development works and how to solve all these technical problems that people run into with npm.

Alright. Mikeal, what are your picks?

So, the main one and probably the most important one is NodeConf, NodeConf.com.

NodeConf.com is the best conference of the whole year. I run it. We’re having it here in Oakland at the Historic Fox Theater. So, you can go get your tickets right now at NodeConf.com. And that’s it I think.

But no, no, no, no. I got a new awesome device. Just got it. It has a calendar and it has all of these crazy things on it. There’s a web browser. It’s called an iPhone 6. You guys should check it out. Consider it, if you haven’t heard of it yet. It’s really awesome. [Chuckles]

It’s like living in the future.

It’s weird that they would just make a whole new device and start it at 6.

Yeah, yeah.

It seems like odd branding.

How does it compare to Android or Emacs or other operating systems?

I heard it… well I haven’t used those exactly. But my friends tell me that it’s like those but it works. [Laughter]

I heard that it’s actually the next version of Android.

Well, like a fork of it.

Yeah. [Chuckles]

It’s the io.js of Android. [Chuckles]

That’s why it starts with 6. [Laughter]

It’s also why it’s called iOS. They just dropped the java. It’s like io.js without the Java, basically.

Right.

So, close to the metal, lean and mean, kind of.

Yeah. It’s like when Mikeal says io.js and his connection cuts out for a second.

So, is the tagline ‘All Script, no Java’? [Laughter]

All about that script, ‘bout that script, no Java.

Alright. Well, I think we’re done. Thanks for coming, guys. I really appreciate, I think we all really appreciate hearing about io.js and just getting the real deal from you guys about what the project’s about.

Yeah, it totally cleared up some misconceptions for me.

Yeah, thanks so much.

And helped me understand.

Alright. Well, we will wrap up the show then and we’ll catch you all next week.