The Changelog: Software Development, Open Source - webpack (Interview)

Episode Date: December 17, 2016

Sean Larkin joined the show to talk about Webpack, how fast open sources moves, how fast Webpack is moving, the core team, the formation, joining JS Foundation, the problem it's solving, the bleeding edge features, sustainability, Sean and team's efforts to build the community, their work on Open Collective, and more.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. What's up? I'm Sean Larkin and you're listening to The Changelog. Welcome back everyone. This is The Changelog and I'm your host, Adams Dekowiak. This is the last show of the year, episode 233. Big show talking about Webpack with Sean Larkin. We talked about how fast open source moves, how fast Webpack is moving, the core team, the formation,

joining the JS Foundation, the problem it's solving, the bleeding edge features, sustainability, the team, Sean's efforts, their work on Open Collective, a lot of stuff packed into this show. So I hope you enjoy it. We have three sponsors for the show today, Code School, Top Tile, and Rollbar. First sponsor of the show is our friends at Code School. And this year is

a great year to give a gift of code. If you're scrambling to find the perfect gift for a friend, loved one, buddy, friend, coworker, whatever. Somebody out there needs to learn how to code and you want to give that gift to them. Give them access to CodeSchool's entire library of courses. They've got more than 60 courses and 2,700 coding challenges all wrapped up into one single awesome gift. You can give a gift of one month for $29, six months for $99, or a full year for $189, a savings of 46%. Head to Codeschool.com. The offer is available until Friday, January 6th, 2017.

The offer starts Monday, December 12th. So very soon, if you're listening to this before that date, once again, Codeschool.com. Give the gift of code and now on to the show. All right, we're back. We're talking to Sean Larkin. And Sean, Jared, is, as you said, one of the most enthusiastic people. That's right. For Webpack.

Maybe in general, open source, I'm not sure. What do you think? He's like a true evangelist in terms of the excitement, the helpfulness. He's out on Twitter with the hashtag webpack, searching it, finding people, helping them out at all times. Yeah, yeah, yeah. That's awesome. He's truly getting people on the webpack bandwagon. And not only that, he's also from my neck of the woods. Ooh. Omaha. He's from Lincoln, right, Sean?

That's right. I live in Lincoln, right, Sean? That's right. I live in Lincoln, but I work in Omaha. Okay. So, Lincoln, about 45-minute drive, and works in Omaha, and so it's always fun to have another member of the open-source community rocking it from Nebraska. That's right, man.

It's the heartland. So, we're excited, and it seems like the whole front-end community is excited about Webpack in general and Webpack 2 in specific. So we have a lot to talk about around that, why it's exciting, what problems it's solving, what makes it different, and such things, what's happening in 2.0. But first, we'd like to get to know our guests a little bit. So if you could give us some background, help our listeners understand where you're coming from and how you got to be on the webpack core team as the community advocate i don't know exactly what your title is but i just call you the evangelist for webpack and all things around it yeah so um and you can just say i'm a maintainer

it's just that we all have like specific focuses and so that one's I think I fell into because I'm the only American maintainer and speaking English as my first language, but dialing back. So man, get some popcorn or whatever you want. Cause it may, I'll try and not make it a long story. Uh, so long story short, uh, I'm a previous technical support rep who kind of went rogue and got tired of not being able to fix people's problems. So, you know, the first place I worked at was actually in kind of the tech community was when I moved here to Nebraska. And my wife's from here. And I just wanted to get a job that was consistent. And so I did tech support.

And I did a really great job at it. But it was just so frustrating having to work around issues, getting the same calls every day. And so I kind of took an interest in quality assurance and even you know, hired me to work on Objective-C for their native application product that they sold. And so from there, I had the official title as a software engineer. And then nine days later, I got fired on my birthday for sharing one line of source code. I think too long didn't read version is some people were not very happy that I had been able to make it as a software engineer. People in the support side of the company. And so I think they were just looking for a reason to get rid of me. But like I tell people that because it's like

the best thing that's ever happened to me. You know you know, I, I was able to work at a small digital agency and got to kind of bust my chops, uh, with, uh, you know, Ruby on rails and Ruby and some more web technologies. And then, um, I had the opportunity to work in Omaha for the first time at a retail company called Hay Needle. And there, I think bought by jet who got bought by walmart now um i did like a lot of almost fully exclusive javascript um and then i worked shortly at another contracting job where i got introduced to webpack uh called info group and i was kind of blown away at how incredible the dev experience was like mind you i didn't ever have to set it up myself. I know that I've heard the stories from people.

But it was already set up, and it was just an awesome development environment, and it was a React shop. It was kind of my first time experiencing a bunch of different technologies, but it was a great learning experience. And so when I left there to take a job at Mutual of Omaha as a UX developer, where I work currently, being at an insurance company, you get the opportunity to kind of have a little bit more research and development time because you have things like compliance and state compliance, copy and legal. And so kind of the dev flow or the dev cycle is a bit slower. Like my first few weeks working there, I had the opportunity to kind of research Webpack and Angular. And, you know, I was able to get some sort of boilerplate set up and we use kind of

still exclusively across our team. And from there, you know, I didn't even know you could submit talks to conferences. Like, that was kind of a new thing to me. And so I just submitted a talk to ng-conf and I was lucky enough to get accepted and they said, all right, well, we would like you to actually do a workshop on how to use Webpack with Angular 2. And so that was a whole immersive learning process for me as well. And ever since then, you know, I realized how important it was to kind of spread the word about Webpack. And it was at that time that I found out after the workshop, which went really well, you know, a lot of people were like, who is Webpack? What is, you know, what is this?

The Angular community had no idea, really, for the exception of a few people. And so, you know, it made me kind of frustrated because, one, you know, you see this tool which has so much potential. And, you know, nobody really knows about it in this community. And so the first thing I did was try and really stress how to get funding for the team. And so I kind of put myself out there and jumped in the Gitter chat that was there. It's just like a web-based chat, kind of like Slack, but for GitHub repos. And I kind of like at private mentioned all of them and pulled them into a private channel.

And I was like, hey, I want to get you guys paid. I really believe in your tool. You know, how can I help? And so we talked for about three weeks off and on. And I found out that Kent C. Dodds was doing a podcast or a JS Air with that core team on it. And I was like, oh, my gosh, I need to meet them. And so I think I talked to like Jeff Wepley and I said, hey, can you get me on this panel? I just want to be there as like a panelist and just talk, you know, or sit behind the scenes.

And I don't know if it was because kent wanted to save face or something but the day it was or you know the week before it was announced he goes introducing the webpack core team and i'm there right next to those three and i'm like oh my gosh so at the day of the the podcast or live stream, they asked me, do you want to be on the core team? And I said, I would love to. So they asked you because they were already playing on this, right? Or did he just announce it and they were like, well, I guess you can be on the core team.

