Tobias Koppers // @sokra

Tobias: I created a prototype, basically kind of forked the project. I re-implemented it from scratch, with code splitting as feature. And this was the birthday of webpack.

Brian: That’s Tobias Koppers, maintainer of webpack. And this is The ReadME Podcast, a GitHub podcast that takes a peek behind the curtain at some of the most impactful open source projects and the developers who make them happen. I am bdougie aka Brian Douglas…

Kathy: And I am Kathy Korevek.

Brian: In every episode, Kathy and I invite a maintainer or open source developer into our studio to explore their work, their story, and where the two meet.

Kathy: In this episode, we speak with Tobias, whose project, webpack, is used by developers all over the world. An open source JavaScript module bundler, webpack allows frontend developers to use a modular approach for their web application development purposes, taking all the code from the application and making it usable in the browser. Tobias started working on modules-webmake and it wasn’t offering the features he needed. So he built webpack and people from all over the world started contributing. Soon enough, sites as well traversed as Instagram spoke of using webpack and it took off. We spoke with Tobias about the process of building webpack, how he got support for it, and where he sees his role within it--while also balancing a new full time job.

Here, Tobias shares the origin story of webpack.

Tobias: It started at the time I was studying. So because of my computer science studying include some Java and basic programming languages. And we also did lots of projects, of course. And I did a project with Google Web Toolkit and it’s some kind of Java to JavaScript compiler for the web. And it has a nice feature which was code splitting, which allows you to split part of your application into a separate build that is then loaded on demand on the page. It’s probably because Java created a huge JavaScript bundle, but anyway, I liked this feature.

And later, doing my master thesis, I did a web application and I was looking for some kind of optimizer for web application or kind of tool to build my web application. And I didn’t find a lot. The only tool I found was a modules-webmake, but it was lacking in regards of code splitting, because I like code splitting from GWT, from Google Web Toolkit. And so I created an issue and proposed this feature, add code splitting to this tool, to modules-webmake. Yet generally, the maintainer liked it, but he didn’t want to add it to the tool.

So I created a prototype, basically kind of forked the project. I re-implemented it from scratch, with code splitting as feature. And this was the born day, the birthday of webpack basically. So the prototype evolved into a separate module and renamed it to modules webpack, at the time. And yeah, it started then as its own project and continued a lot.

I had some early users who were interested and wrote a lot of issues. So I basically talked with them a lot on GitHub and implemented features, improved it. At this time my master thesis was done, so that was not my motivation in improving it. More like I had fun implementing that and talking with the people and implementing features they like, and was happy that they liked the product, the open source thing.

Kathy: webpack’s official release date was March 10, 2012 and its impact cannot be underestimated. Code splitting does exactly what it says, splits the code into various bundles, thereby streamlining it and allowing for everything to move much more quickly. And like so many open source projects, webpack was born out of a problem Tobias saw and an effective way of solving it.

Brian: As you discover new things, building on what already exists is always a good way to approach a problem, or acknowledging that things exist is a good way to start. Moving to the next direction of what the future of the web is. And I would say for webpack, me being a webpack user for years, it was something that completely changed my thinking of how I approach bundling stuff and leveraging other tools like Babel and even some of the modern stuff like JSX and React.

So my question is, as you were approaching this problem, did you take any existing examples or ideas and thoughts from web tools like Browserify or Gulp or Grunt?

Tobias: So yeah, obviously from modules-webmake which was where I took the issue. I later discovered Browserify and RequireJS because at this time, I didn’t know about them. And if I would have known about that, I probably would have used them, but I think I just Googled too few stuff.

So yeah, I wasn’t into web development at this time. So it’s more like starting this project and didn’t know anything about it. So of course, all the other tools inspired webpack. I think it’s also a good thing in open source that you can, and you are allowed, and it’s not bad to copy or be inspired by other tools around and maybe solving their problems a little bit different. And continuous involving and I also think that many other tools are being inspired by webpack. So it’s take and give.

Kathy: It’s the foundation of open source, being able to give and take, but also build new resources for people to create the foundation for their products. Brian and Tobias discussed code splitting as something that’s built into some new frameworks, like Remix and Next.js. Because of this, you no longer need to think of incremental static regeneration but you could build a certain portion of the site on demand. Did Tobias feel like the approach that webpack had, to basically bring code splitting and bundling to the masses, impacted where we are today in the modern web?

Tobias: Yeah, I definitely think so. I think at this time, when webpack was created, it was too early and it wasn’t really needed for people to have code splitting. So I think webpack was pretty early in doing something like that, but I think it was also the right direction because I think it influenced and everything moved towards bigger applications and moving towards the need for code splitting.

