410: Gulp with Blaine Bublitz
We're chatting with Blaine Bublitz, lead at the Gulpjs open source project, about what Gulp is, the lack of money in open source, SVG and Gulp, handling dependencies in Gulp, and what the future of Gulp looks like.
Time Jump Links
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--bundle of fun--Rupert and with me is Chris--compressed and optimized--Coyier. Hey, Chris. How are you?
Chris Coyier: I'm doing fantastic. We have a great guest on. I've never met Blaine before. We have Blaine Bublitz here. Did I say your name right? Hey Blaine.
Blaine Bublitz: You did. Yeah.
Chris: How are you?
Blaine: Yeh. How's it going? Thanks. Thanks for having me. You got it. You got it on the first shot, which is impressive.
Chris: Thank you. Thank you. That's from experience as a radio show host, which is a lie because it helps me none and I'm terrible at names. But anyway--
[Laughter]
Chris: I'm kind of a fan of one of the projects that you work on heavily, which is Gulp. This is going to be a show about Gulp, everyone, at least partially. But, of course, Blaine works on different things and is interested in lots of things, so we'll get into that too, but no avoiding it. Even your Twitter bio says, "Gulp JS Lead," so that's you, man. Gulp.
Blaine: Yeah. Yeah, yeah, that's me. I kind of decided to claim the lead title a few years ago because I was not the--
Dave: Mutiny and insurgency. I love it. [Laughter]
Blaine: Exactly. Exactly. I was not the creator. A guy named Contra created it in Arizona, where I live. I got involved early on, but I was never the lead maintainer or anything like that. I just helped out. For the Gulp 4 release, I was kind of the visionary and the main developer behind that, so I decided to claim that lead dev title.
Chris: Yeah. great. Let's do the due diligence a little bit. Gulp isn't your job-job, or is it?
Blaine: It's not. It's mostly a hobby right now. Before my current job, I actually was trying to make it into a job. I was trying to do different funding avenues and figuring out a way to not only make it sustainable but also help me get by.
About a year ago, I joined a company called Tidelift, which is working on getting money into the open-source ecosystem. It helped that I had a lot of experience in that space.
Chris: That's nice. I would almost call you a developer-developer, in a way. You're one of those developers who builds tools for other developers and even works at a job where the point of that company is to do things for other developers. I'm sure you've built client-facing sites in your lifetime plenty too, but it's interesting now that you're so focused on developer experience things.
Blaine: Right. I never heard it described that way but, yeah, I definitely feel you there. I like building things to make developers more productive and just like developer experience and things like that. It's something that I've been really passionate about for a long time.
Chris: You're at Tidelift, a Gulp JS lead, and let's leave it at that for a minute. This is like an outsider perspective of Gulp because I think it's one of the most interestingly placed tech things in a weird way. That was a terrible intro, but here's how I see it.
There was nothing. Then there was Grunt. Grunt was first and Grunt was like, "You should have tasks. I'll watch your files and I'll run tasks." That was an awakening experience for the dev community. This is a bunch of years ago, you know. That's great.
Then Gulp came along, what feels like to me, after. But I have no idea when their foundation date is, but it seems like Gulp was a new player and somehow took the lead. I don't know how many years it took, but it feels like Gulp at some point got cooler than Grunt. People liked the Gulp approach better, perhaps because, in Gulp, you were just writing Node. You weren't making a configuration file.
When you were just writing Node, it opened up more possibility. If you needed an escape hatch to do something else, it was right there. It just felt more natural developer ergonomically or something.
Then Gulp trucks on. Eventually, Gulp 4 comes out but it seems like there was a lot of time between 3 and 4, perhaps, and that Gulp 4 had API changes and stuff that were weird to people. It feels like kind of that Angular 1 - 2, release, kind of like, "Whoa! This is way different!" kind of vibe. But I get it. There's cool stuff, so maybe we'll jump, maybe we'll upgrade, maybe we won't. I don't know.
But then, even that feels like that was a number of years ago, you know, Gulp 4 a number of years ago. It feels like people don't -- you're not seeing lots of tutorials about Gulp anymore. For some reason, it too, like Grunt before it, feels a little old or something.
If today you were like, "I need to do some stuff with my project files," you're like, "Uh, okay, well, the modern ones that there are a million tutorials a minute written about is Webpack and Parcel and Rollupify," or whatever all these ones are. Those, they feel like they're in a different category because they're all about bundling and both Grunt and Gulp--but Gulp is what we're talking about--just did stuff. It wasn't naturally a bundler. To compare Webpack directly to Gulp isn't fair. They don't really feel like the same thing.
You're like, okay, so I need a tool. I don't want Webpack right now, let's say, for this project. I just need something else. Is it still Gulp? I feel like there are a lot of developers that say it like that with a shrug at the end. They're like, "Is Gulp still the thing that we use?"
Dave: That was going to be my question, Blaine. Is Gulp dead?
[Laughter]
Dave: Catch us up.
Chris: Yeah, catch us up. Did I characterize that correctly or do you have a different view of how that went down?
Blaine: No, I think you kind of characterized it very correctly. I just saw a Twitter thread the other day that was basically asking that question, "Is Gulp still the thing?"
Chris: Yeah.
Blaine: I think that Gulp -- again, I have been putting a lot of work into it but I didn't come up with a lot of the stuff early on. A lot of the branding, a lot of the way that we talk about ourselves and things like this. We were always the streaming build system, but I've never really viewed Gulp as only that. We were like the low-level plumbing to the stuff that you need to get done.
We actually just did -- I don't want to say it was a rebranding, but we did a whole new website update and, with that, we also rewrote our content for our homepage. We had to really think about, do we want to keep saying "The Streaming Build System"? We kind of fell back to this idea that we are a toolkit to enhance and automate workflows, whatever that means really, right?
You can use pieces of Gulp without using other pieces of Gulp. You can use the task system without having to use the streaming system, like the file operations. You can use the file operations without using the task system. Though, I don't know why you would want to do that, necessarily, but you could.
The Gulp 4 release was really about bringing us to that point. It was about bringing us to good core features, good core things that you can build upon.
We kind of pardoned our streaming implementation. There's some really cool stuff that we did with our streaming implementation that you wouldn't see in most node streaming libraries. The task system takes into account all of the ways that JavaScript and Node developers develop. It has Async/Await support. It has callbacks, promises. We even do event emitters, so we have full support there.
You mentioned something that I think is very interesting and I thought a lot about is the tutorials. We haven't had a lot of tutorials come out but I feel like any tech that's sufficiently old doesn't get tutorials because they're just a mainstay, right? You can grab Gulp and, if you know Node, you can write Gulp code. You can write your Gulp file. Along with that, we've also spent a bunch of time getting non-Node developers up to speed through the Gulp documentation. We have a whole new Getting Started guide that was released either with or right after 4.0 was released.
Chris: That makes sense. I bet there are a lot of developers out there, like I probably know Node a little better because of Gulp. It's an entry point for some devs. I need to do this and I understand that it's written in Node, so I guess I'm writing Node.
Some of that confuses me, like, did you have to write your own promises implementation? I would think, well, Node has promises so Gulp has promises. Do you know what I mean? What's the connective tissue there? Does it need any?
Blaine: Right. Yeah, so we didn't write our own promise implementation. You can use whatever is available in the runtime. The thing that's hard to kind of deal with is, Gulp supports all these different types of a-synchronicity: promises, callbacks, streams, et cetera. Our task system needs to actually have that embedded at its core.
Essentially, if you return a promise from a Gulp task, we need to know how to wait for that promise to be completed to move on. The same with streams. The same with basically anything that we support, we need to know how to wait for that stuff to be done.
Chris: That's a big deal to me as a user because I definitely need to be able to tell Gulp, "These two tasks can run in parallel," maybe. But for the most part, when I write Gulp files, they're pretty not async. They're like, "Do this then do this, then do this," because some of it might be like that first task writes something to the file system and the next task might look at the file system again.
Maybe that's a bad example because maybe you're not supposed to do that with streams. You're probably supposed to just pass it along or whatever. [Laughter] It feels like that's just an example. Sometimes you really just need the task before it to be done-done before you do the next task. Yeah?
Blaine: Yeah, for sure. There's some really cool stuff that you can do with the new task system in Gulp 4. I usually don't recommend them just because they're very advanced and we get a lot of support requests for them in our issue tracker if we recommend that people do the advanced stuff, so we try not to do that.
Gulp's task system is all curried. It's like partially applied so you can build up your workflow, your task workflow, and then you can call that function at a different time. You could actually pass data along, theoretically. These are very advanced techniques that I usually don't document or recommend. It's just if you understand the fundamentals of how Gulp works then you can really get yourself in some deep weeds.
That's kind of the whole plumbing aspect, right? People could build libraries on top of Gulp or things on top of Gulp and they can abstract those complexities away from their users.
Chris: Okay. Okay.
[Banjo music starts]
Chris Enns: This episode of ShopTalk Show is also brought to you by X-Team. That's x-team.com/shoptalkshow.
X-Team allows you to work from anywhere for the world's leading brands and get support to do more of what you love as a developer. Maybe you haven't heard of X-Team before but X-Team is a 100% remote company that helps companies scale their development teams by providing them with extraordinary teams of developers from around the world. They believe in living a life of freedom that allows developers--that's you--to spend more time getting energized by your passions. They foster a unique, active lifestyle and culture around this idea that continues to attract thousands of developers to apply every day.
X-Team is the most energizing community for developers in the world. What separates X-Team from their competition is a level of attention and care they give to their developers. They proactively support them, fund their learning and growth, and connect them in roaming hacker houses around the world and then give them a remote environment that motivates and inspires them on a daily basis. Where other companies simply place and drop their talent, they foster and cater to their unified team of developers centered around the same beliefs, values, and lifestyle.
Check out X-Team if you'd like the chance to work with big brands like Riot Games, FOX Broadcasting, Kaplan Incorporated, Coinbase, Beachbody, and more. You get to live and work in one of their roaming hacker houses, X-Outposts they call them, around the world that changes locations monthly, allowing you to explore and work remotely in the most beautiful locations. You'll get to take part in adventures, share passions, and learn how to be a better remote developer.
You'll get to take part in one of the most energizing communities for developers in the world by participating in their seasons, a three-month experience filled with challenges, rewards, games, competitions, and more, all centered around a theme that will inspire and energize you. And you get $2,500 per year to spend on doing more of what you love and staying energized. Use it on conferences, courses, video games, photography equipment, and more.
If you're a developer who is looking for a chance to try out remote work, visit x-team.com/shoptalkshow and find out more. Our thanks to X-Team for sponsoring this episode of ShopTalk Show.
[Banjo music stops]
Chris: Let's see. People out there, we're a bunch of minutes into this and we didn't even really define what Gulp is, but I think they get the point. It's a tool. It's written in Node. You use it in Node and it runs tasks for you.
I guess that's probably, I would think, 90+% of why you would use Gulp, if not 100%. It's a task runner. You define some tasks and it runs some tasks. What are tasks and what do you see as the top tasks? What is a task and what's the main one that people reach to Gulp for?
Blaine: Right. That's an interesting question. We've tried to break down these barriers on our terminology and on Node terminology. We keep using things like tasks, workflow, and stuff to kind of conceptualize or to bundle these ideas into words that we can talk about.
A task is just a function. But what Gulp allows you to do is it allows you to kind of bind those functions to your command-line in a really easy way. On top of that, we also were talking about, I think you said you want to run this task, then this task, then this task. Gulp also allows you to compose functions in a very--I mean I wrote it--elegant way. We expose your tasks to the command-line and we provide two methods, series and parallel, so that you can kind of combine all of these tasks or functions in any way you want.
I think one thing that sets tasks apart from any function in Node is that they have to all be asynchronous. We were talking about how we support promises. If you have a function that returns a promise, you can assume that that function is asynchronous because you don't know when the body will finish executing.
Dave: I think Gulp was one of my biggest -- I mean I think I've done async programming before but just getting used to that idea that, "Oh, compiling my CSS, that can happen. That can finish whenever, and maybe before I even compile the site or something like that." I don't know, but the API, too, is like, "Source, grab these Sass files and then .pipe it to some other function like prefixer. Then .pipe that to the destination," or whatever.
Chris: Mm-hmm.
Dave: It just was very cool but it also took some, I guess, brainstorming around, "Okay, when would this finish up?" Oh, it could finish up whenever. "Okay. Okay. I have to kind of rethink how my life works or, I guess, which series of tasks." How do I serialize some tasks but then how do I also just don't care? Can I run two things at once?
It was very, I guess, challenging to me in the early days but it made me very used to just programming in Node or kind of being a more asynchronous kind of person.
Chris: [Laughter] You're an asynchronous person.
Dave: I'm an asynchronous person. I really don't care when it gets done.
Chris: See, you broke the Sass barrier. To me, that seems like a big one in the world that I live in is that I have a project. I want to write Sass on it, let's say. Sass is still super popular. I use it on several big sites. I don't think Sass is going away any time soon. The people, they like it. So, you need to run Sass.
Now, if you look at the Sass docs, it'll be like, "Whoa!" Dart Sass is written in a way that you can use it via Node too and here is our little API. You hit it with these files and it returns. Nobody is going to use Sass like that. I'm sure very few people run the Sass CLI stuff super directly - just use their API directly. Maybe you'd write an NPM script to do it but then you're editing your package.json when you add a new Sass file to watch. It feels like having some kind of abstraction level that's like, "This is the file that has the configuration of how we process our Sass at this company," especially because it's not just Sass, as Dave said.
It's probably like, "I'm going to run Sass. Then I'm going to run auto-prefixer and maybe other post-CSS stuff if I want to. Then I'm going to minify it." That's three things in a row, and all of these things are asynchronous, like we just talked about. How long does Sass take to process? I don't know. As long as it does. It might be ten milliseconds or it might be a minute. It's just - who knows?
The same thing with all these steps, so I have to write some code that says, "Do this. Run Sass. Do this. Run auto-prefixer. Do this. Minify it. Then when you're done, go put it in this folder over here because, in this house, we put our CSS in a CSS folder."
You need something to do that and there are precious few options out there in the world to do it. I feel like, these days, there's one. It's Gulp.
Blaine: No, I feel you. [Laughter] Tangent, actually, I love Sass. We use it for our website and I love that you can embed your media queries inside of each selector. I just think that that is amazing. If that were all that Sass did, I'm fine with it.
Chris: Yeah. It's a big one.
Dave: Yeah. Nesting and especially nesting media queries.
Blaine: Right.
Chris: Hell yeah. Hell yeah.
Blaine: To think that it unwraps it backward, it's really interesting to me. I would say I am fine with people using command-line tools and I'm fine with people using NPM scripts.
I don't think that Gulp necessarily competes. Like you said, Gulp doesn't compete with Webpack. In my opinion, it doesn't really compete with the command-line, running things at a command-line. We have a command-line tool. It's not our direct competition.
Things that we do well are, like, I feel like almost no command-line that you run has globbing, like if you do **/ or you do your CSSdirectory/**. Every CLI tool is going to deal with that differently.
Dave: That gets me all the time and it frustrates the hell out of me. It's probably because I learned Gulp first and it was like, "I love this."
Chris: That's a big deal just for Sass because you're like, "Please watch all my Sass files, please." But we've only talked about Sass so far. Gulp isn't just for Sass. We also have a set of tasks for our JavaScript. I also have a set of tasks for our SVG files. I even have a set of tasks for HTML files or PHP files for a project that I'm working because there are things in there I want to update. It's like big groups of tasks.
Blaine: Yeah, it can do everything, right? You can find plugins for pretty much anything you can think of. That was something that I think we did really well is that we didn't try to silo off the plugin community. I would say that that has led to varying qualities of plugins and we are actually thinking about maybe reining some of it in and taking on the maintenance of some plugins just because we've seen them.
People get bored. It's open-source. People get bored. People move on to other languages or get a job. They got to get paid somehow. We've been considering, as a larger team now, maybe starting -- we actually already started it, but it's not really popular yet. It's called Gulp Community where we can adopt and help find maintainers for plugins.
I think, yeah, like you said, you can find plugins for all of the stuff that you're doing. If there's not one, you can actually just in-line the code that you need, right? You don't need the Sass plugin. It's nice but if you just need to compile Sass, you can install the Node Sass library and call that as part of your task.
Chris: Right. Right.
Dave: See, this is what I like about Gulp versus other competing products, we'll call them. I know how, like I could select all the Markdown files in my blog and then I could figure out a way to translate it, like send it to Google Translate or something. I don't know. Some API that translates it into Spanish and then I can write out a file with the same file name that's .spanish.markdown or something like that. I know how to do that. I could write that in Gulp.
But then it's like, "Okay, Dave. Use Grunt or use Webpack." It's like, "Oh, man. I sure hope Webpack has Webpack transform English to Spanish Markdown." I don't know my skills. My file manipulation skills feel like they don't transfer to the other systems. This is what I really like about Gulp is it feels like programming to me. It feels like, "Oh, I just write little--"
I've been thinking about this a lot because I knew you were coming on the show. It's almost like Apple's Automator that they have that no one uses or maybe that's even dead now. It's like Apple's Automator or shortcuts that's on the iOS. It's like you give it an input and then you kind of construct the way to output and that's it. It'll suck things in and spit things out. That's what it does a hundred million times a second. It loves it.
Blaine: [Laughter]
Dave: That's what I love about Gulp.
Chris: As somebody who writes cloud functions--I do. It's just something I've been doing lately. It relates to my job and stuff--that are also in in Node, then it makes this kind of like return to Gulp feel even more comfortable because I'm like, "I'm just working in Node anyway. Gulp is Node." This seems like that was a good choice is to just stay in regular-ass Node land. [Laughter]
Blaine: [Laughter]
Chris: But thinking of unmaintained plugins, because that happens, and I know you think about--
Dave: [Laughter] Speaking of--
Chris: Dave, you have no experience.
Dave: I know, well, I got a bug report. Go ahead.
[Laughter]
Chris: We just know that that happens. If there are 10,000 Gulp plugins in the world, I'm sure 9,000 of them are abandoned. It's just the way it is. Maybe they're fine abandoned because it just doesn't matter or they do something that doesn't matter anymore or something.
Gulp itself matters. Look at how many Gulp leads there are. It's just you, right, Blaine? If you weren't born or there was no Blaine, maybe Gulp 4 never happened and maybe Gulp itself was one of those abandoned projects. Isn't there a risk even there?
Blaine: There's definitely risk and this is something that I've thought a lot about, actually. One of the big pushes on Gulp 4 and the thing -- I mean I will take a lot of the blame for Gulp 4 taking so long to come out because, you know, I am, to an extent, a perfectionist. It was my beautiful little painting that I wanted to be perfect. Eventually, I just had to release it.
I think we only had one major bug in the first month that it was out and we got that fixed almost immediately. So, it was really cool to have it released and be so solid.
One of the big holdups, other than me, was that I really wanted to build out a team. I don't think that I know enough about file systems or enough about command-lines or enough about any individual piece of the project. Even though I have all of that in my head about Gulp, I wanted to build out smaller teams with multiple maintainers that can help in those areas.
We have grown the team from basically two or three people to I think we're up to 13 now. We're continuing to try to grow the team for people that have more specialized areas. It could even be in triage, right? We have a triage team as part of the Gulp core team now.
Chris: Interesting.
Dave: Wow.
Chris: It sounds like you like it. You wouldn't be doing this if there wasn't some part of you that just enjoyed this, yeah? It doesn't sound like it's for the money.
[Laughter]
Blaine: It's not. It's rewarding. It's also frustrating at times, right? People non-ironically saying that it's dead or, "Why would you use it?" or things like this, or angry people and issues, especially doing the 4.0 upgrade. It can be frustrating but it is also very rewarding.
Just to hear you say, like, there's not really anything out there that you would grab. There's not another tool that has replaced it. There are a lot of tools that are alternatives, especially if you have very specific workflows, but there's nothing that straight up has been like, "Oh, we have completely replaced it with better ideas," because I think the ideas that it was founded on are very solid and it has made me learn a ton about Node, a ton about programming.
I've been working on Gulp, like helping out, since 2013. It's almost seven years now. In July, it'll be seven years. I have only been doing software development for ten years. [Laughter] So, how does that work, right?
Chris: Yeah. Yeah, I hear people like that from the WordPress community and stuff too that are like, "This was my come up in project and I've just been at it for a long time. It basically is me as a developer."
I see on the gulp.js website, which is brand new, by the way. Congratulations. There's some clear momentum there. Nothing like a fresh coat of paint, right?
Blaine: Yeah, thanks. We put a bunch of effort in. I was visiting a friend in Bulgaria in February. She wanted to transition from more dev-centric to more design and front-end and UX work, so I was like, "Well, hey. The Gulp website is really old and crusty. Do you want to do an information audit and figure out the things that we should have on the website, figure out the new design and things?" She really jumped in and produced something that I am blown away by. I'm really happy with the results.
Chris: That's great. I think where I'm trying to go with this is sometimes it's astounding in open-source how big of an impact something can have, how many users it can have, how important it is to people and to have that be 100% unrelated to the profitability of that project with most open-source making hardly any money at all. The superstar, anywhere where that's not true feels like a big rarity. The fact that Vue makes enough money makes them kind of a superstar of the open-source community because they make -- I don't even know. I don't have any numbers but they make enough money that it's not embarrassing. You know? [Laughter]
Not that how much you are. I have no idea what your numbers are, but isn't that weird? It's like, gosh, you could make a fricken' mobile game with a little racecar that runs around the track and sell it for $5 on some app stores and make ten times more money than you could in open-source. Is that true?
Is there a way to extract some money out of this for real? Not that you want to quit your job or anything, but Gulp is huge. Where's the money?
Blaine: Yeah. There are a lot of options, right? Gulp, especially through my efforts before I joined Tidelift and ongoing just to help out the team, we've been really working towards different avenues.
The one thing that you can make a lot of money on that we haven't decided to do yet. Just as a team, we don't necessarily agree with putting advertisements on our website or documentation. We have not gone that avenue. I know that you can make a bunch of money there. We've, instead, with this new website launch especially, we've opted for corporate sponsorships that get their logo placed in a rotating banner or individual contributions that get you to show up randomly in the individual backer section.
Chris: There's a little bit of money there, right? That's trod territory for open-source projects, right? Like, "Throw us a few bucks."
Like I said, I have no idea what your numbers are, but I've never heard a story that's like, "Pfft, this is paying the bills. Going to get my Lambo with these $5 donations," you know.
Blaine: Right. It definitely does not. It definitely does not replace a job. We are part of Tidelift. I am not the Gulp person for Tidelift just because of U.S.--
Chris: Conflict of interest there?
Blaine: Yeah, U.S. employment law stuff, but our Japanese maintainer, our core maintainer, he is actually the lifter for Tidelift.
Chris: What does that mean? Like the benefactor of money?
Blaine: It's the person that completes the work that Tidelift needs done. Tidelift is a managed, open-source subscription for large enterprise companies. If you're a large enterprise company and you're using Gulp and you need additional assurances and benefits--
Chris: Oh, interesting.
Blaine: --on top of just using the open-source code, then you would subscribe to Tidelift and some of your subscription money would go back to Gulp. Then you're provided those guarantees and assurances from one of the Gulp core maintainers.
Chris: What are those assurances? We're not going to break your stuff. We have an SLA, or something.
Blaine: Yeah, it's very similar to that. If there's a security vulnerability that affects us that we'll get it fixed quickly. That we'll just continue ongoing maintenance. There are also assurances around licensing and how we will provide those--I'm going to say the word again--assurances to subscribers of Tidelift.
Chris: No, that's cool. If you're big enough, you're a $10 million revenue a year product, so you're a middle-sized kind of company, you're starting to be at that level where, like, "If we're going to pick some software, we're not just going to grab it off the shelf anymore. Maybe some of it, but the most important pieces, we want those assurances that things are going to be okay. We have some money to throw at it."
Blaine: Yeah, exactly.
Chris: Are the numbers public here? What does a middle-tier company like that pay if they want these assurances for Gulp? Is it like $50 or is it like $2,000? I guess you don't have to say, but it's interesting to me.
Blaine: Yeah. Well, so the Tidelift subscription has pricing models on their website, but it's not just that you're paying for just Gulp. It's that you get the whole catalog of open-source software.
Chris: Oh, interesting.
Blaine: You were able to have these assurances for a lot of the software that you're using and some of our initial plans start at, like, $1,500 a month with a year term. It would definitely be, like you were saying, much more like $10 million or a large company making a lot of money. It's not like the startups, right? But it's a company that needs these guarantees.
It needs this extra layer. It's risk management, right? When you start using open-source and you grow to a certain size, you need risk management.
Chris: Yeah.
Dave: Mm-hmm.
Chris: Oh, it's pricy. The baby plan is $1,500 a month, but that's nothing for a big company that what you're buying is assurances. That's awesome. I guess the name comes from rising tide lifts all boats, yeah?
Blaine: Yep.
Chris: That's why you can't do a one-off. Yeah, okay. Dave?
Dave: Well, I just was saying, it makes perfect sense to me. I think any company these days, we're starting more and more just to offload to whatever we found on NPM. "Oh, man. I'll just NPM install that and that'll work. I guess it works and, hopefully, it's around forever. Fingers crossed."
I think, yeah, companies need more risk management or just assurance than just, "Hope it still works." You know you can't build a business on that. I think sensible companies would be like, "Yeah, we should probably support these people and," whatever, "facilitate support."
I know GitHub has an individual contributor thing you can do or whatever but this seems cool because you kind of get that contract like, "Hey. I'm paying you but not just because I'm your buddy. I'm paying you because I will call you one day if it's harming my business." I think that's smart too. It offers a lot.
Blaine: Yeah. No, I agree. This is why I joined the company, right? I think that this is a good business model to push forward.
Chris: 1-800-fix-gulp. You get that phone number and it goes right to Blaine.
Dave: Yeah, hotline. [Laughter]
Chris: Yeah.
Dave: Bat phones. All that. It's an upsell.
Chris: Okay, so that's cool. Yeah, I almost feel like there should be more Gulp sharing parties or something. [Laughter] I don't know. Whenever I write a Gulp file, I have an irresistible urge to share it with people and be like, "Look at what I'm doing! Did I do it right?"
Dave: There was one time I made the most beautiful SVG processor in the whole planet and I can't find it. I don't have any idea what client that was for or whatever.
Chris: Oh, no!
Dave: It just sucked a folder of SVGs and used Cheerio to manipulate some things and spit it out.
Chris: Did it? Nice. Classy. Yeah.
Dave: Oh, it was so beautiful.
Chris: I'm always avoiding Cheerio if I can just because -- ugh.
Dave: It's a….
Chris: It's a big one. Yeah. Yeah and it's like -- I don't know. But the benefits are then if you have malformed SVG, it will tell you that, which other SVG things won't.
[Banjo music starts]
Chris: Hey, ShopTalk listeners. This show is brought to you in part by CodePen. That's me, your host Chris, Co-Founder of CodePen also. Sometimes I like to sponsor our own show and tell you about CodePen.
It's a freemium app, so you can use CodePen for free, but I hope to compel you with the features of CodePen Pro. One reason you might upgrade is just because you like this show. That's fine with me. I'll take your support that way. Ideally, there's some part of Pro that makes you want to upgrade.
One of the little things you get with Pro is that you get unlimited embed themes. You might build something on CodePen in which to then use somewhere else, like use in a blog post or documentation or whatever. It's nice because you change your theme and then it changes on every single embed where you used that theme.
Of course, that's very important to me on, like, CSS-Tricks, for example, where I might want to change the look of the embed because we're redesigning the site or just want to freshen things up or something and have that theme change over the entire site. Of course, I do that. If you need several, a bunch of themes, just go Pro and you have unlimited of them, which is cool. Just one of a dozen or more features you get for upgrading to Pro on CodePen.
[Banjo music stops]
Chris: Here's one, though. You do your SVG. Right, Dave? You've got it going but then you link up the sprite somewhere. I do this for some advertising stuff too. How I have the final file or I have a file that represents some ads on the site or something, just like an SVG sprite would be and that is intended to be Ajaxed in or something. But I intentionally cache the crap out of it.
I'll tell browser cache at the browser level, "Please cache this as heavily as you can." If I want to cache bust it then it's on me to change the query string or something. I'd have an SVG process that does this SVG processing and then goes into whatever other files, maybe some JavaScript files where the Ajax call is performed or HTML files if it comes from there and manipulate those with a Gulp task to break that cache kind of manually.
Dave: Ooh!
Chris: That's all.
Dave: See. I like that.
Chris: On the ShopTalk Show website, we use Gulp and we have a Sass process too, but I never got around to wiring up the cache-busting. Our hosting needs that. If I change some CSS on the ShopTalk Show website, I have to go to the header file, find where it links up the SVG, and change the query string manually to a new number. Otherwise, after I push, you won't see the CSS changes because it's still cached in the browser.
Blaine: [Laughter]
Chris: It's a Gulp task away. I've just got to write it.
Blaine: Got to write it. Yeah.
Dave: I was going to ask, Blaine. I feel like it was maybe Gulp 2 to 3 or maybe it was 2 to 4 or something. There was a dependency thing. It might have been with Gulp Sass or gulp-chokidar or something. I have no idea.
Chris: [Laughter]
Dave: It prevented an upgrade, right? I think you were kind of in that situation where the Gulp project was like, "Hey, use the new version of Gulp. Use the new version of Gulp. It's way better," but then you were kind of pinned down by some popular dependency. Maybe you remember that story a little bit better. [Laughter]
I guess the ultimate question I want to ask is, how, as a maintainer, do you handle somebody's dependency getting popular and hamstringing your project? How do you work in those confines?
Blaine: Hmm. That's interesting. Something that we have strived very heavily for -- I don't know how long this has lasted. Once you reach seven years, certain things far ago passed get very fuzzy.
Dave: [Laughter]
Blaine: We don't break the plugin API. I know Chris was talking about how the API breaking changes from 3 to 4 are difficult to get over but the thing that we decided to do with our major breaking changes there were that we didn't break the plugin API so that you're only waiting on yourself to do the upgrade. If you are using Gulp 3 and you don't have the time to upgrade to Gulp 4 or you do have the time and you're not blocked by a plugin not upgrading.
The 3 to 4, we shouldn't have anybody. As long as the plugins were behaving correctly, we shouldn't have anybody that you were waiting on. I think there were a few plugins that actually were using event stream, which we banned even before Gulp 3. We said, "Don't use event stream because it doesn't actually create real node streams."
We recommended everybody use the through2 library for plugins. If every plugin that you were using was following those guidelines and using through2, then upgrading from Gulp 3 to 4 should have been no problem. Well, obviously, it'll be a problem because the API breaking changes, but you're not waiting on anyone.
Chris: I didn't find 3 to 4 that bad. I'm sure lots of people -- well, you have lots of evidence that people did. It's just syntactical stuff. I could see the reasons behind it. It seemed fine.
What killed me for a year, which this is just very specific to me and my own lack of knowledge here--this is not symbolic of all--there was something where the CLI was just baked into Gulp now or wasn't a separate package. Maybe it's the exact opposite. Maybe it's broken off now and it wasn't before.
Also, the version number of it went down somehow instead of up. I don't know. It was kind of confusing in that I had some old version installed and my computer would just not let go of it. It just wouldn't run. It would cause errors. Then it just turned out it was installed in some weird subfolder and I had to root it out and delete it. After that, it was all good.
Please, if people are having trouble with that, I remember how to fix that, so hit me up. [Laughter]
Blaine: Yeah, and one of our maintainers I think jumped in and helped you. This is why I wanted to build a team is because I would have never known those commands to run to figure out where that file was existing on your computer and how to remove it. How did it get there? How did it get root permissions? I don't know enough about the terminal to even solve that problem for you.
Yeah, that was a big breaking change that we were kind of forced into doing because the command-line -- the Gulp core library, the thing that you import that require Gulp or input Gulp is only like 80 lines long. It's not a big library and so the majority of installing Gulp was dependencies.
We used to ship the command-line built into the main package, so you would install Gulp globally and you would install Gulp locally. This actually caused us a bunch of headaches. One, the version number. Your global version number would always have to match your local version number. When we started working on Gulp 4, we were like, "Oh, well, you actually can't have a Gulp command installed that runs 3 and runs 4. If you install the 3 version, it will never run 4. If you install the 4 version, we could theoretically include a ton of code so that it would run the old one but that would bloat the Gulp package.
What we decided on as a team is splitting out the command-line into its own library. Gulp CLI exists as a separate library now. That is versioned independently of Gulp. When you saw your number go down, you went from Gulp 3.9 or something to command-line version 2.1--
Chris: Right.
Blaine: --because we started the new command-line at version zero because it was a brand new thing we were developing from scratch. We don't do mono-repos like a lot of projects are doing these days. We actually have 60-some repositories.
Chris: Oh, god. Oh, get onboard. It's better. Anyway, go on.
Blaine: [Laughter]
Dave: Oh, man. I don't know.
Chris: [Laughter]
Dave: I don't know. Go ahead. Go ahead. Go ahead.
Blaine: Gulp packages aren't created only to use in Gulp, right? Mono-repos are mostly namespace things in NPM. The Gulp packages, they exist outside of Gulp so other people can use them. Microsoft actually built a tool on top of Gulp core libraries because they didn't want the streaming implementation. They just wanted the task system, so they took all of the libraries that I wrote for a Gulp task system and they just built their own build tool.
If we were namespacing, it would just be a little weird, right? It would be like, [email protected]/undertaker to build your task system. That'd just be a little weird to me. I know it's fine. It's just a naming thing but I wrote these libraries to be used by everybody.
Chris: I see.
Blaine: We have a library called Interpret that if you've ever named your Gulp file anything but gulpfile.js, if you've named it gulpfile.coffee, if you've named it gulpfile.babble.js, if you've done your Webpack config in any language that wasn't just pure JS, like if you've done the same thing, your webpack.babble.js, then you are using Interpret. It is a library to register transpilers inside of Node.
If we had things namespaced as @gulp.js, I just feel like they would likely be used less by people not only because it's a discoverability issue trying to find the package in a scope on NPM, but also just because people don't want to advertise. I don't know. It's a weird open-source thing. [Laughter]
Chris: I get it. If they're built to be totally-totally independent, then just let them be totally-totally independent. I think that's a really good use case for not mono-repo'ing, in this case.
Blaine: Yep.
Chris: Yeah, that seems fair. If it was just like, "These are only meant for internal usage," and you still split them off, that feels less nice, you know. Only for the ergonomics of, like, "Oh, god. Now I'm just constantly changing directories and stuff to do my Git commits and all that." It is just a management headache, an ergonomics headache, I think.
Dave: I would agree. Yeah, it's a horse-sized duck problem, right?
Chris: Yeah, definitely two animals are involved.
Blaine: [Laughter]
Dave: I had some questions, Blaine. What's the future of Gulp here? Version 4 is out. The new website is out. What is the future of Gulp? Where do you think it's going?
Blaine: Right. I have lots of ideas. We're going to keep working on our documentation. I'm very happy with our setup now. We can churn out new documentation. When we did our rewrite of the documentation for 4.0 and the new website, we didn't translate any of the plugin guidelines or how to write a plugin. We didn't translate any of the recipes, so I want to get a lot of that stuff figured out.
One of our big expenses for the money that we do receive is to pay a documentarian and whoever else helps to write docs because it is probably what I would think is the least interesting thing that the team could do. People don't want to do it. They will do anything but. They will go fix issues. They will create new features, but writing documentation is really hard. It's one of our big expenses.
Dave: Well, and I guess, at a certain point, you're too deep, right? You know too much about Gulp and how it works and how to write a Gulp file that you almost lose out; you miss out on that novice sort of mindset, the beginner mindset that might be required to make really good docs. That's tough.
Blaine: Right and our documentarian actually has written about four lines of Gulp ever, so gets to tell me when things are way too deep and when I have too much knowledge or experience. We can bring it back to its base and really root it in the fundamental knowledge, not Blaine is super deep in the weeds here. [Laughter]
Chris: That's nice. In our last show, the topic of a friction log came up, which was kind of -- you try to do something technical and just be mindful as you're doing it of everything that was unusual, caused you some friction, and write it down. Maybe that works for docs as well if somebody is reading some docs and there's friction because they just don't understand what the heck you're talking about. That's a moment there to latch onto.
Blaine: I would say the other immediate future thing, Dave, is something that came up very recently and is kind of frustrating to me is that Gulp 4 started to be developed when Node 0.10 was still new. Now Node is up to 14. Our support actually goes back to 0.10 because I didn't want to break people in the release. But Node 14 that came out the other day, it actually breaks the Gulp watcher.
Dave: Oh!
Blaine: What we will very likely -- I don't know how we're going to find the time to do this because it's a lot of hours of work, but we need to probably do a Gulp 4 to Gulp 5 breaking release that just changes our Node.JS support matrix so that we can upgrade some libraries to get the fixes needed to support Node 14.
Chris: Oh, well, that's a flippin' nightmare, man. I'm sorry. You have to lock to an old Node version, which is probably something that some people aren't stoked about, like, "Oh, we can't use Gulp 4. It's stuck in the past," you know. I don't know. It just seems like a bummer. What did Node do to you?
Blaine: They just changed some and it's been happening for a while, but they've actually just removed some of the features that we relied on in the native code. I understand that they are trying to clean house. They're trying to remove this old, crusty, native -- I think it's probably C code or bindings for that. That's what our watcher library uses.
The watcher library has been upgraded but they don't backport fixes, so we need to do an upgrade, which is a major breaking change. Then we're also going to have to drop support for Node. To be honest, these are old Node versions but we try to have the most comprehensive support we can, so we're going to be looking into that in the immediate future.
Chris: Well, good. Good luck. Yeah. No, that's cool. That's good to hear. Again, thanks for coming on. I really appreciate it. We saw each other, I guess, at VueConf here in Austin. That was fun. It's just good to know Gulp is going, Gulp is still active.
I think it was always kind of in my head, like, "I like Gulp but what's going on with it?" I want to say thank you for coming on the show and kind of talking about it because it does sound like it's active-active and still very useful.
I guess we should wrap it up here. Blaine, for those who are not following you and giving you money, how can they do that?
Blaine: I would say, go check out the Gulp website, gulpjs.com. I'm really happy with the design. It's really cool. I don't promote myself too much. I'm @BlaineBublitz on Twitter.
Yeah, hit up Gulp. The Gulp stuff is really cool. We have all of the sponsorship links. You can find the Tidelift enterprise option on the website as well. Yeah.
Dave: Nice. Yeah. Thanks. Yeah, there is a donate button in the nav. I support open-source, getting money, getting paid so, everyone, go there and chuck a buck or two bucks, I guess, is the minimum.
[Laughter]
Dave: Chuck two bucks at it. All right, well, cool. Well, thank you so much and, yeah, thank you, dear listener, for downloading this in your podcatcher of choice or via your Gulp file because you could probably do that.
[Laughter]
Dave: Be sure to follow us on Twitter, @ShopTalkShow, for tons of tweets a month. Consume that in your Gulp file.
If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.
Chris, do you got anything else you'd like to say?
Chris: Hmmm… ShopTalkShow.com.