Well, so, you know, Kent, I think Kent was a little apprehensive at first of having me on the show. But then he asked the team and they were like, yeah, he can be on it. And we had been talking behind the scenes in this getter chat for about three weeks. And, uh, so I think, you know, by that time they were, uh, you know, they already knew who I was and I, you know, they extended that invite and they're like, I was like, okay, yeah. So it was kind of like a freak accident almost, but, you know, I all I can tell people is that you should just put yourself out there and do the best that you can and show that you give a shit about the tools you want to support and be a part of. That's great advice, man. their getter chat is like all right guys let's let's get you paid that sounds like a good way

open source community is like oh somebody's here and they're gonna get us paid come on in can you get can we get you a cup of coffee can we break that down though jared i don't know where you're going with this but i was really curious when he was saying that was the get people pay like what does that mean yeah and why did you think of that as your first initiative with Webpack? Well, a lot of questions were swirling around my head like, why aren't these guys working on it full time? Is it just a lack of time, etc.? I guess I kind of paraphrase when I say, let's get you paid, but it was kind of the first thing I said. And I kind of asked some more questions. And there were some companies that I met at ng-conf who were kind of asking

these same questions, like, what's the release cycle? Or would you work on this full time? Or if not, you know, what kind of monetary funds would, you know, would help, etc. And so, you know, it kind of just led to learning more about them and how much they work on it. You know, before I joined, really, it was just Tobias Coppers, the original author, who was maybe working on it five hours a week on his free time. I can't help but hop back, you know, maybe three or four pegs and just have to ask you about these two lines of code or one line of code. Oh, please go ahead. Well, I mean, was this launching a nuclear missile or was it your company's private SSH keys? I mean, what the heck?

Actually, no, it was actually it was not even the product that they sold. It was a so basically, you know, you can kind of share a lot of view controllers between like so the older version of the product. We actually created a ticket tracking system out of it. And since I was, you know, coming from support, I had the best experience working on this tool. And so I became the primary software engineer working on what we called ticket tracker. Well, there was an if statement in there that I wasn't 100% sure about. And so I sent a message to one of my, to the two previous employees who were also devs. I was like, what do you guys make of this? And they're just if statements with some logic in it, and that's it.

So they were no longer employed there, and so you were breaking some sort of rule, I guess? Well, yeah, the official was sharing trade secrets for something they didn't even sell. But yeah. Oh, my goodness. But I mean, it was the best thing that's ever happened to me, to be honest. I'm so glad that it, you know, that happened.

I probably would still be there just working on Objective-C, which isn't the worst, but yeah. Do you say that in retrospect? Like now you look back and that's the best thing or at the moment where you're like, sweet. Uh, yeah. Like I was really upset at first cause it was like, you know, I had finally gotten over the hill and i had you know

overcome the adversity of something that that company has never seen um let alone probably five percent of all people who are in support and want to make something better of their lives and and do something more impactful and so like to get shot down like that so quickly i was i was upset and a little concerned because it was like well i've only been officially a dev for nine days. What am I going to do? But I mean the beauty of LinkedIn is that most people don't care and they just see your title and they're like, all right, ship it. So I mean I had been programming for longer than just nine days officially, officially. But, uh, you know, they want to see what's on paper, but yeah, retrospectively, like it's the greatest thing, you know, that could

have ever happened to me to really propel myself and my involvement in the community and open source forward. How did it do that? Like what, what were the things that happened to make that the best thing? I think it was just being able to get me into places and and job it kind of like it sounds silly to say and maybe a little contrived um but like once you have that title it was so much easier to find a another dev related job you know uh i had i had tried in the past with just saying you know i've done technical, you know, I've worked on these languages on the side. And that usually wasn't good enough. It's like you're in the club.

You got past the velarope. Exactly. And like once you're in, you're good. Like, you know, I've maybe only been doing full time JavaScript for about two years and maybe, you know, kind of some other technologies, you know, for maybe no more than a year and a half. So it's like, you know, I'm a quick learner. And, you know, I think some people saw that and the people who did believe in me at the company were happy to make it happen. Do you think that title gave you a certain level of confidence that you could have achieved otherwise, but it was like somebody else named you this and so now it felt like you were one?

Or did you already feel like you were a software engineer and finally somebody put the title on your desk? I think the title is the recognition for sure. And you know, it wasn't as much competence because I've known I've been able to prove myself worthy, but it's kind of like that thing people want to see on paper. Oh, do you have this on paper? I knew I could pass the eye test but you know having the stats is what i think people were concerned about so now you're a webpack core team member maintainer and really kind of the voice of the webpack team to the community and like i said during the intro you're you're you're out there really in the trenches on Twitter.

Tell us a little bit. We're going to get into Webpack probably on the other side of the break and why you're so excited about it and why everybody in the greater JavaScript community is kind of letting the Webpack tractor beam pull us in as even us at the changelog have been pulled in.

We use webpack to build our assets um yeah but what is it not about webpack what about you just first of all tell everybody like you're what you do in terms of webpack in the community helping people you know searching hashtags you know staying up late at night give us a little bit of your workflow and what you've been doing for webpack users. Yeah. So like initially I wasn't very comfortable with making core changes to the library. And so I just wanted to do whatever I could to help kind of encourage smarter people.

You know, people are way more brilliant than I am to get involved. But at the same time, you know, kind of learn a bit along the way. And so, you know, the first thing, you know, my role is literally represents the voice to the community, but at the same time, the voice of the community back to the core team and the organization. So, yeah, I do, you know, from day to day, I probably spend about four hours on Twitter just searching Webpack. And sometimes JavaScript on the side, depending on, you know, if there's something controversial or whatnot. But literally, yeah, 98% of the time if your tweet has Webpack in it

and it's something that I could probably assist with or share guidance or maybe convince you to help add a PR for our docs page or whatnot, that's one of the things that I uh, you know, I'll, I'll respond to, to almost all those tweets. Um, I guess, um, aside from that, you know, we, I think you could see on the GitHub, you know, under my face, it says pushed for the core team to form. So like initially we didn't really have a core team. Um, and we didn't really have any transparency or organization or a medium

publication or anything. And so like, those are some of the things that, you know, I thought really would be, we really needed people to have a glimpse to the inside of what's happening behind the scenes, even if there wasn't much. And so, you know, we published a repo meeting notes, which has, you know, it's my fault too, because we've been so busy, but I haven't updated in a month. But, you know, we have now weekly core meetings. So every Wednesday morning, at least my time, we meet and, you know, face to face on hangouts. And we talk about the direction of the organization and what we need to get done and things like that. And so, yeah, I would say that if you boil it all down, you know, being an evangelist is one thing,

but also somebody who tries to help anybody kind of reason with the issues that they're having or to help guide them in the right way or just get them excited about using a tool that has just, in my opinion, limitless potential. It seems to be paying off. Do you feel like all that hard work that you're putting in is being fruitful or do you feel like you're spinning your tires?