So I think that was one of the success factors of webpack, that we had this feature very early and it pretty much was majored in the webpack years before it got mainstream, maybe it got mainstreamed because of webpack or I don

t know. Code splitting was then mainstream because applications grew a lot and got bigger and bigger, and more moved to client side. And I think that that created the need for code splitting and all that.

Brian: Yeah. But speaking of mainstream though, I know a bit of the webpack story and how it took off a bit, and I know a lot of the help came from the React community as it was up and coming. I’d love to hear your take on that from your angle of the React team eventually finding out about webpack and how it took off from their engagement and also promotion.

Tobias: The biggest promotion for webpack in the early days was Pete Hunt and OSCON. He basically did a talk about how instagram.com works and he basically did a lot of existing tool sets for features. And so, at the end, they used webpack and it helped them to solve all the issues. The most pressing issue was code splitting and the most motivating issue also. The other point was that webpack, it wasn’t intentionally from me, but it has the idea about, “everything is a module.” So basically, not only JavaScript, but also style sheets, HTML templates were modules in webpack. And so this was also, I think, one key point of them using webpack to integrate everything, the whole application into a single dependency graph. And to be able to, if you delete this JavaScript file, or load this JavaScript file on demand, it will also load the dependent style sheets on demand, and assets on demand, and all the things--everything is connected in a big graph.

I think also, at this time, React was created for instagram.com. So basically, both evolved at the same time. And I think they all work great together and solve similar problems about components and building applications up in pieces and thinking in components and modularizing your application.

Kathy: Because of the success of Instagram and how many people mirror its architecture and solutions, webpack has found mass adoption. It also points to something so special: Open source software is the backbone of more than many realize. And while webpack is successful, its team remains fairly compact, about 20 people. So to remain strong and afloat, it has taken sponsorship from large companies. We wondered how Tobias approached getting sponsorships through Open Collective.

Tobias: So basically, it was at the time where Sean Larkin joined webpack. He basically was drawn to his idea that he wanted to get us funded, and wanted to make a team, and get us organized. And he started getting a core team, and was joining Open Collective and also joining the Chase foundation. And did a lot of talks about webpack and motivated companies to start sponsoring. And I think it was pretty unusual to sponsor open source projects at this time. At least it was not mainstream, it’s more like very exceptional. Yeah. So I don’t know what he did, but he did a good job on getting, luring companies into sponsoring webpack.

And I also think that it was very important for webpack. Because of the sponsorship, I was able to do it full-time and we were able to fund a lot of other contributors. And I don’t know exactly, but I think that many contributors staying, could afford… they could contribute to webpack because of re-paying our contributors. I always want to make it that contributing to webpack is not a lost game where you invest a lot of time, but you don’t get paid for this time or don’t have anything for this time. So it should be. It’s not super well paid, but it’s at least something you can live with and it’s not wasted time. Or I don’t want to dis-motivate people by not getting anything about it.

Brian: There’s something that’s a correlation I’ve seen a lot with projects, where you write some code, people start leveraging it, it either takes off or just sort of sits there. Like, you only have two paths. But the webpack project, it got adoption and you saw some success there. And Sean came in as, I guess, could you attribute him to be the visionary or the operations person to be able to have that connection to Open Collective and to get into all these conferences and meetups in the US? I’m curious. Do you, do you see the correlation of being able to have someone to do the non technical work for the project? And do you find success from that?

Tobias: For our project, it is definitely some kind of success because Sean did a lot of public relation stuff and I did a lot of maintaining stuff. And I think we’re good together because he was good as public relations, he did a job related to that, before that. And I was not good at public relations and not good at talking. And so it’s more like I’m more as a technical person behind it. I think it worked out pretty well. And we had some other people that did a lot of documentation stuff and that was very good, because I am also bad at documentation.

Brian: It’s good to be self-aware and know where limitations lie. It sounds like that’s a great way to have other people step up in places where you know that you might not have the expertise in. And it sounds like Sean did that well for you as well as other folks. It’s funny, because webpack, it’s a project that I’ve leveraged a lot, but I’ve also interacted with folks who’ve contributed there.

Kathy: Open source and the community go hand in hand. It’s people coming together to make something stronger and, for contributors, it often can be the start of a long journey. In regards to webpack, contributors brought such a diverse skill set to the project, filling in gaps where others may not have been able to. It’s certainly one of the successes of webpack, the combination and abilities brought to the table. What does Tobias attribute the success of webpack to? It wasn’t the first module builder so what was the thing that got the community attached to this?

