097 JSJ Gulp.js with Eric Schoffstall

Download MP3



01:47 - Eric Schoffstall Introduction


Next Week

Assemble.io with Brian Woodward and Jon Schlinkert


AJ:  Frosty the code man. [Laughter] AJ:  Was an Angularian soul. [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]   [This episode is sponsored by Peer60 Incorporated. Peer60 Incorporated knows that the best JavaScript developers hone their skills by listening to JavaScript Jabber podcasts. If you’re looking for a frontend or full-stack development opportunity, helping Fortune 100 companies understand their customers better, email jobs@peer60.com.] [Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now, you can join the action at our membership forum. You can sign up at JavaScriptJabber.com/jabber and there you can join discussions with the regular panelists and our guests.] CHUCK:  Hey everybody and welcome to episode 97 of the JavaScript Jabber Show. This week on our panel, we have Aaron Frost. AARON:  Hello. CHUCK:  Jamison Dance. JAMISON:  Hey friends. CHUCK:  AJ O’Neal. AJ:  Coming at you live from the wonderful summery winter land, Provo. CHUCK:  Joe Eames. JOE:  Hey there. CHUCK:  I’m Charles Max Wood from DevChat.TV. And we have a special guest this week and that is Eric Schoffstall? ERIC:  Schoffstall, yeah, coming at you from the even sunnier Phoenix. AJ:  Oh, nice. CHUCK:  Yeah, I bet it’s warm there. I could use some warmth. Do you want to introduce yourself really quickly? ERIC:  Yeah. I’m Eric. I go by Contra on GitHub and most other places, actually. Been doing Node for three years, somewhere around 160 Node modules at this point, creator of GulpJS, and cofounder of FRACTAL which is a consulting and training company. CHUCK:  Cool. JOE:  Wow. CHUCK:  So, is GulpJS a project of yours or is it a project of FRACTAL’s or is it more of a community effort or what? ERIC:  It’s a project of FRACTAL. I’m really the only core contributor to it though. We publish all of our open source stuff under the company. CHUCK:  Okay. But this is under GulpJS/Gulp. ERIC:  Yeah, licensed under FRACTAL. But it is its own organization and everything. CHUCK:  Okay. AJ:  Gotcha. CHUCK:  So, do you want to explain briefly what it is? I know most of us are at least familiar with what it does. ERIC:  Yeah, absolutely. So, how familiar are you guys with Node streams? AARON:  A little bit. JAMISON:  Familiar. ERIC:  Yeah, familiar? JAMISON:  There might be people listening that aren’t, though. ERIC:  Yeah, so Gulp is the streaming imperative versus declarative. So everyone here is familiar with Grunt, right? You define this big JSON config object and that’s supposed to tell the Node stuff, “This is my files. This is what I want you to do with the files.” Gulp inverts that. And you are actually the one describing what needs to be done to every file and every step along the way. So the stream stuff, everybody emphasizes the stream stuff a lot. It’s only a minor part of it. It’s really an inversion. Though, the main decision with that is an inversion of what Grunt is doing. AARON:  Okay. CHUCK:  I think I’m more confused. [Laughter] JAMISON:  For example, with Grunt you define these big config files and the way you set up your build or the way you set up what you want your Grunt file to do is by creating objects that have special keys that have values that are also nested objects. So basically, you’re not writing code that does something. You’re setting up [a bunch of] configuration. ERIC:  Yeah. JAMISON:  And with Grunt, you write functions that do stuff. ERIC:  Yeah, with Gulp you just write the code to do stuff. JAMISON:  Sorry, yeah Gulp. ERIC:  And Gulp is just a tool to help you write the code to do stuff. AARON:  Okay. CHUCK:  So, it’s like brainwork I guess or common tasks or common types of tasks? ERIC:  Yeah, you can call it something like that. AJ:  So, what I want to reduce this to is basically you use stream and promise-like magic to make asynchronous tasks look simpler on a line-by-line structured file? ERIC:  So, Gulp actually doesn’t use promises. Some people lump streams and promises together, but they’re a completely different thing. So, Gulp uses streams as a part of its plugin interface. Gulp itself actually, the code doesn’t really do a whole lot. You’ve got your source stream and your destination stream. And then you’ve got a way of defining tasks and that’s pretty much all there is to it. Everything else is a set of guidelines for what’s the best way to make a streaming plugin. And the ecosystem takes over from there. AJ:  Are you using streams1, streams2 or streams3? ERIC:  Right now, we’re using a mix of streams1 and streams2. But currently, we’re trying to get everything over to streams2. AARON:   What’s the difference? Can you guys explain to those of us who don’t know, between streams1 and streams2 AJ:  So, streams1 is what everybody’s familiar with. That’s what every module is written in. JAMISON:  Well, some people might not know what streams1 are, if you’re not [in development]. AJ:  So, the streams is just a triggered event. So, you register an event with .addEventListener which is aliased as .on and you remove an event with .removeEventListener which is sometimes aliased as .off but I think in the Node core module, it isn’t in streams1. And so you have an event like open and that lets you know that the file handler’s open. Then you have an event like data and that lets you know that you get a chunk. And then you have an event like end that lets you know that this stream is complete. And so with streams2 they switched it up a little bit because what happens is when you want to write to a file on the file system, you have to wait for the buffer to flush before you start writing another hundred megabytes of file. Otherwise, what you do is end up with a vulnerability on your server that’s a denial of service attack through memory allocation where somebody could write a bogus response to your server that is a gigabyte response. And they can write it to your server faster than your server could write it to the file kind of thing. And then you explode the memory. Or just in general, bad use case, you don’t ever check to see if your buffer is flushed and you just keep on stacking on and you run out of memory. So with streams2, they changed it up a little bit so that instead of, and I haven’t really used it, but once or twice for a demo tutorial type purpose. But they use a read and instead of using a data event, they use read and then onFlushed or something like that so that it’s easier to do it the right way instead of taking brain effort to do it the right way with checking the buffer queuing. Feel free to correct me, those of you that have used streams2 and are more familiar with it. ERIC:  Yeah, so I think to boil that down a little bit. Streams1, let’s say we have A and B. We pipe A to B. Streams1, A just throws data out and B listens for it. In streams2, B actually reads the data from A and has more control over how the reading happens. So I think that’s just a simpler way to put it. Streams2, Isaacs has described it as SuckStreams. So streams suck data out of each other instead of throwing data at each other. AJ:  Beautifully said. JAMISON:  I wanted to back up a little bit and talk more about some broader questions about Gulp. Grunt existed when you started writing Gulp, right? Do you want to talk about why you wrote Gulp? ERIC:  Yeah, absolutely. JAMISON:  What problem it’s trying to solve and what the differences are? JOE:  Yeah, tell us why you hate Grunt. Tell us [inaudible]. AARON:  Yeah, what were the downfalls with Grunt? Why did you pick to build a whole new ecosphere build in JavaScript if Grunt was already there? ERIC:  Okay. JOE:  Yeah, why are you saying that Grunt is the worst thing ever? [Laughter] AJ:  Yeah, why? AARON:  Why do you hate Ben so bad? [Laughter] ERIC:  So here’s the thing. I don’t actually hate Grunt. I think that there are some pros to Grunt. And you know, I used to use Grunt a lot. I’ve had a lot of experience with it. It was really nice while it lasted. But it’s one of those things. As a programmer, you just always want things to be the perfect form of it. AJ:  Yeah, I’m hearing it as, “It’s got some cases where it’s good, but not enough of them. Good while it lasted. Yeah.” ERIC:  Yeah, well the thing is though, Grunt is a lot better than what was out there at the time, but it can keep getting better. So, I like to think of Gulp as like the next evolution of it. How many times have you had a bug with Grunt as well where you go and you try to trace it down? And the thing is just overly complex, in my opinion. I think that a lot of people just want something that’s simpler, that gives them more control and is faster. By giving people more control, they can say when they want to hit the disk, when they don’t want to, and it just is faster due to that. AARON:  Cool. So, one of the cool things about Grunt is the community’s gotten involved. And we have hundreds and hundreds of plugins at this point to where anything I really need to do is mostly already built. And at this point, I just have to configure it a bit. So are you guys doing the same kind of thing? It looks like you guys have some gulp-concat and some default plugins. Do you call them plugins? How are you guys approaching that? ERIC:  Yeah, so a Gulp plugin is really actually just a stream. So the plugins aren’t only for Gulp. You can use them with any streaming thing. So the fact that you can just reuse these things wherever doesn’t make them a Gulp plugin, but we still like to call them Gulp plugins, just because they were made specifically for Gulp. But yeah, we have a plugin ecosystem. But we actually have this ideology that people shouldn’t be making hundreds and hundreds of plugins, that you should make plugins only for what’s needed and just use standard JavaScript Node practices to do the rest. JOE:  So, what you’re saying is you also hate NPM? [Laughter] JOE:  Sorry. ERIC:  No, I love NPM. And that’s why I don’t think people should make hundreds of whatever-something plugins. It’s polluting npm and creating silos of packages that can’t be reused in anything else. AJ:  Very well said, very well said. JAMISON:  So the other thing that’s nice about Gulp, or one of the other things, is your Gulp file is just a Node program. You just require modules and you call them. Grunt abstracts away the Node package system. You have load grunt task from npm. I don’t know. I’m not a Grunt expert, but I used it enough to experience a little bit of pain because it throws away all the knowledge I have about how Node works. So it’s a lot more explicit in how you set your Gulp files up.  And for me that’s a bonus. Some people don’t like that. AARON:  Yeah, so that could be, depending on who you are, a bonus or a weakness. If I’m not a Node guy, let’s say I’m a backend guy just trying to zip up my frontend or something, the abstraction might be appreciated. I don’t know. ERIC:  Yeah, so that’s a complaint we get a lot, is people say, “Hey, I’m a designer. I don’t know Node and I don’t really care about learning it. How do I use Gulp?” And this is a problem we still have. I know people are working on declarative layers on top of Gulp and I think that that’s going to solve that really well. I actually have a link that I can drop to that. It’s called Gasp. It’s an experimental project I’m working on. And it just takes a JSON object and then generates all the Gulp tasks and all the plugins and everything in the way that you defined it. And this lets a whole new class of people come in and use this without actually having to know Node. JOE:  Do you think that Gulp is any better or worse than Grunt when it comes to that? ERIC:  When it comes to that, Gulp is really bad for designers. And I’ll just come out and say that because it is code. You have to know how to program to use it. But I think that Gulp is so low-level that a whole new set of build systems can be built on top of it, like Gasp, or I know a couple of other people who are working on declarative layers. So I think when those start coming out, not only will they be faster than Grunt, but they’ll probably be just a lot cleaner and even more declarative than Grunt. So I think that at that point, there won’t be any excuse. JAMISON:  So, you’ve mentioned faster than Grunt a couple of times. Do you want to talk about what makes it faster? What speeds it up? ERIC:  Yeah. So, with Grunt, let’s say we have three tasks for a set of JavaScript files. We want to minify them. Actually, let’s say some CoffeeScript files. We want to compile the CoffeeScript, we want to minify it, and then we want to put it in a folder, right? So, with Grunt you actually have to define those two tasks, CoffeeScript compilation and minification, as completely separate things. They take in files and they put out files. So, you can say the problem with that is you’re hitting the disk a lot more than you need to. You’re reading and writing twice for all the files. So if we have a hundred files, you’re now doing 200 reads and 200 writes when really, it should be 100 reads, 100 writes. So you end up with this whole mess of temp files on disk. And I’m sure everybody’s experienced this. I like to call it Grunt hell. We’d have all these temp folders that you’re writing to and cleaning up when you’re done and you’re just moving files around. And there’s a lot of file system state that you have to watch out for when you’re using Grunt. And I think Gulp solves that by doing everything in memory. So, you’re actually not doing as much I/O and that’s why it’s faster. JOE:  So, just going back to the whole make and gcc optimized in memory compiling. I like it. AARON:  Yeah, I like that too. I didn’t know that that’s what it did. But I can see how that can be wicked fast by comparison. JAMISON:  I think Grunt gets a bad rap a lot of times for speed. So, that definitely is faster, not having to write a bunch of files. A lot of the speed problems come from the specific plugins as well though. So, if you use a faster plugin, your stuff will be faster. And that’s common to Gulp and Grunt. ERIC:  Yeah, that’s definitely a problem, no matter what system you’re using. JAMISON:  But yeah, having it optimized around streams solves a lot of problems, especially if you have a lot of steps that your builds go through. AARON:  Yeah, that’s true. ERIC:  Yeah, the more steps you have, the faster Gulp is going to be than Grunt, is what it boils down to. JAMISON:  Oh, I just saw Aaron posted in chat, gulp-grunt. There’s also a grunt-gulp. What do you think about that? So, people can call a Grunt task from Gulp or Gulp tasks from Grunt. ERIC:  Yeah, so I’ve been talking with some people. There’s an organization called Node Task that is about interop between build systems. So, we’ve been talking about it and there have actually been some blog posts too of people using Gulp within their Grunt plugins to make it faster. So I’m all for that. If people want to use Gulp inside of their Grunt plugins to make it faster, please. It’s open source. Anything, just use it. JOE:  But how do you personally feel about that? Do you think that’s a good idea? ERIC:  I think if you really are stuck on Grunt and you want to make it faster, if you want to use Gulp inside of it, I have no problem with it. I think there could be even a future where Grunt was rewritten to operate on top of Gulp. AARON:  Yeah, that’s what I was thinking. I was like, “What if these Gulp plugins are just stream-based plugins and what if people use the declarative layer that is Grunt on top of your Gulp stuff?” Would that be a really, really bad thing? ERIC:  No, absolutely not. And that’s what I meant earlier. People are already working on declarative layers on top of it. I think that it makes it more accessible. The problem with Grunt is really not the declarative layer. It’s the way that it was designed in terms of the way that it functions and the way that its tasks work. One of the big problems I have with Grunt is there’s no difference between a plugin and a task. They’re the same thing, essentially. And I think that that’s wrong. JAMISON:  What do you mean? Can you talk more about that? AARON:  Yeah. ERIC:  Yeah, so when you have an uglified plugin or task in Grunt, they’re the same thing. You can not really use uglify in multiple places. It’s one thing. You specify all the input files and all the output files. There’s no distinction between multiple things that you would want to use that for. AARON:  Gotcha. So, they mitigate that through putting different targets inside the uglify target itself, like having subtargets. You guys get around that just by I require the uglify plugin and then I use it wherever I want and that’s how you guys get around having that limitation? ERIC:  Yeah. There’s no limitation with Gulp because it’s just a standard Node module that you can reuse. And you can define tasks. So, the plugins and tasks are completely separate entities. AARON:  That’s true. I can see that too. JOE:  So, one of the things that I really like about Grunt is that the whole target convention, naming convention type thing where you can specify a single target or multiple targets or multiple in and multiple out type of stuff, they have the standard way of dealing with it so that I don’t have to quite do so much configuration. Does Gulp have anything analogous to that? ERIC:  For doing, could you elaborate on that a little bit? JOE:  Well, let’s say concatenation. Normally, you think, “Oh, I’m only going to concatenate to one file,” but you might want to concatenate to multiple files. Or if you want to, say bring in 20 files and say, uglify each of them separately, then you want 20 output files. ERIC:  Yeah, so that’s one of the things that is really great about just using standard Node stream stuff, is that these tools already exist and they’re not specific to Gulp. So, utilities for forking streams, rejoining streams, all that’s already there. So, that control flow at the stream level already exists within the Node ecosystem. So we didn’t have to reinvent any of that. It’s there for everybody to use. JOE:  Gotcha. You’re definitely saying it’s more flexible. Would you say that it’s easier than it is in Grunt? ERIC:  Yeah, I would definitely say it’s a lot more flexible. In terms of ease, it depends who’s asking. So this goes back to the declarative versus imperative stuff for defining control flow. I think it’s easier. People who are really sold on declarative stuff may not. And that’s where I think that these declarative layers are going to come in and change those minds. JOE:  Gotcha. Why did you choose to go with non-declarative? ERIC:  Because I’m a programmer and I like to write code and not config. I think writing config is just very tedious. And as a programmer, I also like to have control over everything. So I think that, how many times have you found yourself programmatically generating your Grunt file? Most of our Grunt files are actually just code generating the Grunt file for all these different things just due to the limitations with declarative stuff. So I think that by going with imperative, it gives you just a whole new level of control and freedom to do what you want with your stuff. JOE:  I truly appreciate the disdain with which you made that statement, “I’m a programmer.” [Laughter] JOE:  I kind of picture you then following up with, “I threw it on the ground.” [Laughter] AJ:  I hope that you like our trolling. It’s all in good fun. JOE:  Yeah. ERIC:  Oh, I love trolling. I’m the biggest troll there is. JAMISON:  I’m personally a big [inaudible]. JOE:  I guess I kind of got that already. JAMISON:  No, I’m a big fan of Gulp. It fits my brain better than Grunt. I don’t want to say that it’s better than Grunt, but for me it works better. JOE:  That’s because you’re a pansy. Does that mean that it’s egg-shaped? [Laughter] JAMISON:  I don’t know what that means. JOE:  Well, I’m looking at a picture of your head. [Laughter] CHUCK:  So, I guess we’ve talked a little bit about how it’s set up through code and geared toward people who want to write code for their tasks. And it takes advantage of streams, which I’m still a little bit fuzzy on but I’m going to go read the substack stream handbook that is listed on the Gulp page. Are there any other major advantages to using Gulp over Grunt? ERIC:  So, I think just to boil down what we’ve talked about, it’s easier for some people and soon to be easier for all people. It’s a lot faster and it gives you more control. Those are my top three. I think that there’s a lot of stuff in the ecosystem, like we’re really strict on our plugins. We will blacklist your plugin if it’s not good. So you can be sure that our entire ecosystem is very cohesive and good. So, I think that other than that, it’s just personal preference. AJ:  So, I love that you use words like right and wrong and good and bad, because so many people come on the show and they’re all PC, PC, PC, and I’m all like, “Heck yes.” Just say it like it is for once. [Chuckles] AARON:  So, I have a question. I have a Grunt background. So, Grunt has this idea where they have the CLI, which allows you to have multiple, so you have the global CLI and then per project, you install your specific instance of Grunt. And that allows you to have multiple instances of Grunt runnable on the same machine. Does Gulp have something for the same thing so that when I upgrade one of my projects to the latest version of Gulp, I don’t have to upgrade retroactively all my older projects to the latest version of Gulp? What is you guys’ plan on that? ERIC:  Yeah, we have that. So, we don’t use a gulp-cli thing like Grunt does. You still install Gulp globally. But we do support that still. So, your global Gulp version is your CLI. That’s all it’s used for. And it just runs whatever’s in the local folder, the same one as your Gulp files. So, you can maintain two separate versions. If you need a new feature on the CLI, you can update your CLI for that. But the actual local Gulp is completely separate. AARON:  So, when you say local Gulp, are you talking about gulp-util or do I install Gulp globally and locally? ERIC:  Globally and locally. AARON:  Gotcha, okay. JAMISON:  Gulp-util, if I understand it right, is more for people writing plugins. It’s not required to just run Gulp. ERIC:  Yeah, and we’re getting rid of that soon. That was just something to hold us over until we had the acceptance tests completed. AARON:  Cool. So, I’ve never seen the library. Well, I installed it globally and locally. That’s cool. I like, that makes it easier to explain on how to install, so that’s cool. JAMISON:  I was talking to a couple of people that use Gulp and they like it. They had a couple of I guess complaints or questions. One of them was about errors in tasks and Gulps behavior in that case. Do you want to get into nitty-gritty stuff like this? ERIC:  Yeah, so that’s one thing that we’re having a lot of issues with right now, is error management. We have some smart people working on it. Rob Richardson, the guy who basically wrote the entire task system. So, the task system is actually a module called orchestrator. And that’s where you define your tasks and it works out the dependency graph and everything and runs everything with maximum concurrency. So that’s where all the error management is as well. So, I think that while we are having trouble with it right now, the next version of orchestrator should handle everything really great. And I think that that’s not going to be an issue in the future. JAMISON:  Do you have a timeline on that? ERIC:  So, he’s working on it on a branch right now. I haven’t really pestered him about a timeline. So, currently we’re doing, you can wrap your streams and stuff to handle the errors. But I’d like there to be better handling at core. I’m not sure exactly when. I would say at least by the end of February. JAMISON:  When you say you can wrap your streams, you just mean the default onError listener stuff in Node streams? ERIC:  Yeah, so you can either listen for the error event or you can wrap. There’s a module called multipipe and that actually replaces the .pipe keyword too. So not only do streams emit error events but when they encounter an error, they’ll emit an unpipe event, which is a huge problem for what we’re doing because that causes everything upstream to stop sending data. So what multipipe does, and there are some other modules, like gulp-plumber has actually blocked that unpipe event. But what we want to do is make sure that our plugins don’t emit that event. So, we’ve actually altered our plugin guidelines for that. And we’re making sure that everybody gets up to date and we get rid of that. JAMISON:  Cool. That makes sense. CHUCK:  So, if somebody wants to contribute to Gulp, what do they need to do? ERIC:  Yeah, so we actually have a really great document for that. I know Jason Denizac, if anybody knows him, jden on Twitter, wrote this really great contribution guideline document. So, it actually is a boilerplate for telling people how contribute. And we can list what we want here, code of conduct, communication, frequently asked questions, all that kind of stuff. So, documentation is a huge thing that we need help with. Everybody loves to submit pull requests, but nobody ever wants to document anything. [Chuckles] I think that programmers just hate writing documentation for some reason. Me included. So, our docs are lacking. Recipes, blog posts, just any documentation would be appreciated. So, if you would like to contribute docs, we’re open to pull requests. AARON:  That’s awesome. JAMISON:  So, that’d be a good way to maybe get started if you’re not super comfortable just diving in and writing code, is starting with docs. ERIC:  Yeah, so we actually have a section of docs called recipes. And these are just, “Hey, I used Mocha with Gulp. Here is a task that I used it in and let me explain why I did a couple of things.” So that way, people can just say, “Okay, I want to use Mocha. Let me go look at the recipes and go find one for Mocha.” And it’ll explain in-depth why they did what they did, how to use it, stuff like that. So, I think that recipes are really great for beginners and we need more of those. So if you’re using Gulp, go put your tasks on the recipes list so other people can see them. JAMISON:  Cool. Are there any questions that you wish we had asked you about Gulp that we didn’t? Any, just softballs that you want to knock out of the part? ERIC:  So, somebody asked about blacklisting earlier? JAMISON:  Oh yeah, I wanted to talk about that. ERIC:  Yeah, so we’re really strict on our plugin authors and I think that it’s turned out great for us. We actually have extremely strict guidelines that we call our plugin guidelines. But we’re also going to have acceptance tests soon that will actually score every single plugin based on the plugin guidelines. So, anything that is below a certain threshold will not show up on a plugin search. And we also can manually blacklist plugins to make sure that people only discover the good plugins that we, I wouldn’t say approved, but say that they’re high-quality and they do what they’re supposed to do correctly. JAMISON:  So, you’re obviously not talking about npm then. There’s some other kind of search to find this stuff? ERIC:  Yeah, so we have our own plugin search. If you want to install a plugin or put whatever you want, gulp-crappy-thing on npm, you’re totally free to do that. I can’t stop you. But in our plugin search, we don’t want to show duplicate plugins, really bad ones that shouldn’t be Gulp plugins like gulp-connect or something or gulp-requirejs when you could just use those modules directly. Mainly because we don’t want to create, we’re really, really trying hard not to make a silo of stuff that is just worthless abstraction over stuff that’s perfectly fine as Node modules. And I think that Grunt created this whole thing of hundreds of modules that aren’t really useful outside of Grunt. We’re trying not to do that. AJ:  So, I do agree that it’s weird how, it feels like for everything, you have to have a grunt module. And a lot of times, it’s just, “Okay so I take this boilerplate that I’ve copied and pasted and now I’m just going to change the name of this module for this module,” kind of thing. It’s really, really, really short and simple. But maybe it would have been easier just to use the module directly like what you’re saying. ERIC:  Yeah. So like RequireJS for example, pretty much our basic guideline is don’t make a plugin for something that can’t deal with in memory files coming in. So RequireJS for example, their API does not let you just say, “Oh here’s a file. Compile it.” Just due to the way that it works, you actually just give it a folder and it will go through and compile everything. So obviously, a Gulp plugin is not a good fit for that. So, anytime somebody goes and publishes gulp-requirejs, we go open issues and say, “Why’d you do this?” dah, dah, dah. If they don’t listen, then we’ll resort to blacklisting it just to keep those bad actors out of the ecosystem. JAMISON:  That’s really interesting to me, because I know npm has been talking about some kind of tools to make discovery easier on modules. So there’s a trillion billion modules. I don’t have the numbers right now. But the metrics for finding which ones are good are basically how many stars on GitHub does it have? And they’ve been talking about doing things with automated testing or some kind of social thing where some people’s stars count more than others and stuff like that. But it sounds like you guys are the first people that I know of that are actually doing it. AJ:  Curating. JAMISON:  Yeah. ERIC:  Yeah. So, we’re curating it. We don’t just come out and say, “Oh this plugin sucks. We think it’s stupid. You’re not allowed on our website.” But we do say, “This plugin doesn’t work,” or, “It has too many bugs. It just shouldn’t be a plugin. And those are our requirements.” So, I think that acceptance tests in that way, so right now we’re doing everything manually but we do have tables set up. And I linked that as well. GulpJS/acceptance on GitHub. So, we have all these different criteria that we can actually just go through your code and statically analyze if you’re doing any of these things. So, I don’t know how npm would enforce something like this for all modules. But I think for Gulp we’re able to do it because we know what’s right and wrong for plugins. So yeah, for example if you console.log something, you get a deduction, five points. You should use the gulp-util log. That way, people can trace everything through. If your string doesn’t behave correctly, you get points off. There are a couple of things there. If you use colors, the module, you get points off because that overwrites the global stream prototype, which is bad. We just have all sorts of different criteria like this. AJ:  Dude, this is awesome. I love that. That is so awesome. JAMISON:  Can you change them from points to demerits or something? Just some goony arbitrary [inaudible]. That’d be cool. [Laughter] ERIC:  Yeah, the deduction points… JAMISON:  You get five demerits. ERIC:  From that are actually totally arbitrary. I just like, “Oh, this looks kind of severe. Ten I guess? Five? One?” I think that we’ll want to get rid of the point system and it’ll just be one deduction, five deductions, something like that. AJ:  Yeah, well that’s what we want, is a cool name. It’s not how many the points are that’s arbitrary. We want the name to be something arbitrary. ERIC:  Yeah, demerit. That sounds great. AJ:  Like demerit or gorgons or pestles or I don’t know. [Laughter] AJ:  I’m not really good at gibberish English. JAMISON:  AJ is available for hire if you’re looking for branding, basically. That’s what he’s trying to say. ERIC:  Yeah, we could name it something awesome. [Laughter] ERIC:  Anybody out there, if you have any word suggestions, please pull request. Any new word, it doesn’t even have to be real. AJ:  Maybe we could call it stools. Like you get five stools for doing something bad and ten stools for doing something mega-bad. AARON:  Stool. It’s applicable. [Laughter] CHUCK:  Alright, well if we’re done talking about crap. JAMISON:  [inaudible]. We just wait to talk about it. AARON:  So, I’m actually pretty excited about Gulp as well. It looks like, I feel like it serves some developers better than Grunt does. And I feel like Grunt may serve other people better as well. I’m excited that Gulp plugins are built to be easily runnable in Grunt. And hopefully, I think Gulp’s existence will ultimately, I don’t think it will push Grunt out. I think it will make Grunt be better, which will also make Gulp start to get better. So, I’m actually excited we have a second option that’s wicked powerful, because I think it will ultimately push both of them to become better products. So this is cool. I’m excited. JAMISON:  Here, here. CHUCK:  Awesome. Any other questions or comments before we get to the picks? JOE:  Is there a favorite tutorial of yours out there about using it, learning it? ERIC:  Yeah, so there’s a Lara, I don’t know, how do you pronounce this? Laracasts something? They have a very cool Gulp thing. It’s a video tutorial. So it’s Laracasts.com/lesson/gulp-this. And they have a really good tutorial up there. I like it a lot. So, I think that if you are interested in learning it, go check that out. We also have a list of tutorials in the documentation, lots of blog posts and stuff in there. So, if you’re interested, just go check out the list. JAMISON:  My friend Murphy just did a presentation on Gulp and it was really good. He has his slides up, and I think his slides are even built with Gulp. So, it’s like a dogfooding thing. So, I can put a link to that stuff in the show notes. ERIC:  Yeah, great. If you want to add it to the docs as well… JAMISON:  Oh, sure. ERIC:  We have a list of articles and stuff. CHUCK:  Awesome. JAMISON:  Sounds rad. CHUCK:  Alright. Well, let’s do the picks. Joe, do you want to start us off with the picks? JOE:  You bet. So, my first pick is going to be a book. I just read ‘The Fault in Our Stars’ by some guy. He’s a really popular author. I can’t remember his name. I didn’t read it because of him. I read it because my daughter dared me to. [Chuckles] And it was actually a really good book. It was hard to read a little bit because it was a little bit brutal, but it was also really hard to put down. So, I really like that book. I know they’re making a movie of it. I’m sure they’re going to absolutely destroy it. So, that’s too bad. JAMISON:  So, read it before it gets [inaudible] is what you’re saying. JOE:  There you go, exactly. [Chuckles] JOE:  I also want to pick an iPad game called Castle Doombad. It’s like a tower defense type game where you run like a, you’ve stolen the princess and all the heroes are coming to save her and you have to kill them all before they get to her. [Laughter] JOE:  It’s really quite fun. And then my third and final pick will be the new 24 TV show that was revealed during the Super Bowl. I always liked 24 when it was on TV so I’m totally jonesed for a new 24 TV show. CHUCK:  Awesome. Jamison, what are your picks? JAMISON:  Okay, I have two picks. The first one is an album. I feel like it’s tradition. It’s by this artist called Clark. It’s called Totems Flare. And it’s also, by tradition, weird electronic-ish stuff. I don’t know. I’ve been trying to branch out and find new stuff and this has been some good programming music. My second pick is a talk by Alan Kay called Normal Considered Harmful. Alan Kay is one of the wise elders of computer science. He’s been around forever. I think he was, didn’t he invent Smalltalk? I might be showing my ignorance here. But I think he was involved in Smalltalk. This talk is about how in lots of other fields, you are required to know what has gone on before, before you start producing new stuff. So physics, you know about Einstein’s discoveries and the bedrock that you build your work on. And in computer science, we just reinvent the wheel all the time. And it’s some good stuff. So those are my two picks. CHUCK:  Awesome. Frosty, what are your picks? AARON:  So I’m going to pick House of Cards. It’s one of the Netflix original series. And season 2 comes out Friday. It’s going to be awesome. I’m excited. I’ve always [inaudible] really backed this organization. Not backed, but hoped they would stop sucking and having a new CEO I think might help. So I’m excited for Satya Nadella and I hope that Microsoft can maybe pivot with a new CEO. But then also last night was Tech Crunch had their second annual Crunchies award ceremony and John Oliver was the host and it was hilarious. So if you guys get a second, he roasted all of the attendees and it was pretty hilarious. I’ll put a link so you guys can go check it out. Those are my three picks. CHUCK:  Awesome. AJ, what are your picks? AJ:  So first, I’m going to pick STR8 cologne because I used to use it. And it was formerly only available in Turkey or something and then countries that bought it from there. And I for funsies looked it up on eBay today and found that there’s some dude selling it out of Greece to the US. And so I’m totally going to get some because when I used to live in Albania, that’s the stuff that I bought because it smelled really good. And most of the other stuff was just alcohol with food coloring and maybe a flower petal put in or something to make it smell not exactly like alcohol. So, if you’re into trying a Greek cologne, I’d recommend STR8. Also, I guess this is like a no-brainer, but for some reason I hadn’t thought of this before. But you can use these services that will translate from a phone number and tell you which carrier that phone number is from. So instead of always paying the two cents or the one cent for Twilio to send a text message, you could actually do it via email and send it for free for most people, because most people are either on AT&T, Horizon, Sprint, or T-Mobile. And then the other couple of people that are using Google Voice or Twilio or some sort of other automated/computer-integrated system, then you’d still have to pay, the money’s on Twilio. Anyway, so I made a little Node module for that, that I’ll have up very shortly. CHUCK:  Awesome. Caveat on that, that’s in the US. Some of the foreign carriers don’t do the email to text. AJ:  Oh yeah, the gateways. That’s true. CHUCK:  Just putting that out there. Anyway, I don’t have any picks. I’ve been sick the last day or so. I guess I’ll pick antibiotics because I’m feeling better today than I was yesterday. [Chuckles] AARON:  I pick penicillin. JAMISON:  Modern medicine. That’s a good pick. CHUCK:  So, anyway… JAMISON:  I pick science. CHUCK:  Science. AJ:  Yes! CHUCK:  We love science. Eric, do you have some picks? ERIC:  Yup. I’ve got three, actually. Only one is serious so I’ll start out with that. NodeSchool.io, if anybody has heard of it, they have a good stream adventure, it’s called. It’s a command line learning utility for learning how to use streams. And basically, they start you off on knowing nothing and work you up to knowing how to be a stream guru, like piping request through tar streams and just really cool stuff. So that’s NodeSchool.io, stream adventure. And my second pick is a fedora parkour dubstep remix and I just think it’s funny. So, that’s one of my picks. JAMISON:  What? [Chuckles] ERIC:  My third pick is a video by a very fine fellow named Brandon Wirtz called NodeJS Is Stupid and If You Use It So Are You. [Laughter] AARON:  I’ve read that before. ERIC:  And it’s a really great rant that makes no sense about how non-blocking means you don’t write to the hard drive and all sorts of other fun quotes. So I’ll let you all dig through that and figure out what the best quotes are because there are hundreds of them. AARON:  Dude, I actually watched that and it was wicked painful. ERIC:  Yeah, so there’s actually a whole ecosystem of dubstep remixes of that video. [Laughter] ERIC:  So, I don’t know if I’m legally able to post some of those links. I definitely won’t put them as any of my picks. But if anybody’s interested, contact me. [Chuckles] JAMISON:  You’re part of the underground Node.js dubstep remix market. ERIC:  Yeah. There is one. So, if you’re interested in joining… AARON:  It exists. ERIC:  Or you just want some of the content, join nodejsdubstepremixes on freenode. AARON:  That’s funny. CHUCK:  Awesome. Alright. Well, let’s go ahead and wrap the show up. Thanks for coming, Eric. ERIC:  Yeah, absolutely. It’s been fun, y’all. AARON:  Yeah, good job, Eric. CHUCK:  Alright. Well, I guess we’ll end the show. We’ll catch you all next week.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.