You know, I would say that if we look back from April where I first got involved and talked, you know, just first talked to them for the first time. Um, I think on paper, you know, the stats definitely show it. Um, you know, we're, we were already like 400% in increased downloads on NPM. Now we're at about 900 to a thousand percent. Um, so I think, you know, we've really kept the momentum um but at the same time like i think when i started there were a lot of negative tweets about webpack and whether or not i don't know if people are just hiding from me or not or just don't want me to respond i try not to be the person yeah secret words for webpack they can't – or stop using the hashtags.

Antigrams and stuff. Right. So you don't find them. Right. But really, I mean, so nowadays all I see are like article retweets and maybe an occasional person who needs some help or praise about our new docs page and things like that. And so I think it's really

made a difference. And I mean, if you look at our open, our open collective where we take donations and support like that, the amount that we've raised in the time that we since October 15th, when we announced it has been ridiculous. Yeah, absolutely. It just speaks to the benefit of having someone like yourself around and supporting people who are, you know work in many ways and interesting technical challenges and solving needs. And yet, you know, you kind of kind of put a package on it. You have to put a, you have to have, you don't have to have, sometimes the, sometimes the, you know, the meritocracy works, but lots of times, especially a tool that is dense like this, it's difficult to get into, you know you know you you see the configs and as an outsider you're like wow this is too hard for me to use i'm going to go back to whatever you know scripting i had or just script tags or whatever

but um the value of having a well-rounded team i guess is what i'm is striking me yeah and having somebody of your skill set who's technical and on the inside, but is doing more of the docs, the helps, you know, thinking about it as more of a product or a overall package. Yeah, absolutely. I mean, and I try to, I mean, because I always thinking about sustainability or the future, you know, every day I spend at least an hour and a half just reading the source code and trying to learn more because I'm only at about 70%. So, like, I've gotten, you know, maybe about 10 or 20 commits now into core. But, you know, there's so much more that I need to learn to be able to help people, especially when it comes to more difficult challenges.

But, yeah, you're absolutely right. I mean, Andrea Goulet, I think her name is, I listened to a talk at Nebraska JSConf that she did this year. And it kind of like, it touched me in a way and really validated my reasonings for what I did. And it was saying that no organization will succeed unless it has great communication. And it's just as important as the code itself. And so being able to have a voice for the people and vice versa has really, you know, bore fruit of success for us. And I mean, even like I've seen impacts that we, our work has had on other people who are maintaining repos. Like the support that I've seen impacts that our work has had on other people who are maintaining repos.

The support that I've seen has increased for Babbel and React. People who didn't really have super strong advocacy, now you find people who are doing it extremely well. Can I credit that to what we're trying to do? Maybe not, but I think everybody together is seeing the value. Also worth pointing out that this is all happening very fast. Because like you said, you're hearkening back to the good old days when you got involved back in April. Right? Yeah, I know, right?

This is the speed of the open source community. Lives change very quickly and projects live and die very quickly. But one thing, just for the audience's sake, if you want to troll Sean, this is what we did with a Changelog Twitter account. I think it was last week when we were getting ready for the show. We went out there and made a tweet about the first time you demo webpack to a friend and it's a gif of a guy showing off his knifing skills. He throws a knife and it bounced back, almost hits him in the face. I just hashtagged that webpack, not because I actually dislike hashtags as a thing, but I knew if I hashtagged it webpack that Sean

would definitely see it. Sure enough, he replied to. So he's out there on the Webpack hashtag. If you want to troll him, just put something ridiculous on Twitter and then make sure you hashtag it Webpack and Sean will have to see it. Or just, it could be like a silent thank you or a silent, a passive way to like say hello in a kind way, I suppose. It was a troll of love. It was not a troll of hate. I hope you felt that love, Sean.

I was jesting. Absolutely. I did. I thought it was funny, too. It was good. All right. Well, that's going to be our first break opportunity. So we've been talking about Sean and his history with Webpack and Webpack as a movement and kind of one that he's been ushering in and

helping along. But we haven't talked about Webpack, the tool, the project, the technical merits, those kind of things. So we'll take that up on the other side of the short break. Hey everyone, Adam Stachowiak here, Editor-in-Chief of ChangeLog. And I'm talking to a Rollbar customer. Rollbar puts errors in their place rollbar.com slash changelog check them out get 90 days of the bootstrap plan totally for free i had a conversation with paul bigger the founder of circle ci and he talked deeply about how they use rollbar and how important that tool is to their developers. Take a listen. CircleCI is a continuous integration and continuous delivery platform.

Our customers are the developers in an organization. Developers rely on us heavily as part of their deployment workflow. So let's assume anyone listening to this is someone who needs to use Rollbar. Someone needs to know about this tool, needs to know about this product, needs to know how it's changed how you do business because of it. I'd like them to know how important this tool is to you. And a better question might even be, could you have done what you're doing with CircleCI without Rollbar's help? We operate at serious scale. And literally the first thing we do when we've created a new service is we install Rollbar in it. We need to have that visibility.

And without that visibility, it would be impossible to run at the scale we do. And certainly with the number of people that we have. We're a relatively small team operating a major service. And without the visibility that Rollbar gives us into our exceptions, it just wouldn't be possible. If there's people out there who ship code without rollbar, I can only imagine the pain that they're going through. Oh, that's awesome. Thanks, Paul. I appreciate your time.

So listeners, we have a special offer for you. Go to rollbar.com slash changelog, sign up, get the bootstrap plan for free for 90 days. That's 300,000 errors tracked totally for free. Get Rollbar trying today. Head over to rollbar.com slash changelog. All right, we are back with Sean Larkin talking about all things Webpack. Sean, we haven't even talked about what Webpack is. We just kind of assumed our audience knows and they probably do know but that being said tell us what webpack is and what problem or what problems it's trying to

solve and we'll kind of go from there so maybe i'll describe the problem or this you know what things were like two years ago uh in the web development community so So, um, before we had module bundlers, which is what web pack is, um, the primary way to add code to your website was to either include it as script tags, whether it be multiples or just have like one script tag. Um, now a lot of times maybe you can think back to, you know, I can remember cases for me, some places I've worked, we had like 30 or 40 script tags in the browser. And we struggled from all sorts of issues from race conditions, some code was relying on other code that didn't execute quick enough, or you were loading libraries like lowodash or Underscore that maybe you only use two functions from, but you got the whole library.

I know that happens with Moment.js also. So things like that as well. And we're ending up with these huge, slow, tons of network requests that are caused by doing so. But then also at the same time, we were using so much duplicate code and code that, you know, never even was run in the browser when you used it. And so the node community, when it comes to running JavaScript uses a slightly different approach where you start with one file and then kind of a module loading system, which

is, you know, common JS or using the require statement. And so it allowed you to create modules that you could require code from, you know, one file to another. And so it allowed code to be encapsulated, um, as well as allowed you to, you know, only pull or require in parts that you're using, um cetera. And so back in the day, maybe about two years ago, Tobias Koppers created Webpack. And so Webpack is a module bundler that takes kind of that idea of using requires and import statements like in ES2015 and tracing, starting at a single file, which we call an entry point, and then it collects all of the dependencies through each of the files that are referenced