Tobias: I can’t say exactly, but I think the top three success factors were: code splitting, to have everything as a module, and a combined model graph of all resources. The third factor, I think, was the flexibility. So webpack is very extensible and it’s basically written with the intent that every user, every company has a special case and it will be able to customize webpack really heavily. I think, but I have no proof, but I think that the flexibility of webpack was one of the success factors. Especially as the JavaScript ecosystem was very in flux at this time. It’s not that much settled on what is the right approach about everything. I’m not sure if it settled now, but it’s at least more settled than five years ago. And so I think that the flexibility and the extensibility of webpack was also one success factor.

Brian: Yeah. Would you say that JavaScript is a mature language now at this point?

Tobias: I don’t think so. It’s more like, I think it’s still in development. I think it’s very, it’s not immature, it’s more like it’s continuing to evolve and it’s getting better over time. But I think JavaScript is a really difficult language to evolve and to develop, because it’s more like, you have to be backward compatible to everything in the web. And it’s not like other languages with to bring changes, like Python 3 or something like that, where you can change things which would break and can evolve the language really easily because you can do small backend changes. But in JavaScript, it’s more difficult to evolve. But I think we are doing a good job with, like, the recent ECMAScript versions. Yeah, I think it improved a lot and it’s moving to the right direction.

Kathy: A lot of the stuff that is happening on the web, and its ability to advance, is thanks to projects like webpack. And because of the funding, Tobias has been able to work on it full time for the past two years. Working on something you’re passionate about is very exciting and I imagine Tobias feels the same way. But, as we discover in this conversation, it can also have its limitations.

Tobias: It was great at this time, because at this time we also get my first daughter, and as I’m working on open source, I was working from home. So I really have a lot of time to spend with my family, and no more traveling to work. Yeah. It’s easier and more flexible, and can work from any time. It was a great experience. I think recently, a lot of people also experienced this with Corona, and home office stuff.

With open source, you can do what you are interested in. It’s not so much about, “I have to do this, but I don’t like it.” So it’s more like you can basically spend your time on what you think is important for the project. And also, what you think is fun. Yeah, you should probably fix some bugs if users report them, but otherwise you can have a lot of control, and being your own boss is great.

Brian: So speaking of which, you recently took a job, you took a role to, one, continue to work on webpack, but after saying all that, what was the catalyst of taking a role at Vercel, to work on webpack and the Next.js ecosystem?

Tobias: One factor was that in the open source community, I don’t have so much insight into users’ builds, and what users do with webpack. At Vercel, I have a lot of direct connections to customers, and can get code and can build the code. It’s more, a little bit from another perspective, to look at what users’ needs are. I also think Vercel is a great company, and that they’re doing a great job also with open source and Next.js. I also will be able to contribute to Next.js. So my job is webpack and Next.js, and doing everything together. Maybe it’s also a bit, I don’t think that webpack will be forever. It’s a lot of other tools coming around, and webpack is getting old. I don’t think it’s yet a bad tool, a legacy tool. It’s more like, I probably won’t be able to work indefinitely until I get old on webpack. So I also look into other alternatives and, yes, being at a company, I can evolve with this ecosystem and don’t be bound to a specific tool.

Brian: If you’re looking for user feedback, Next.js has lots of users, and Vercel definitely has a lot of users as well. It’s an interesting take too, as well, to be able to advance and continue working on interesting problems. Taking a job might make sense to answer a lot of those questions for you.

Tobias: Mm-hmm (affirmative), definitely. I already got quite a lot of insight, and worked with customers about why the tools, the builds, are slower, what’s the problem. I think it’s definitely a huge chance for webpack to getting more stability, and also evolve where the user need is. You get a lot of feedback from all kinds of customers in the open-source community, but it’s more from all customers.

At the company, you’re getting feedback, you know where the feedback is coming.. it’s coming from a huge enterprise customer or it’s from a small one-off contributor, or something like that. I think you can work directed into what... you get the feedback provided with how important it really is. In open source, all issues basically are the same. Yeah. It’s not that, is it a real problem or is it just one customer having this problem? Yeah, it’s a different perspective. It’s interesting. I think both are good, but now I have access to both.

Kathy: Tobias now has a full time job and while it involves working on webpack, he has to direct his energies elsewhere too. In the meantime, there are new build tools that are mirroring what webpack is doing. Much like webpack replaced Browserify, will there be something that replaces webpack?