in it. And so the result is one or two or maybe even four or five bundles of code that only contain the code that you're actually using. On top of it, I mean, you could go even deeper and say that Webpack automates tools that are, you know, takes care for you, certain tasks like uglifying your code, minifying, creating source maps. It performs a feature called code splitting, which allows you to split your JavaScript into many asynchronous chunks so that you could load code after the initial render. And so Webpack is kind of like a, it's a developer experience tool. It is a performance enabler with all these design patterns like

lazy loading and code splitting. But it also allows you to do some really crazy things. So it treats everything as a module. So it could be CSS, HTML, images, PNGs, or fonts. And you can require all of those into your JavaScript. And as long as you have the right set of transforms, which we call loaders, you can use that code and bundle it also into your application. And so we say it's a static asset bundler or a static build tool. So it does a lot of things. it does a lot of things. It does a lot of things.

Which is perhaps why it's somewhat complicated, right? Absolutely. Or probably from your perspective, maybe it's not complicated, but from many other people's perspective, or maybe it is because you have to explain it all the time. Yeah, I mean, always giving the intro is kind of hard because it is so multifaceted. And so it can do so many things that I always forget like 30 things that I can do while trying to explain it.

Something that's useful sometimes, and I like the way that you cast it in terms of, you know, this is how things used to be and this is how things are possibly with Webpack. But what about in the context of other tools? So many people may be familiar, for instance, with Rails Asset Pipeline. They may be familiar with Gulp or Grunt. They may be familiar with Brunch or these other tools that do similar things. They have some sort of overlapping features, but they don't all do the same things. Can you cast it in light of existing tooling? Yeah. So like, for example, Grunt and Gulp are just task runners. So they're going to perform operations and you write tasks that do things to your code.

So let's say for an example, the example I like is that let's say you're using like Lodash and you want to create like a big, a bigger monolith JavaScript bundle, you're really grunt and gulp don't understand the dependency graph that Webpack creates when it runs. And so what's happening is that you're getting that entire, you know, you're just smashing a bunch of JavaScript files together and concatenating them instead of only requiring the dependencies and parts of those libraries that you're using so that would be one thing um yeah i think also like uh instead of having separate tasks for each of your types of files which you would probably do with grunt or gulp webpack is like the single uh running ahead-of-time compiler

that handles all of those things for you. Say that again, one single ahead-of-time compiler. It's like you run it once, but it's performing all those tasks behind the scene that you configure. But it's like a ahead-of-time compiler for the web. Gotcha. One thing that you mentioned, and I've seen it in practice, I still don't completely understand the advantage.

So maybe you can help with that is bringing your CSS in, bringing your images in. I can probably enumerate a few advantages, but I'd prefer if you did it. Because traditionally, I've been down with, let's minify it and concatenate all the JavaScript. Let's uglify the JavaScript and let's uglify everything, but keep them separate, keep them safe, you know? But this is, this is a whole new world where it's like, let's just put it all in one big

JavaScript bundle and, and then break that up into, you know, chunks that make sense and ship it. Why is that better? Well, so really it's, um, what I like to say is you don't have to bundle your images into your javascript but you want to have those images managed by webpack and so um we can use one of the loaders or transforms that i talked about as an example so if you want to um let's say have an image that's loaded into javascript or you require it into a javascript file you have two options on that loader that say specify a limit which is just a file size and if that image is over that limit then just go ahead and emit it to your build directory or your dist folder. Otherwise,

if it's under a certain limit, then go ahead and base 64 and mine it because the cost of an extra network request is greater than the cost of the bundle size. I'm sure that they do because you guys are on top of the curve, but the know the up-and-coming hdp2 protocol is it still a case that that's better with h2 because of the pipelining and the single connections and all the other things that they have um where it isn't good there there's benefits and there's disadvantages so like um you can still uh like for example um when you're bundling you can actually we have some features for h2 called like the aggressive splitting plugin and so what that does is it leverages that idea of the streaming or multiplexing

that can handle let's say 50 concurrent network, and you can create 50 small bundles. But to just, let's say, use like a module loader and dynamically run every dependency and require statement, you know, as like a network request, it's at least the studies that have been done so far show that having smaller bundles is more performant than it is to just have no bundling at all. That is interesting. Give me a second. I'm just thinking about my next thought. Stuff too much.

Just thinking about the next place to take that. I have a potential suggestion. Okay, go ahead. I'm thinking, like, who is it for? Like, who is it for? Like, who primarily uses it? What kind of developer? Like, who cares to this degree?

Like, performance? People who care about performance? I mean, that's kind of everybody to a degree, but, like, who in particular? Well, you'd be surprised. In a perfect world, I'd want it to be for everybody. There's some people, let's say, like, Dan Abramoff of the React and Redux team. He thinks Webpack is a very low level tool. And in some cases, if you look at all the wrappers that sit around it, maybe that's the case. But I mean, in my

opinion, we want to make it as usable for anybody to take and just say, I want to be able to split my code up. I want to know how performant these bundles are. I still want to be able to work in any dev flow or dev stack, use any type of templating or preprocessing and have it just work. And so, you know, that's kind of our goal is to be able to make it easy for anybody to use, but at the same time not sacrifice performance. So what are some of the steps that you guys have done to get there? So we've had Webpack 1 for a while now. Webpack 2 is coming out. It'll be here, fingers crossed, 2016 calendar year.

Webpack 2 will ship right now. It's a release candidate stage. I know you've put a lot of work in the documentation um you know you have example webpack configs because that's i mean that's actually a huge boon because you have to basically configure webpack you know with a config file and um you know having like this is what i want to accomplish here's a config file that looks like that that's very helpful but what are some other ways that you've smoothed it out and with webpack 2 and tried to bring it up a level so that people can use it without feeling like it's a low level tool like dan says yeah absolutely so like the first like you said was

our new documentations page like originally that was the only thing that we wanted that was really holding back webpack 2 as a release candidate. And we just finished that milestone, so you can check out webpack.js.org to kind of get that new experience. So I think, you know, some of the things we want to do is, like, simplify the way things can be done. So I guess, you know, early on in version 2, you could write those transforms I talked about, loaders, you could write your, those transforms, I talked about loaders,

you could write them in like 30 different ways. You could pass a loader property or a loaders property. And, you know, there wasn't really any way that was the wrong way to do it, but there were caveats for some. And so like we wanted to you know make things a little bit more explicit and so like a smaller example is that you could say the name of the loader or you could do the name of the loader dash loader so like babel or babel dash loader um and so we've made that explicit now we're slowly trying to you know not have a bunch of breaking changes but also have very simple ways or one way to do things um i'd say another huge thing is our configuration validation so this is something that just landed as of like beta 25 um and it has significantly

reduced the amount of errors we've seen on our github and twitter etc but essentially if you have a property that's not correct or is in the wrong place, or let's say you put the plugins property inside of somewhere it shouldn't be, we now have a schema that will validate against your config and give you an error. It'll prevent you from even building and saying, hey, this is wrong.

This can only accept a string or an object, et cetera. That's been a really huge usability enhancement. I can attest to that first one because when I was first getting going, I got Webpack working really quickly, which was great. But then when I wanted to do slightly more fancy things, you start looking at examples. And because there is, know like he said maybe 30

ways there's lots of different ways to go at the same thing all of the examples out there are different and they're all trying to accomplish you know the same thing and they look different than my config and so just in your example mine says you know sass and then an exclamation mark and then css or whatever and but it should this one says sass-loader and it uses ampersands. There was no continuity or consistency in the examples of other people's Webpack configs. That makes it very difficult to piece yours together. And so I think that's a great move is let's simplify the happy path to just be this one. This is how you should do it.

Absolutely. We've actually felt you guys doing that. We've been upgrading on the betas of Webpack 2, and our config begins to go into deprecation mode. You shouldn't do this anymore. We hit a couple of those, but it's a beta, so we can't complain. People will complain though. Oh, of course. That's okay. We like that though. We, we want to be able to, that's like one of those things we love is having the people who have the strong

voice and want to, you know, be candid with us because we want to talk about the issues. And I like to say those kinds of people are like our best future contributors because, um, you know, they have good ideas in addition to, you know, some heavy complaints. Right. So one of the features that you mentioned, which I does, I do think sets it apart from all the other ones is the removal of code that you're not using. Is that, is that called tree shaking? Is that the same idea or tree shaking something different? Well, it's kind of like, yeah, it is. So it is a feature of Webpack 2, probably the most sought after, I guess, for size. But essentially what, you know, since Webpack understands every dependency statement in each file, it can see what code is actually used or not.

And that's kind of like the tree-shaking part. But then there's also dead code elimination, which actually is what reduces the size of your bundle. And so Webpack actually isn't responsible for the dead code elimination, but what we do is we mark those dependencies as unused, and then Uglify.js, through our Uglify plugin, will actually remove those statements that are not used, as long as they don't have side effects. That's very cool. What are some other bleeding edge features, the real sexy stuff that people love about Webpack that gets, you know, something that gets you excited, gets these future contributors, the ones that are complaining the loudest,

but also are adopting the newest things? What's some of the bleeding edge stuff that's exciting? I would say probably just being able to do code splitting just blows people's minds. I don't know another tool that does code splitting the right way and effectively. And so I would say code splitting is huge. Just being able to create these asynchronous chunks

of your code and then lazy load them into the Webpack environment, that's really profound. Like React Router and Angular 2 Router, all of them are using the patterns that we recommend to do code splitting just from their libraries themselves. And so people love seeing that they can actually reduce the size of their bundles just by, you know, a simple system.import or require.ensure or the newest one that we just released, which is up to date with the ES spec import

with, you know, like parens as a function. I guess other ones that are kind of bleeding edge and super sexy, I would say, are the ability now that, so one of the things that I really love about, you know, what I do specifically with the community is that I also get to be the one who speaks with the most incredible developers like Addy Osmani and the Chrome team and the Edge team, the guys at Firefox. And so

Addy and I partnered together to create a feature in Webpack that can help increase awareness. So you'll hear probably performance budgets get thrown along around a lot and so now by default as of this latest webpack build um you will get warnings in your terminal that say hey this these bundles are over a certain size you should reduce them um you know to have better load time performance. And, you know, we'll do some things like if we don't see code splitting, we'll say, hey, you can reduce the size of your initial load time by using system.import or import or require ensure and kind of give them like a help document that shows, you know, about code splitting.

What are the biggest things holding it back for new users? You've addressed many of those, but surely there are things outstanding that people will get tripped up on when trying to use Webpack. I think the number one thing is probably, that's hard because it's like, I want to say it's just the lack of learning. And so, you know, I would like to think that our new documentation is really repeated um but i think holding it back from new users yeah probably the usability of the configuration i know that that's a really big challenge uh for a lot of people who just don't like it or don't understand it. I guess maybe for more people who come from a different or who are really big on performance and size bundle,

they will probably say that they would want to choose something like Rollup, which uses a little bit more performant technique to make your code as small as possible. Give us kind of a high-level rundown of the config, because there's a lot of verbiage. You have modules, rules, loaders, plugins. You have exports, entries, outputs, resolvers. Can you explain it?

It's tough because we're just in audio, so we can't refer to common code. Well, that's okay. But could you explain it to us in layman's, as much layman's terms as possible, how the config lays out? Sure. So I like to deliver it in like four concepts or five concepts. So think of it as a concept but then also a property on the configuration. So your webpack configuration is just a JavaScript file which exports an object or an array of objects and that object is your configuration. So it's going to have some properties at the root level and these properties describe how webpack is supposed to bundle your code.

So the first concept is entry. It also maps to the entry property. But what an entry is to Webpack is the first place to start to create your dependency graph. So you can think of it as like the top of the graph or tree. And what it does, it's going to scan through all of those dependencies and collect everything into a compilation or like a bundle. The output, so entry point tells Webpack where to start and what to bundle. And then the second is probably the output property. So output, you know, describes kind of, you know, what the word is, is that it tells Webpack how and where to bundle your code. You can specify like a file name and a path. And there's some more advanced properties. So let's say if you wanted to like make a UMD wrapper around your code, so it could be using a script tag. You can do so. There's some more advanced configuration under output.

But the simplest ones are just file name and path. So the output will describe how to treat your code and where to place it. And then the next property or concept would be loaders. So essentially what loaders are, are single file or file, one file to another file transforms. And it's a loader behind the scenes. If you look at a no module, it's just a function that is exported

that takes a source argument and then returns a new source. So there's all sorts of different loaders that are out there in the community. But the best way to describe what a loader does is that it is the last step in resolving your code to convert it into JavaScript. So it performs those transforms for you. And so it doesn't map directly to a loader's property. But what it does map to is module. Since everything is treated to Webpack as a module, you're basically specifying the rules for the type of modules you're importing. And so if you look in a configuration, it's set under module.rules or module.loaders. We haven't deprecated the term loaders yet, but you can use either or.

We want that to be a graceful deprecation since a lot of people use loaders. And then I would say probably the last one is going to be called plugins. And so to Web webpack plugins are kind of the backbone of the entire system um behind the scenes 80 of webpack source code is actually plugins itself um that's nice but we yeah it is i mean we externalize that process so people can create custom plugins to hook into the compiler lifecycle of Webpack. So the easiest way to describe what a plugin is compared to a loader is that a plugin can do anything a loader cannot.

And so common things that you'll see plugins for are uglifying your code, so minification, as well as emitting extra files or let's say creating different types of source maps if you wanted to or doing kind of anything under the sun. We have a large amount of built-in, out-of-the-box, kind of publicly available plugins

that we made under our optimization folder that you can apply. But in terms of the property and the config, it's just plugins, and it's an array of new instances of these plugins. And I'd probably say the last one. Yeah, I mean, you could talk about Resolve if you'd like to.