Tobias: Webpack was created in a world where everything was in flux and unsure and unstabilized in the web ecosystem. And now everything comes together and is getting more stabilized and more... You’re getting the direction of the web. And so there’s a chance for new tools to really specialize on the new world. Less on flexibility and go more optimized on the stuff where the web is directing to or is stabilizing on. So, there’s definitely a good chance for other tools to overtake webpack and that direction. Yeah. webpack is really old and it’s huge and it has backward compatibility needs, and we have to still serve other old customers. So, it’s always with time that legacy tools get overtaken by newer tools.

So, I won’t say that it may not happen. It probably will happen. I don’t know, one, when and it’s probably also that webpack will stay alive for maybe five or ten years after that, because all the enterprise customers probably don’t upgrade, don’t get on the newest type of tool and continue to have old code bases or continue to work with webpack code base. I’m not sure about the future and I won’t deny that there will be a new tool eventually and overtake webpack, and maybe I contribute to the new tool then after that. I think the webpack team has a lot of chance to evolve, especially as it’s evolving so fast that there are good chances. And now there’s a time where these tools can be easily integrated into that, the ecosystems that can be WebAssembly and can be compiled and cross compiled. Everything is really integrated now so there are interesting abilities that these new tools can provide. Let’s see.

Brian: Your take on the evolution of the web and tools, it’s very much in play for a lot of stuff. What we were doing with webpack, we were doing also 15, 20 years ago prior. But we weren’t doing it the same way because the machines, the processors, they were all different. So like single threaded JavaScript was enough. Now we’ve got all this new hardware and technology that’s going to come out eventually that we’ll need to always want to iterate and improve on the situation of being able to take advantage of that stuff too as well.

So, I do hope that these new tools will have the same sort of user experience that webpack gave to me. Once I have learned it, now I just know it. So, I’d love for all these other tools to also have that same experience eventually. Otherwise, I don’t see a reason to leave webpack today, maybe next year. Touching back on the decision to take the full-time role at Vercel and help that ecosystem, what was the thought process and what went through your mind of taking the job, but also your loyalty to webpack, and also maintaining, your word, the baby that you created, which is webpack--what advice would you have to other maintainers who inevitably will probably get offered a job if the project reaches the success of webpack? What advice would you have for them to go through that same sort of thought process?

Tobias: When Vercel offered the job, they also promised me that I can continue working on webpack and Next.js. I definitely don’t want to leave webpack and just do something else. I wanted to continue to work on webpack and getting maybe new directions and maybe a little bit more. I’m also open to do a little bit... 50% mixture of stuff, company stuff or whatever. So yeah, it was a little bit like leaving webpack, but it was.. I also saw it as my chance to evolve and get new directions and get new ideas. So, the best idea is to work at a company which really uses your open source project or is really highly dependent on your open source project and you can continue working on your open source project as part of your company. That would probably be the best idea I can recommend.

Brian: Yeah, yeah. This is very much true in the JavaScript ecosystem. And you see a lot of success in the projects that have large backings versus the projects that maybe have a good idea that eventually tend to fizzle too, as well. So, definitely lots of thoughts and considerations for maintainers who are listening on the future about, or just thinking through the future of their projects. But Tobias, I really thank you very much for sitting down and chatting with us about webpack and your journey into it, but also the next journey that you’re sort of currently embarking.

Tobias: Yeah. Thanks for having me.

Brian: It was great to speak with Tobias Koppers and have him on the ReadMe Podcast. To learn more about Tobias and his project, webpack, please visit webpack.js.org.

I am Brian Douglas, and I am a developer advocate here at GitHub.

Kathy: And I am Kathy Korevek, I work in product at GitHub. The ReadME Podcast is a GitHub podcast that dives into the challenges our guests faced and how they overcame those hurdles. In sharing these stories, we hope to provide a spotlight on what you don’t always see in the lines of code, and what it took to build the technology that inspires us all.

Brian: It’s been really great spending time with you. The ReadME Podcast is part of the ReadME Project at GitHub, a space that amplifies the voices of the developer community: The maintainers, leaders, and the teams whose contributions move the world forward every day. Visit GitHub.com/readme to learn more.

Our theme music has been produced on GitHub by Dan Gorelick with Tidal Cycles. Additional music from Rhae Royal and Blue Dot Sessions.

The ReadME Podcast is produced by Sound Made Public for GitHub.

Please subscribe, share, and follow GitHub on Twitter for updates on this podcast and all-things GitHub. Thanks for listening!