It's kind of a little bit for more specific scenarios but so Webpack resolves just like Node.js but we have this entire augmentation on top of it that makes it really flexible and crazy powerful and so we call it enhanced resolve but the property is called

resolve on your config and that's just how it finds things in which places basically in terms of requiring or including different code is called resolve on your config. And that's just how it finds things and which places, basically, in terms of requiring or including different code? Yep, absolutely. Okay. There you have it. Four simple concepts.

You too can be riding the Webpack train. That's what I call the core concepts, I guess. There you go. And a lot of that is in our new docs. So you go to webpack.js.org slash concepts. And I authored 90% of that entire section. So the whole purpose is to be able to give somebody, like a first-time user, a really good journey through understanding the different parts of Webpack, how it works,

and what these things mean to you and why do you want to use them. Very cool. Well, let's take our second break. On the other side of the break, let's get back into the conversation around sustainability, the Webpack team, what you've been doing with Open Collective as well as JS Foundation. Lots of interesting things there around Webpack

and making it a sustainable project because more and more every day, so many groups and companies and individuals rely upon it to bundle their code. So we'll take that break and sustainability will be on the other side. I talked to Daniel Reed, head of design at TopTile, about their new expansion into Topau Designers, doing for designers what they've done for developers. We talked about why Top Tau works for designers, and this is what she had to say. As a designer, the big, or as any kind of creative person, the big overarching question is always like, how can you find inspiration? And for me personally, and for a lot of creatives that I've spoken to, it's really about traveling, exploring and being accountable for your own career.

And I think as a TopTile designer or a remote designer in general, the ability to be able to switch up your lifestyle, change contexts, meet new people, have new ideas sort of infiltrated into your life by having that freedom and flexibility is something that's absolutely fundamental to doing great work. That's the real power of TopTel, I feel. You're not just stuck with one product, one company, or even one agency, but you can choose to work on multiple occasionally or a range of different clients. And I think that that keeps you fresh. It gets you involved in new technologies, different people, and is really fundamental for being sort of switched on as a designer. All right, that was Daniel Reed, head of design for TopTile. To learn more, go to toptile.com slash designers. That's T-O-P-T-A-L dot com slash designers. Tell them Adam from the Changelog sent you.

And now back to the show. All right, we're back. And Sean, during the intro section, you mentioned how one of the first things you, one of the first topics that you broached with the Webpack team was sustainability. And I've talked about sustainability with you offline and you've been interested in RFC, Request for Commits, and the work that Nadia's been doing around sustainability.

You've also started what I consider to be a very successful open collective. Now you guys are supported to the tune of $27,000 a year, which is pretty good. Not going to, you know, not going to support four people full time or anything like that, but still nothing to balk at. That's like over 700 people, individuals and corporations helping you out. So talk, talk to us about, first of all, the Webpack team and what it looks like in terms of like who, you know, who is being supported and then talk about how you've gotten support and how you need more support and these such things. Yeah, totally. So, um, the core team consists of five people, uh, myself, um, Tobias Coppers, who lives in Germany. He's the original author. Um, Juho Vepsaline, who lives in Germany. He's the original author. Juho Vepsaline, who lives in Finland. And he has is the maintainer of DevMiddleware and Webpack

DevServer, as well as Johannes Ewald, who is in Germany, who has been really involved. You know, he is a designer by trade, but also an engineer. And so he's been extremely involved with CSS Loader, Style Loader, SAS Loader, Less Loader, and helping kind of support those communities and fixing anything that goes back to core. And he designed our newer logo that we have released. I forgot to mention that Case is also from the Netherlands. I believe he's in Amsterdamsterdam i'm not 100 sure um but then we also have kind of a second tier of people who we just call the contrib team

and they're responsible for helping maintain all of the loaders and plugins that we have underneath our organization um and so we have like a private Slack community that we use specifically for the purpose of communication, kind of a little bit less static collaboration, I suppose, or, you know, with less fluff. You know, we wanted to do something public like Gitter or Discord, but it was, you know, we found that we wanted to be able to still have some sort of private environment so that we could effectively communicate to these people. And then I think we also have a team like the Analyze team who works on our bundle analyzer, which you can find in our old docs page.

And then our documentation team, so people who've been really involved in just helping support and work on Webpack documentation. So one that has been really involved and we're ever grateful to her is Pavithra Kodmad. And she's from India, but she works for Flipkart, who is a heavy user of Webpack and really got the spotlight shown on them for reaching kind of a next-tier level of web performance. That's a big team. It is a big team. I mean, it's kind of like herding cats sometimes, especially even for us as a core team because we're all in different time zones

for the exception of Johannes and Tobias. So in terms of sustainability and what we've tried to do was one of the first things I wanted to do was I wanted to meet every week. One, because I was totally new and just happy to see these guys and talk with them and learn more. But two, because we needed to have some sort of direction and it didn't exist. And so we meet in the mornings, which is kind of their afternoons that works well on a certain day and every week. And we kind of talk about things that need to be done, things we want to do. And then as an organization, any like house cleaning, like, you know, legal stuff or trademarks or logos or, you know, T-shirts or anything like that. So this is all from april like you became part of the core team in april the core team was formed in and around that time officially and the rest of this team you're talking about has been added on since then is that

is that true yeah so like for the exception of Case, who is now a maintainer as well, everybody, I think beforehand, it was just us four. And we didn't really have a contrib team yet. And it was something that we talked about. We really needed to have some sort of support and get people involved. So we did like a call for maintainers for, you know, these smaller libraries that are in our organization that needed some love. And so, you know, once we got that together, we got the Slack organization up and kind of talked about the first initiatives that needed to be done on, you know, 80% of the pages. And so if you look at like HTML loader or karma web pack, you'll kind of see

this really nice template that explains a little bit better, uh, right in the read me what it does. Um, and these teams will meet and do hangouts and, um, uh, we'll add enhancements, fix PRs, et cetera, and reach out to us if, if needed. It's a lot to build in such a short amount of time. What do you think you've done right? What do you think you're doing right to make these moves possible, the proper and healthy team growth and onboarding, not only users, but also people that can help maintain portions of the code base? So at least from what I can do as a person,

is that if anybody ever wanted to learn more about webpack um you know i i very clearly state on twitter all the time that if you want to help maintain and get involved uh to let me know and and i'll usually send them a dm and say hey what what interests you you know what do you like to do? What's your background? Because really, we want to find something that works best. And, you know, to be honest, like, our organization has all sorts of stuff that could be worked on, whether it be documentation or smaller loaders or plugins or maybe Webpack as a core or even, like, some of our other libraries, like our Resolver, Enhanced Resolve, Webpack Sources, Loader Runner.

So, like, I try to get an understanding of who the person is and their personality and what they like to do, and then I ask them what they want to do. And I tell them I will sit down, whether it be on a Hangout or just in Twitter, and I will give you a complete rundown of kind of the library, the plugin system, and kind of everything they might want to know if they want to contribute to Webpack Core and how it works. And so, I mean, I like to think that it's kind of some of those things

where you just sit down and work with the people who you know are really excited and want to be involved. And I guess it's kind of easy when we have a community of plugins and loaders made by other people. And so you can pull those people in and say, hey, we would love you to help us. And like, for example, HTML Webpack plugin, which is Jan, he's known as Jantamon or Jantamon on GitHub. But he did some incredible work with that plugin. We're like, let's get him in the Slack and, and talk about, you know, better ways that we can help increase, you know, the quality of that library, but then also kind of come

up with new ideas and collaborate. So when you said at the beginning of the show, let's get you paid, Jared mentioned opening this, this third segment here about open collective 27,000 ish a year, not quite any single person's full-time salary or, you know, supporting a full team of people, you know, you're talking about how you're looking at the, the bright spots in your community and, and shining a light on them or supporting them or encouraging them or inviting

them into different areas and giving them responsibilities and maybe even something that did well for you, which was give them a title, you know, to kind of give them that badge of like, here's something that you can own. What ways are you using the money you earn? Like I know a lot of people aren't really trying to get people actually pay. They're trying to do things that are community building or like new logos. Like how are you want to talk when we talk about sustainability and money specifically how do you use that so like i mean in the end we you know to

me like personally you know my dream job or perfect job would be to literally work on webpack full-time or work in open source or you know kind of help bring these things together and collaborate to kind of build you know to push this project forward but um so like to me my goal is to really hope that we can get enough sponsors and and uh backers to really get us that to that point um 250 000 as an angel budget sounds crazy and almost unattainable, but technically we've already gotten 10% since October. Um, but realistically, uh, speaking, you know, some of the things that we've done that are kind of small is like we have, uh, you know, we've, the core team members themselves can

submit expenses on the work that they've done. Um, and we kind of like divvy it out based on the amount of funds available and kind of the hours that we've worked. And so kind of Tobias tracks that a little bit. Um, but then also additionally, like I just spent some money for a designer to, to print t-shirt designs or to come up with t-shirt designs that we can submit, whether it be for t-shirts or other apparel, things like that, because people want webpack t-shirts and they've always expressed it and thought it was cool. They like our new logo. And so just another way to give somebody, you know, that kind of personal

feel and ownership of some sort of contribution to our organization and community. What I like too about Open Collective, since you're using that as the, I guess, the platform to present yourself as a collective on Open Collective, but it is the way that they allow you to show your expenses like you're mentioning in a transparent way. So you'd have to go, or Tobias would have to go to open collective and submit an expense and the team approves it.

And it gets shown there for the community to see. So like, I love the fact that you can not only see what your annual budget is, but then also the funds available, but then the actual expenses and who submitted them and for what, but there's, there's a level of transparency that's not normally there if you don't have this.

Yeah, absolutely. And we were really, you know, the challenge was we were looking for a platform that allowed us to kind of manage our money for us, I guess. Like, you know, initially it was just like a patron account or not even a patron, but a gratipay that just went to Tobias. And, you know, up until then, I had no problem with it because he was doing a bulk of the true work. But now this is a platform that kind of holds onto this money in like a nonprofit account, but then also at the same time, lets us be transparent. And then it gives other people to kind of do like a bounty source thing. So if somebody else wanted to help fix an issue that was kind of on our priority list, we would pay them out for it. You say nonprofit, you mean whenever someone contributes money to you, it's a tax deductible gift.

You know, if you're in the U.S. or I'm not sure about abroad, but at least in the U.S., that's a tax deduction for you. It is a 501b something something account um so like the paperwork has not been officially filed i think with the government or it hasn't gotten back yet but that is the long-term goal so it can be a tax-free um source or account for us right it also takes it away from tobias and the you know with the whole gratify situation like that's a good starting point but this allows it to be community owned, not one person. It removes the bus factor, removes the potential. This is not BDFL, but like person in charge kind of thing. It also removes that one complexity on potentially like income tax or IRS or, I know it's not an issue for Tobias, but, you know, anybody else in the world might have that kind of concern. Yeah, I mean, you know, the best thing is, like, if we were all to just disappear, like all five of us on the core team, this will still be around.

And so the collective as a whole, what it represents, you know, metaphorically and I guess you could say physically will still exist. And they will help to kind of, you know, to find a new owner, et cetera. I mean, we're not going anywhere, but you know, if that did happen, there's always a fallback strategy for that. And open collective really helps. They're really responsive. Yeah. We we're, we're huge fans. We've spoken with them actually face to face. And I've been very impressed with them. We actually were going to do something on there but hadn't pulled that trigger quite yet so it's something

we've considered but we've had so much happening around us like we mentioned in the break. The new open source CMS, new branding, a lot of new shows so we did have a plan there but we pulled back from it but I love OpenClick. I think it's awesome they've helped kind of bite on my heels a little bit too when it comes to doing special things in the future there's just some things that just fall between the cracks

I have so much coming at me in a thousand ways and I have an 8 month old in the family we're in similar shoes here I got a 9 month old there you go so So you understand. You know, and so she kind of helped Pia. I think it's Mancini and like the rest of her colleagues, you know, at Open Collective.

They have been so helpful in keeping up, you know, and reminding us of things that we should be doing for the future or – and kind of really help support our cause. And that's really nice because I think I can only do so much and there's sacrifices that happen, but with that kind of help, it's so important and has really helped it be what it is today. Are you guys getting where you need to go? I mean, you mentioned you have maybe a $250,000 a year budget that will be supporting everything that needs to go on. Uh, right now you're at, uh, 27,000, which is awesome. I mean, you look at that's a big number, right? That shows a lot of support and there's hundreds and hundreds of people supporting you, but yet it's not quite

enough. It's only 10% there. Do you feel like the 90% is within reach or are you never going to get there? Because right now, Sean, you're very much doing – you're like a startup founder in terms of dedication, right? Because full-time job, wife and kids, life, and then you're on Twitter four hours a day with the webpack hashtag. You're doing personal hangouts with people. You've even helped me on Hangouts. I can't remember what we used, but just with my Webpack config. So you're doing the yeoman's work,

like the grunt work, and you're putting all the investment in. And you mentioned earlier that your end goal would be full pack open source, full pack. I'm going to be saying web pack every other second. Full time web pack, full time open. Yeah, it's working.

Full time open source. Do you think you're going to get there? You know, like I try not to have expectations. I mean, I can tell you what my dream is and what I think, uh, you know, something that's perfect for me. Um, but I'm not sure. Uh, it really, it's kind of a cultural, it's a culture issue. Um, and we're kind of like in between the problem of a culture issue and funding for free things. And so it's like, we're a build tool or a bundler. And even if we are getting, you know, 3 million downloads a month, and we're the top 1% package in NPM that's downloaded, I think we're still a tool that many people see as

constantly getting replaced, because in the past it has been. And most, let's say, business owners, marketers, managers, don't see the return on investment of a tool like this where um you know i think we have some opportunities to maybe show that more to help kind of increase the awareness um but yeah i mean do i think it's possible uh yeah i mean if everybody who downloaded it once from npm for a cent or you know we'd have our budget in one month so like we know the user base is out there um and this system has has shown in just two months to have you know 100 backers and how many corporate sponsors i have it right here 12 to have 12 corporate sponsors already has just you know it it's humbled humbled me and really showed me the people

who really care and understand. And I think as long as we keep pushing that message forward and the people like Nadia Eggball and Pia and, you know, all these people who understand the importance of sustainability with these tools continue to, you know, increase that awareness and we all do together. mean anything's possible i think you may have stumbled across a solution right there npm install tolls just you know yeah i mean every time you install you just pass a penny micro payment over to the webpack team you know just a penny uh you know like i i'm not sure if that would be like maybe it's a good idea. I feel like it'd be really hard to regulate, but to be honest, like something that I thought would be a cool

idea is like brave, you know, the, the browser that's kind of trying to do the whole mobile support micropayments for ads and everything like that. Like, uh, that would be a perfect platform. You visit a page that uses web pack, You give, you know, five cents to their organization. Boom, problem solved. All sorts of interesting possible solutions. The fun and interesting part is we don't know what's a good idea and we don't know what's a bad idea. And so sometimes we just have to experiment and find out. It's true.

I mean, you got to hit it from all sorts of different ways. I mean, I think for us, maybe there's a future of doing some sort of webpack enterprise where we have a private-based service that we sell. I mean, like you said, the roles of somebody in open source and making it sustainable really align and start to merge with something of that of a startup and so you have to find unique ways like providing specialized vip support which like for our if you sponsor up to 500 to a thousand dollars a month for us we will give special support hours that you can sign up for um so it's things like the support um you know kind of maybe custom work or consulting as well as like even maybe a private product that's built for the enterprise level which i think a lot of people have really thought about doing or do do you mentioned earlier that you know some people are skeptical because of the

tooling in the javascript and front-end world constantly changing. And we've had a lot of debate around JavaScript fatigue lately. You like to cast it not as fatigue, but you call it the JavaScript renaissance, which I like, because I think it shows an optimistic perspective that is refreshing. But that being said, is Bundler another step on its way to something greater? I called it Bundler. Gosh, Bundler is a Ruby tool. Is Webpack a step in the Bundler renaissance, or is it here for the long haul?

Oh, I think it's here for the long haul. You can actually kind of see it happening in like the course of a, a year's time where you'll see all these kind of like imitators that do lots that say they do lots of these things, but then boom, die out. It's the reason is because you can't, at least I have yet to see, we'll just say that I've yet to see any tool that can reach feature parity and

flexibility and pivot and change, you know, and keep up with like the spec, the JavaScript spec, the tools that are around us. Been able to pivot as fast and add that much, you know, kind of feature parity that, you know, Webpack has. And so, you know, we've kind of set the expectation of you need to create source maps, you need to support hot module replacement, you need to be able to work and manage CSS styles and any type of asset, you need to be able to code split, you need to be able to reorganize your code. So for cacheability, you need to be able to, you know, split your code up into tiny bundles for H2. You need to be able to tell me whether or not I'm creating too large of bundles or advise me, or you need to be able to have an infinite

plugin system that works, that can do anything. I mean, a lot of tools try and accomplish those things and then fail. And I mean, a lot of times I say just, you know, that's one of the things I really have been trying to encourage is, you know, I want to find those tools and say, hey, do you guys want to help us make our tool better? Not from an arrogant standpoint, but from a let's make something that lasts and push it forward that benefits everybody together. I mean, even when it comes to like roll up, you know, we we're adding roll-up features and Rich Harris, who created it, is going to help us. And so, like, you know, we want to work with as many people as possible with browser vendors. So, like I said, the Chrome team and we're working with the Firefox team behind the scenes with dev tooling and source mapping. We've talked with the Edge team to do custom instrumentation.

We want to bring in as many people as possible and set our roots because we want to be here forever or as long as we're needed, I suppose. There you go. Before we close the show, I definitely want to say on behalf of me and Jared and the rest of the team here at ChangeLog that we thank you particularly, Sean, for your efforts

to step up and do this for the team, but also to the rest of the team, the core team, the contribs, and everybody else that are involved with Webpack. I think we need people like you in open source. Thank you. It's exciting to have this conversation with you. But if you had the ear of everyone out there

who cared about Webpack or should care about Webpack and they want to get involved or you want to give them an invitation into different areas, what are some things you can share in terms of easy inroads to get involved or how to become a contributor themselves? So the best way is to, I would say, check out GitHub. Put an issue on either our core, which is webpack slash webpack, or if you want to get involved in our documentation,

you go to webpack slash webpack or if you want to get involved in our documentation you go to webpack slash webpack.js.org um you can even just create an issue say hey i want to get involved how can i help um and then you know i'll probably reach out and communicate with you or you can even just tweet me on twitter at the lark and yeah t-h-e-E-L-A-R-K-I-N-N. And you can control me on there. Just say Webpack in a tweet and I'll probably find you and say, I want to get involved. How can I? Okay.

We can direct message and talk about different ways and find the perfect fit for you. And you mentioned the Open Collective and the budget you have there, different things you're doing there. Where does that live at? Is it webpack.opencollective.com or is it opencollective.com slash webpack? That's correct. It's opencollective.com slash webpack. Gotcha. So check that out.

You'll see the budget there if you want to be a corporate sponsor. There's ways to do that there. The budget's listed. How the money's being spent is transparent, so you can freely give money and know it's going to the right places and see that it's going to the right places to support this awesome community. Well, with that, I think that's pretty much it. I mean, thanks to the listeners for tuning in. I know this is a slightly longer show, maybe by a few minutes, but definitely

a good deep dive into your past, where Webpack is going and how this community is being governed and informed and led by you and others. So that's super awesome. If you're listening to this and you haven't yet subscribed to ChangeLog Weekly,

you gotta do it. It's an email we ship out every Saturday. And I'm only telling you this because you're missing out if you don't subscribe. I'm sorry. What do you think, Jared? Do it. Do it. Do it. Do it.

ChangeLog.com slash weekly. Do not miss out. Don't be that person. Get the email. Read it. Love it. Share it. Do it.

All that good stuff. Do it. Do it. Do it. We're back. Do it. Weekly. All right. And with that We're back. Do it. Weekly. All right.

And with that, let's call this show done and say goodbye. Goodbye. Do it. Sayonara. Do it. All right. Just a reminder, this is the final show of 2016 for The Change Law. We'll see you next year in 2017 with new shows, a bigger network, a lot of fun stuff we have planned.

Stay tuned. Head to changelog.com. If you haven't been there in a while, subscribe to Master. Go to changelog.com slash master. Get all of our podcasts. And don't forget our weekly email, changelog.com slash weekly. We'll see you in 2017. Thanks for listening.