On YouTube
195 JSJ Rollup.js with Rich Harris and Oskar Segersvärd
02:17 - Rich Harris Introduction

02:34 - Oskar Segersvärd Introduction

02:50 - rollup.js

04:47 - Caveats and Fundamental Differences Between CommonJS and AMD Modules and ES6 Modules

11:26 - Where rollup.js Fits in the Ecosystem

17:40 - Input Modules

18:35 - Why Focus on Bundling Tools vs HTTP/2

20:13 - Tree-shaking versus dead code elimination 

25:53 - ES6/ES2016 Support

27:36 - Other Important Optimizations

32:11 - Small modules: it’s not quite that simple

41:54 - jsnext:main – should we use it, and what for?

Picks

Better Off Ted (Joe)
Elementary (Joe)
Ruby Rogues Episode #137: Book Club - Functional Programming for the Object-Oriented Programmer with Brian Marick (Aimee)
Ruby Rogues Episode #115: Functional and Object Oriented Programming with Jessica Kerr (Aimee)
Ruby Rogues Episode #65: Functional vs Object Oriented Programming with Michael Feathers (Aimee)
Operation Code (Aimee)
Google Define Function (Dave)
Scott Hanselman: Dark Matter Developers: The Unseen 99% (Dave)
MyFitnessPal (Chuck)
Nike+ Running (Chuck)
Couch to 10k (Chuck)
Aftershokz Bluez 2 Headphones (Chuck)
Pebble Time Steel (Chuck)
Climbing (Rich)
The Codeless Code (Rich)
Star Wars (Rich)
The Website Obesity Crisis (Oskar)

Special Guests: Oskar Segersvärd and Rich Harris.

 
JOE:

You're not here, Dave.

Oh, you wish. [Laughter]

There is no Dave here. These are not the Daves you're looking for.

Hey everybody and welcome to episode 195 of the JavaScript Jabber Show. This week on our panel we have Dave Smith.

Hello.

Aimee Knight.

Hello.

Joe Eames.

Hey, everybody.

I'm Charles Max Wood from DevChat.tv. We have two special guests this week. We have Rich Harris.

Hello.

And Oskar Segersvärd.

Yeah. That's as close as you're going to get. [Laughter]

Congratulations.

[Inaudible] [slaughtered] it.

I know, right? You both want to introduce yourselves?

Okay, I'll go first. I'm Rich Harris. I'm an interactive journalist at TheGuardian.com which means I use JavaScript to help tell the news. And I help out with a couple of open source projects on the side, one of which I hope we're going to talk about.

Yes. And I'm Oskar. And I work at a smaller advertising company called Widespace. We're out in a few countries in Europe. So far, [inaudible] US. And I just love the project that I'm working on [inaudible]. So, happy to talk about it.

Alright. Nice. So, we brought you on to talk about Rollup.js which is a module, loader module bundler is what it says on here. Do you want to kind of give us an overview of what you mean by that?

Yeah. So, typically when you're writing a program, maybe you're writing a library or you're writing an application, it's a lot easier to build it out of lots of separate module. Otherwise you end up with thousands of lines of code in the same file. And you end up with problems with version control and just being able to understand what all of the code is doing. And so, typically what people do is they write their programs in lots of separate files instead. But because it's the web, because we don't want to have users downloading many script tags all in one go, it's best if we can bundle those files up into a single file. And so, that's what Rollup does. It takes a collection of JavaScript modules and turns them into a single bundle for an efficient delivery.

So, what's the difference between Rollup and say the Linux cat command? That was mostly…

Meow.

Essentially there isn't actually all that much difference. It is more or less concatenating files. The difference is that the order in which those files are concatenated is determined by the dependency graph that you describe with import and export statements inside your JavaScript module. So, rather than concatenating them say, alphabetically you're concatenating them in the order that they need to load in order for the program to run.

And does Rollup.js actually parse my code looking for import statements, ES 6 import statements?

Yes.

It does.

It parses your code and analyzes what it's actually doing in an attempt to not only [inaudible] put the code that it requires in the correct order but also remove anything that it can safely determine that you don't need.

Ah, very nice. So, if I have a gigantic framework and I only use some pieces of it, it will prune out the parts I don't use?

Correct.

If it's structured correctly, or in a way that Rollup understands.

Sounds like there are some caveats there. Can you go into that?

Well, JavaScript is a very dynamic language. And because of that static analysis, which is this process of finding out things about a program without actually running it, it is really difficult. And so, there are times when it's just not possible to determine that it's safe to remove a particular piece of code. And so, Rollup will often have to err on the side of caution and include code that actually doesn't end up getting run. But because of the way that ES 6 modules are structured, we can do a lot better than has been possible to do ever before, because JavaScript modules export many items instead of a single object containing lots of items. We can safely remove a lot more code than say UglifyJS would be able to give them the output of a CommonJS module bundler.

Everyone keeps talking about how ES 6 modules are more efficient than the other module loading systems. Is what you just said the only thing there is or is there more to it? Like CommonJS like you just said, or like we used to use require.

It's kind of hard to explain this without codes samples. And I'm suddenly realizing that a podcast  is a terrible medium in which to show code samples.

Yeah, that's why we just make jokes most of the time.

[Laughs] Essentially, the fundamental difference between CommonJS modules and AMD modules on the one hand, and ES 6 modules on the other, is that with CommonJS and AMD you can only really export one thing. So, you take a library like Lo-dash for example. Lodash is an object with lots and lots of properties on it. Yeah, lodash.each, lodash.pluck, and so on. And if you import that into your library, then you have to basically import the entire object. Now with ES 6 modules, which can explore many things instead of a single object, you can be selective about which parts you import. Now, Lodash is actually a bad example because Lodash makes itself available as micromodules. You don't pay that penalty with Lodash. But you do pay that penalty with a lot of other libraries. And ES 6 kind of brings us into an era where that's no longer the case.

So, is that it? Is that the only reason that it's more efficient to go with ES 2015 modules instead of

CommonJS or AMD?

It's the reason for using import and export statements specifically. But the fact that we're using them allows us, [inaudible]. So, the semantics are a bit different as well. Since you don't export a plain value. But you export an actual binding to a specific variable. So, you don't get the current value of some variable. You get the binding to the actual variable if it's being updated by some other piece of code. So, [inaudible] more efficient.

There's also, we've got [inaudible] circular references in ES 6 modules. They're designed around that whereas traditionally that's been quite hard to reconcile circular dependencies in CommonJS and AMD. It's been possible but there have been some syntactical dances that you've had to do in order to get that. I would say that the most important and significant difference between ES 6 modules and what we've had before is that they're designed around this idea of static analysis. With CommonJS the only way to truly determine what dependencies a CommonJS module has is to run it. And with ES 6 that's not true because we have these guarantees about syntax. You can look at an ES 6 module and guarantee with no caveat that it has these imports and it has those exports. And that enables a whole range of things which were quite difficult before.

And why is that the case? Is it just because of the way that CommonJS works where you have a module.export equals that could contain anything at runtime? Whereas ES 6, ES 2015 you have the export keyword?

It's because the design is… ES 6 modules have the luxury of making changes to the language.

AMD and CommonJS have to work within the constraints of what was possible in existing environments. And import and export, they're these new language features and we get to say, “This is how they should work,” whereas with CommonJS because you import other modules by calling a function the modules have to be structured in such a way that that will work. But that gives you flexibility to do certain things that defeat [inaudible] static analysis, like renaming your export object for example.

Mm, okay.

So, does this matter a lot more for the toolmakers to make neat tools like static analysis and things like that versus the consumers? Like, one of the things that I was thinking of is, you know in CommonJS you can only export one thing but people get around that by exporting an object which has properties. Now in ES 6 you can export multiple things but when you bring them in, you really use the exact same syntax as object destructuring in order to grab variables to each of those, pointers to each of those same things.

Yeah.

So, with CommonJS if you'd still just use ES 6 object destructuring like on the imports I would look darn close to the same syntax, right? So, from a user standpoint is there a huge difference between using CommonJS, ES 6, or are there other advantages? Like I know that the circular dependencies thing is one but I've also seen that you can still get into trouble with circular dependencies in ES 6 if you do the wrong things.

Yeah, that's true. The syntax is pretty similar. And I think that's by design. I think the designers of the syntax wanted it to be familiar to people who were already using CommonJS modules and AMD modules. And the spec was very largely informed by the real world experience that people had had. So, that's true. It's not going to be a complete sea-change in how we interact with module systems. And the benefits are largely for toolmakers like Oskar and myself. Having said that, I think the long-term benefits are huge. Dependency management in JavaScript has got to be the single biggest pain point for any JavaScript developer be they novice or expert. And we're moving to a world where a lot of the sticking points around using different build scripts and having one thing for the browser and one thing for Node.js, all of that is just going to melt away and we're just going to be able to get back to just writing code and not having to worry about all of this really, frankly quite boring stuff about dependency resolution and so on and so forth

Right. Well, I'm interesting in talking specifically about Rollup.js and where it fits in the ecosystem of options.

Yeah, why don't we shake this conversation tree a little bit and see what falls out? [Laughter]

Nice imagery there, Dave.

Is there anything you'd like to talk about that might apply to that metaphor?

You're talking about where it would fit in the ecosystem and when you would use it. Is that what you're saying?

Yes, yes. That was, that's definitely the crux of my… like I'd like to hear where it fits versus other tools that are out there, when you might use this one versus a different tool, who's the target audience, when people shouldn't choose it, or when it would still be possible but maybe not the best fit.

Well Joe, we don't have a module loader in JavaScript right now. So, we need this one

[Chuckles] But there are others. There are options out there. [Chuckles]

That's what I'm saying. When I first looked at it I was like, “We have a million module loaders out there for JavaScript. Do we really need one more?”

Right. [Chuckles] Yeah, that's actually a great question [inaudible].

Well I'd say that Rollup, at least in my view is more of a bundler than a loader. You don't dynamically load things using it. But you try to generate something that is…

Okay, hold on. Can I interrupt you and have you give us a really good explanation of the difference between a bundler and a loader? Because I think that's a great thing that tons of people are not clear on.

Sure. So, my view of a loader is something running on the, [inaudible] talking about the browser. Something that's running on the browser and is fetching the script files from some server as they are needed. It is loading these files from somewhere and executing them and hooking them together. While a bundler would add some kind of build time, grab a lot of modules, put them together into one file that's much more efficient to send to a client than many individual files. So…

Hey, quick question in there. Could that also be more than one file?

It could concatenate into more than one file. Right now, Rollup doesn't support automatically figuring out different building blocks or different files that it… it doesn't figure out that you could split the files up into more than one chunk so to speak. While the [inaudible] tools that do…

We do have an open GitHub issue for it.

What?

Yes, I know. I'm already eager to [inaudible].

Maybe in the second half of 2016 we'll be able to get onto that.

I'm hoping to. But yeah, so the main difference is that it chunks the files together to deliver something that's more efficient than just fetching several small files.

So, can you give us some examples of other tools that do the loading and other tools that do the bundling?

I would say that RequireJS for instance has… RequireJS is both a loader and a bundler. So, you can run RequireJS in the browser and when you're developing it can fetch your files individually which is quite convenient. And then when you're going to use the files in production, you can put them together and deliver them once. So, two other tools that bundle files are Browserify and Webpack that you probably also heard of. So, they I guess would be more similar to Rollup than say System Loader Polyfill or RequireJS.

Yeah. Certainly Browserify is doing a fairly similar task. Although Browserify is CommonJS-centric whereas Rollup is ES-6-centric. But they're basically doing the same thing.

How about SystemJS? Where does that fit in this?

SystemJS is an interesting one. And it's part of this larger project called jspm which is a really incredible and ambitious project that sort of vertically integrates everything from the repository to the package manager, the command line tool, the bundling stem, as well as polyfilling the module loader in the browser. It is all of these things and it's designed around having this single vertical integration. Rollup just is a very tiny subset of what jspm is doing. And actually, we're working with Guy Bedford on the jspm team. I say jspm team. He basically is the jspm team.

We're working with the guy at the moment to integrate Rollup into jspm so that jspm users can get the really nice, efficient Rollup bundles but with all of the functionality and the convenience that jspm provides.

So, I think that's… so, that finishes up our explanation of bundlers versus loaders, right?

Yeah.

Did a good enough job with that, do you guys think? Dave, Aimee, Chuck?

Yeah, I think I'm good.

Okay. So then, you were explaining Rollup back in the whole, where does it fit, why is it better? I don't know. Did you finish that up or is there more to say about that?

Well, I think you're the guy for that, Rich.

Well, better is quite a loaded word to use, I think. Webpack for example is this remarkably sophisticated tool which is ideal if you're building a complex application because it's got things like code splitting and hot module replacement. It's got this entire universe of different loaders and people have built some incredible things off the back of Webpack. Rollup generates smaller bundles than Webpack. You know, given the same input code it will give you less output code. But it doesn't have a whole [suite] of features that Webpack does, at least not currently.

And so, you could say that Rollup is better for generating a bundle if you have a collection of ES 6 modules. But if you want all of the extra functionality that Webpack provides such as a development server and all of that, then Webpack is absolutely better. So, there's room I think for all of the tools to coexist. [Inaudible] and they all have slightly different angles and slightly different strengths and weaknesses. And I definitely wouldn't say that Rollup is better than any of those other tools.

I don't know if this was mentioned earlier but I think it's an important point that you said there that Rollup only works on ES 6 modules as input. So, you have to write all of your code as ES 6

modules, right?

That's the recommended approach, at least.

Oh, can it take other modules as input?

Well, there is one plugin to Rollup for CommonJS modules. But that is a bit of a hack. But that allows you to bundle CommonJS dependencies at least. We would never recommend you use Rollup to bundle CommonJS module exclusively. We don't want to force you to rewrite some dependency as an ECMAScript module just to be able to bundle it. So, it's like sort of a…

Ah yeah, makes sense.

Yeah, transition.

Can I back up and just ask kind of a general question? I just put this in the chat, but there's so much focus on all of these different bundling tools. Why the focus on them if with HTTP 2 it's actually better I read to serve smaller files so that the browsers can cache them?

Aimee, you're stealing my question.

That's a really good question.

It's a question that we get quite a lot. And the answer is that hopefully one day, HTTP 2 is going to be everywhere. And build tools like Rollup will become really unimportant. And that'll be great because I'll be able to spend more time outdoors instead of… [Laughter]

Instead of writing a module bundler. But we're not there yet. HTTP 2 is a long way off in terms of everyone supporting it and everyone service over HTTP 2. Yeah, I think we're going to have to be bundling our JavaScript for efficiency for quite some time. [Chuckles] Even with HTTP 2, it is still more efficient to bundle your code from the point of view of being able to compress it, because when you compress JavaScript code you get more value out a single hundred kilobyte file than you get out of compressing 10 kilobyte files for example. And I think it was Khan Academy that recently did some fairly in-depth investigation to this issue. And they concluded that even with HTTP 2 [inaudible] JavaScript.

And the other thing of course is that if you [inaudible] then you can take advantage of things like tree-shaking, which isn't possible in the same way if you're serving all of your files.

Can we also define the difference between tree-shaking and dead code elimination? I know you talked about that in some of the stuff that you sent over for us.

Yeah. Tree-shaking is a really [inaudible] for what's happening. And I kind of regret helping to popularize it in the JavaScript community. I thought it was one of those phrases that I was borrowing that [inaudible]. So, when you minify code with a tool like UglifyJS or something, one of the steps involved in that is this process called dead code elimination where you go through the code and you remove all of the bits of code that can't be reached for whatever reason. Maybe they're inside an if false block or maybe there's some code that comes after a return statement or something like that. And because we can guarantee through static analysis that that code is never going to run, we can remove it. But what you can't remove is code which looks like it probably doesn't run but you can't guarantee it because of JavaScript's dynamic nature. And that's kind of a result of the dead code elimination approach of starting with the finished product and then working backwards to identify what isn't being run.

The tree-shaking approach by contrast sort of asks the question, given that this is what I want to happen which bits of code do I need to include? So, rather than starting with the whole bundle and removing bits, you start with nothing and you gradually import bits of code until you can run the program correctly. I realize that's probably a terrible, terrible explanation. Does it make any sense?

It makes sense to me. Essentially what you're saying is that I know I'm going to… you have an example on the Rollup.js website where it shows cube and square which is the mathematical cube and the mathematical square. And when you import cube, effectively what you get is just the function cube even though square looks like it's something that could be run or called somewhere else. But because you know that you're not actually using square anywhere, you don't pull it in. However if you change the return value to square of x times x for cube, then it does that same static analysis and figures out that cube relies on square. And so, it pulls it into the file. So in other words, instead of trying to do some kind of static analysis that looks at it and says, “Well, there's no way that this is going to run because it has an if undefined or if false,” it actually looks at it and says, “This is what I'm actually going to run. In other words, I'm going to run cube then I know I need square,” or I don't need square, depending on how you have your return value set up because it does or doesn't call it, period.

That's exactly it. That's much more eloquent than my version. Essentially they're trying to do the same thing, dead code elimination and tree-shaking, if you want to even think of them as separate processes. And if dead code elimination was perfect, then you would end up with the same result whether you're going backwards as it were or forwards with tree-shaking. But in practice because of JavaScript's dynamic nature, dead code elimination isn't perfect. And so, tree-shaking tends to give you a little bit of an advantage.

So, in your experience on applications would you say that tree-shaking gives a certain percentage of extra dead code elimination that the standard procedure doesn't? Or did I completely misunderstand it?

It varies very wildly.

Sorry. And did I understand that correctly, that tree-shaking is really just another optimization to eliminate a little bit more code than what you could do through traditional means?

They're complementary, aren't they [inaudible]?

This one says I know that I'm going to need this, or at least I'm going to need this function. Dead code elimination might be able to determine that I'm not going to need this statement within the function, for instance.

Ah, so instead of operating just at the name, the module name level, it goes deeper into the syntax tree. Is that what you're saying?

Well, maybe not deeper. But it can work… maybe it works on smaller things that it is able to know that will never run. It's like a complementary…

Ah.

It's a complementary thing. So, you could kind of… I mean, one is like live code inclusion and the other is dead code elimination. It's when we can be sure that we're going to need something we include it or where we're sure we're not going to need it, we can delete it.

And does that include statements within functions? Or is it just at the function level?

It could. I've been working with… I used to work a bit with Google's Closure Compiler. And that has quite a vast dead code elimination built in. So, it can actually detect that a statement, some statement within a function does not have side effects. And if its return value is not used, the function call can be eliminated.

Ah, interesting.

And Rollup has those kinds of abilities on top-level statements at this time. So, it can detect that some expression, some statement does not have any side effect and that it can be removed. But it does not as of this time work inside of these top-level functions and statements.

One of the things that we're very keen to do this year is make that static analysis a little bit more sophisticated so that we can reach further inside and so that we can get a more complete picture of what code is likely… not likely, but what code we can guarantee that we can remove. Because at the moment, as I say, there are lots of times when we have to err on the side of caution and we have to include code even though it's probably not going to run, like methods on classes that are unused for example. At the moment we just have to include them all. We don't have a choice.

So, I'm assuming you have to actually run this in ES 6 or ES 2015, whatever you want to call it.

Oh, we talked about that earlier. I believe they have some, an adaptation for CommonJS inputs as well.

Yeah. But actually, the only real requirement for Rollup is that you write the code in ES 6 modules and you use import and export syntax. We don't require any… you don't have to use classes. You don't have to use arrow functions if you don't want to.

Okay.

But it supports all of ES 6, ES 2015. That's the main goal.

And in fact, that's quite an important point. I think a lot of people have been put off using tools like Rollup because they assume that they have to buy into the whole of ES 6 and they have to transpile their code. And that's not true. Import and export can be used alongside regular ES 5. And in fact libraries like D3 and PouchDB are going in exactly that direction. They're using import and export syntax to declare their dependency graph but they're not using any of the ES 6 features. So, there's no transpilation requirement.

Oh, and in the final output those import and export statements are gone anyway, right?

Yes.

Yeah. I mean they kind of cancel each other out, almost. That's not really a good description of what's happening. But it kind of helps you understand the process. If you've got import foo from foo.js and then in foo.js you've got export default whatever, then that import statement and that export statement, they sort of cancel each other out. So, Rollup is kind of the only ES 6 to ES 5 tool where you end up with less code than you originally wrote as far as I'm aware.

Yeah.

That's funny.

I'm just wondering. Besides tree-shaking are there other optimizations that are built into Rollup that you don't get from some of these other module bundlers?

Well there are a few. For instance, in Rollup you can export an entire namespace from some other, from another module. So, let's say you have some foo module, which exports foo bar and baz, and then you can export the entirety of that module onwards under some other name like mod. And we can statically determine that the function that you're looking up through this indirection, in this namespace, it can verify that the functions you're using actually exist. And we can do, we can eliminate functions that are unused several layers down. While if some other module format was to export several layers of modules, we just lose them. It would not be able to know whether some function is used or not.

The other big difference between how Rollup bundles things and a CommonJS bundler like Browserify is that with CommonJS modules, to make them work you have to wrap each module in a function and accompany it with some metadata. And then at the top of the bundle you have to have a module loader which implements the require function so that you can kind of simulate a Node-like environment in the browser.

With ES 6 modules that's not necessary. You can just put all of the code in the same scope. And as long as you rename identifiers to avoid any naming conflicts, say foo.js has a var x and bar.js has a var x, you're going to need to rename one of them. As long as you do that, you can put everything in the same scope safely and do away with those, with the per module cost of wrapping each module in a function and all of that extra metadata. And the per bundle cost of including the module loader. And you don't need to keep re-declaring your imports because everything's just sitting there in the same scope. So, even without any tree-shaking magic or any of that, ES 6 modules are basically guaranteed to be more efficient than CommonJS.

In the scenario you just described, are you saying you would take all of your modules and the names that they export would all share the same scope?

Yes. We just rename things to guarantee that there aren't any clashes. But everything sits in the same top-level function scope.

Oh, okay. But there is a renaming happening so that you won't have… the developer doesn't have to worry about name collisions.

Exactly. In fact, if you go to RollupJS.org you can see some examples of this. You can try having variables with the same names in different modules and then importing them. And you'll see it dynamically renaming things to avoid collisions. It is something the developer never has to worry about. And that's one of the nice things about modular development, is that each module is its own sort of self-contained universe. And you can go nuts in there. You can declare a thousand variables and you can guarantee that it's never going to conflict with anything else elsewhere in your application.

So, I'm still… I'm trying to get my head around this. But it seems like what you're saying is that Rollup can provide you a loader than you can use because obviously it supports various output formats including AMD, CommonJS, and so on. Is the mode you're talking about here globals mode?

This is what happens whatever the output format you're producing. The output format is really just kind of an intro and an outro to the bundle. In the case of the CommonJS output bundle your intro will be var dollar equals require jQuery or whatever. In globals mode it'll just be an immediately invoked function expression. The stuff that's going on in the middle in terms of renaming variables to avoid conflicts, that's the same whatever the output format.

So yes, we have five different output formats that you can generate. We generate AMD bundles for people who are using things like RequireJS. We generate CommonJS bundles for people who want to then go on and use it in a Browserify context or a Webpack context or they want to run it in Node. We have what's called Universal Module Definition which works anywhere. It works as an AMD module. It works as a CommonJS module. Or it works as a self-executing function expression. Or we can have that and that self-executing if/e or even an ES 6 bundle. It can take 10 ES 6 modules and turn them into one ES 6 module for example. Although right now, that's not very useful because as we've discussed [inaudible] has to load that at the moment.

So, I was going to bring up one other thing. You also sent us over a Medium post that you did on why you're not completely in favor of small modules. Do you want to talk about that?

Yeah, this is… I'm going to get in trouble now because… [Chuckles]

Because a lot of people disagree with me quite strongly on this topic. There's been a real shift in mindset since Node.js came to being. And as the JavaScript industry has kind of got more professional, which says that any time you write a library it should be authored as a small, selfcontained module. Which on the face of it sounds like the most logical thing in the world. It's easier to write. It's easier to test. People who are using those modules don't have to include all sorts of code they're not going to use. But the effects of that mindset I think are actually quite damaging to people who are relatively new to programming.

And my hope is that now that we have ES 6 modules and we have the ability to do things like treeshaking that hopefully the pendulum is going to start swinging back towards larger libraries like jQuery and D3 and Lodash and Three.js and RxJS and all of these things. Which I say the pendulum should swing back. Actually people are already using these in vast numbers. But the sort of thought leadership in the JavaScript community takes [inaudible] some of these things and says that they're not modular enough. And we need to be more modular and we need to write everything as small, self-contained modules.

And the post that I referred to was trying to articulate some of the concerns that I have about making things difficult for new developers. Because we've lost the ability to say, “Oh, just drop jQuery into the page and you kind of got everything that you need to build an application.” When I was starting out and I had a question about, “Oh, I want to load a file from somewhere and I have no idea how to do that,” and someone said, “Oh, you use jQuery Ajax.” And nowadays the response would be, “Well there's like 780 packages on npm that can do what you need. Just pick one.” And I would have been completely lost.

Sorry, that was a very long and rambling answer.

That's a fair point.

Oh, that's actually a great answer and a great point. And a huge deal is… kind of you know, that we're seeing some discussion lately about tool fatigue. And that's definitely related to this point as well. Making things easier on newer developers does matter.

Yeah, and it was [instructed] that the response to that post was very positive. I had people thanking me privately for articulating these things. But on Twitter and other places where thought leaders congregate, I was excoriated for diverging from the current orthodoxy. And I think that's instructed because the people who write blog posts about this stuff and the people who argue in favor of small modules and the people who get invited to podcasts like JavaScript Jabber, they're not at all representative of the vast majority of developers. And they don't represent the vast majority of developer opinion. And so, I think we tend to get trapped in a thought bubble that represents those approaches which most benefit the lead developers and library authors as opposed to the vast majority of people who just want to do some programming. They just got a task to do and they need to do it in the simplest way possible.

I think it's really easy to get your emotions wrapped up and let those drive you rather than kind of just making the best decision you can for the tool you need at that time. So, you don't always need something small but other times you do. That's my [inaudible].

Oh, yeah. But also, we should remember that one of the best things for new developers is to have to learn a new MVC framework this month.

[Laughs] Yes, totally. [Laughter]

That totally helps you learn everything you need to know about JavaScript.

And that just shows that Joe's stuck in the past. It's this week. [Laughter]

Oh, that's right. It is this week.

So, when people complain to you, did you get the impression that they were like, “Look, if you make this easy to hack together and cobble together these monolithic, large applications then I'm going to have to come in and clean up that mess later”? Like what was the crux of their argument?

I think the crux of the argument was that it's easier to produce higher quality small modules. And that it's easier for people to get started as creators rather than consumers because of what npm's made possible. And that's absolutely true. It's very easy now to produce a package on npm and have people start using that, so much so that actually the hardest part of creating a package on npm is finding the name that hasn't been used already. But I think that…

[Laughs] Maybe somebody should write a service for that. [Laughter]

NounJS.com.

They probably have, but good luck finding it because you can't find anything on npm. [Laughter]

I think what overlooked is that if I were to create a new package as a fairly new developer, the likelihood of anyone actually using it and giving me actionable feedback is very, very small. It's just going to get lost in the wilderness. Whereas if I wanted to help out with a project like jQuery or Lodash, there would be a team of contributors waiting to help me with my pull request. There'd be a whole bunch of people on Stack Overflow helping with all sorts of different questions that I might have. And so, actually I think it's a much better onboarding experience if we can all collaborate on tools that are large enough to have a community.

And it is hard enough to get started helping out with those to begin with anyway. Even with all of the help that is available. It's still a huge pain. In fact, one of the talks that I'm really looking… I thought was really cool that somebody did was Kent Dodds is going to be talking. I can't remember what conference he's talking at. But he's talking about how to make your first contribution to open source. 'Your First Pull Request' I think is the title of the talk.

Right.

You know, it's already hard enough to get through GitHub and pull requests and do them right and sign their disclosures so that you can contribute and all those sort of stuff, all these other hoops to contribute, with the help of people that will actually respond to your pull request within the month.

Yeah. Well, and back to the point of do you need a small, specialized tool or a big tool that will do the job? I mean yeah, sometimes I'm fixing a light socket in my house and I need a screwdriver and a voltmeter. And sometimes you're actually building the house and you need to ask an excavator to dig out the foundation. And so, I mean we have appropriate uses of both. And there are a lot of developers out there that are still writing jQuery and not using even the most basic of frameworks like Backbone or any kind of module loader or bundler or anything like that. And they're getting the job done. And so, while I understand the arguments both ways, I think it really depends a lot on what you're trying to get done and what your constraints are, and what's been done before you got there.

It does. And I'm actually not advocating for not using or using large frameworks or small libraries or anything like that. My point is more that it should be okay to build libraries like jQuery.

Mmhmm, yeah.

I think that nowadays if John Resig were to start building jQuery he would get modularity shame. People would say, “Why are you putting all of these things in the same library? This is crazy. These should all be separate concerns.”

Mm, okay.

And because of that, I don't think we're going to have another jQuery. But if you take an example like Three.js, this I a library that people think of as kind of a monolith. But actually, it's composed of loads of really small modules. And if you can write it in such a way that people can use it as a framework or they can just pluck out the small modules that they need from it, then we can have the best of both worlds. We can have these very rich easy to use, easy to get started big libraries without having any of the kind of fat shaming that goes with not using your own handled, artisanal, totally modular Franken-stack, which is…

The current trend.

Excellent name.

Yeah.

You know, that's really interesting. I think that actually would go a long way to solve a lot of the tool fatigue problems that we're having where it's, “Look, if you want to pluck out your little modules and use them, you can. And if not, here's an amazing kitchen sink that we've put together for you that includes everything we think you'll need and you can just get rolling.”

That's the hope. But you know, Rollup is just eventually I hope one way to do this. Webpack too is going to have tree-shaking support. I hope that other tooling is going to come along and [inaudible] similar ideas. It's all based on standards. So, the hope is that this is just going to be how things are done in the future.

I so want to create a framework now that's called KitchenSink.frankenstack.

Please do.

Awesome.

I'll use it.

You just got your first user, Chuck.

That's right.

Sounds like the name of a great indie band.

[Laughs] I know, right?

Well, I really like that. And I think your vision is super awesome and I'm glad you guys are willing to put your money where your mouth is and put some code out there and build this project and say, “Hey, you know the standard allows us to do better static analysis. Let's use it and let's show the world that we can have our cake and eat it, too.” You can have your big, fat modules and all the shame that comes along with them as well as shake out the dead fluff and only use the stuff you need. I think that's really cool.

Cool.

So, are there any aspects of Rollup.js that we haven't talked about yet that we really ought to? Or about the large library versus small library discussion that we need to have?

I guess we should talk about jsnext main which is a topic that fills me with dread but it is quite important.

Are you talking like ES 2016, 17, 18? Or something else?

No. So, we have this problem, right? ES 6 modules are fundamentally incompatible with existing methods of delivering modules like CommonJS and AMD or whatever. Because they rely on these new keywords, import and export. And if you have that in an ES 5 environment, it's just a syntax error. That code just isn't going to run. And so, we don't have a way to distribute ES 6 modules. And so, if we hypothetically build a library that is perfectly tree-shakable and kitchen sink frankenstack.js or whatever, I'm not going to be able to use it because it's not available to me as an ES 6 module. And the reason for that is that you'd still need to distribute kitchen sink frankenstack.js as CommonJS, as AMD, as UMD or whatever. Otherwise no one else is going to be able to use it

JS next main is one proposal for how we start to distribute ES 6 modules. And gradually transition the ecosystem away from these legacy formats and towards the standard that's going to be supported in these environments, without losing support for existing environments today. And it's a little bit technical and boring, but it's probably the most important thing that we could be doing to help shift the ecosystem towards ES 6 modules at the moment.

Well, a lot of ES 6 features are being implemented by JavaScript engines right now. One of the, or like the only thing that has been lagging behind has been the import and export modules. And from what I understand, that's because some of the specifications around what files are actually supposed to be loaded, that still has not been completely determined. So, everyone's waiting with this one thing that Rich and I hold so very dear. It's really a shame.

Oh, it's really a shame.

So yeah, [inaudible].

I guess we should try and explain what jsnext main actually is now that we've…

Yeah.

Yeah, I was going to ask. I was like, okay so you kind of painted a sad picture. How do we solve it?

So, if you produce a library and you put it on npm you'll have a package.json file. And in that package.json file, it's very likely that you'll have a field called main. And that field will point to the entry point of your package. So, if I do import kitchen sink frankenstack.js then the resolver is going to go and look for a directory with that name inside my node modules folder. When it finds it, it will load that package.json. It'll look for that main field and it'll then know where to find the file that I'm trying to require. Jsnext main is a field that sits alongside main. But rather than pointing to a CommonJS version of the library or a UMD version of the library, it points to an ES 6 export version of the library. And so in that way, we're able to get all of the benefits of tree-shaking and all of the rest of it without only having an unusable ES 6 build.

So effectively, then you have two versions of your library and one is CommonJS and what have you and the other one is ES 6?

Exactly. And [chuckles] a lot of people quite rightly [inaudible] that idea. They think that that's crazy, that you should just have one set of code and it should sit in your lib folder or whatever. And that the idea of having a build process which has to create two versions is crazy and overkill because we already have tools like Browserify and Webpack which can deal with the CommonJS source code. And so, because of that people are a little bit resistant to start distributing their code as ES 6 modules.

Yeah, but eventually aren't we going to have to go there?

We are, but there's always going to be this crossover where we're going to have to support things like… you know, Node 4 for example uses this LTS version which doesn't support import and export. So, we're going to have to support that for a long time. We're going to have to support existing build workflows and all the rest of it. So, we're always going to have to distribute a non-ES 6 version even when ES 6 is natively supported in Node and in browsers. And what we're trying to do is help people cross over. Because otherwise we're never going to be able to transition. We're always going to be stuck in the past with these legacy formats. And that would be a tragedy because as we've said, dependency management is the most painful part of development.

There has been some confusion about the main as well, since it's called jsnext main and not ES 2015 main or ES modules main. So, it's not been completely obvious to people what it actually means. And since there is no standard for it, it's up to implementers or it's up to us to decide how to use it. And I know that Rich has promoted the idea that it should be ECMAScript modules. That is the key idea. So, it's the ECMAScript modules that define how it works.

I should emphasize that we didn't come up with the name. [Chuckles]

No, yeah, yeah.

It's been around for, I don't know where the name came from. But it's been around since I joined the project, at least. [Inaudible]

[Inaudible] comes down to whether you should be… whether jsnext main means that you should just point to your ES 2015 source code with your classes and your block scoping, template strings and so on. And then the consumer of the library should be responsible for turning it into code that can actually run in current environments. Personally I think that's a terrible idea. But a lot of people think it's a great idea. And we haven't really been able to find much common ground.

And yes, as Rich said, and at the same time the name jsnext is also quite confusing. Let's say that I had a browser that supported all of ES 2015. But then someone starts using decorators or some ES 2016 language features in this jsnext main. All of a sudden that code that used to work suddenly won't, at least not for me without some additional transpilation. So, in that way the jsnext main is kind of unfortunate.

Yeah, I can see the confusion there.

But it is the best that we have. I don't think anyone has come up with a serious proposal for how we transition the ecosystem towards ES 6 modules while continuing to serve current environments that realistically solves the problem without creating a huge burden for people consuming these libraries.

Well, we've got to figure it out soon-ish because… I mean, they're going to release a new version every year. So, well this has been really fascinating. I don't… I have to end it but I kind of… I think we've kind of gotten to that point in time. Is there anything else that's really critical for people to understand in order to understand what Rollup.js and the project at large is trying to accomplish?

Not really, I think it's sort of fairly self-explanatory once you've seen it in action. If people go to the website, RollupJS.org, there's an interactive playground where you can try out different snippets of code and you can get a feel of how it's working. We do have a road map for new features that we hope to implement this year, like incremental rebuilds, similar to Browserify's watchify. Possibly code-splitting. Possibly some other things. But at its heart it's a pretty simple idea. It takes several files and it turns them into one file.

Alright. Well, let's go ahead and get to the picks, then.

Before we get to picks, I want to take some time to thank our silver sponsors.

js}. Let's face it: errors cost you money. You lose customers or resources and time to them. Wouldn't it be nice if someone told you when and how they happen so you could fix them before they cost you big-time? You may have this on your backend application code, but what about your frontend JavaScript? It's time to check out {Track:js}. It tracks errors and usage and helps you find bugs before your customers even report them. Go check them out at TrackJS.com/JSJabber.]

Joe, do you want to start us off with picks?

Oh, sure. I would absolutely love to regale you with my picks. Are you prepared to be regaled?

Regale us.

I'm on the edge of my regaling seat.

[Laughs] You're going to pay for your whole regaling seat but you're only going to need the edge of it.

Oh.

I set my regale flag to true. [Chuckles]

I'm going to run this up the regale flag and see if anybody salutes.

I returned a new universe with one mutation. Regale flag equals true.

That's right.

[Laughs] Alright. So, my first pick is going to be a TV show which is an old cancelled show with only one season but it's so worth watching. And I know I've picked this before but I was just watching it recently the other day and laughing my head off. And the show is Better Off Ted. That's T-E-D, not the movie dead. Just as good as the movie, although entirely different because it's like an office-based show. And it's so dang funny and there is this one particular episode about Utah that just makes me laugh over and over and over again. So, that's going to be my pick. My first pick is Better Off Ted.

And then while I'm at it, I'll pick another TV show because I've been watching a ton of it lately. And that is the TV show Elementary, about Sherlock Holmes, but it's kind of a modern day. Not to be confused with Sherlock which has Benedict Cumberbatch in it done by the BBC which is also great. So, I'll pick that one, too. Both Sherlock shows. In fact, any Sherlock shows that are out, I'll pick those. And while I'm at it, the Sherlock show that just came out that's in the movie theater because I'm going to go see it tonight. And so, I'm preemptively picking it because I'm sure it's going to be awesome. Because every other episode they've done of that Sherlock is great. Not to be confused with Elementary, which is about Sherlock which is also great, which you should also watch.

And those are my picks.

When you said regale, did you mean confuse? [Laughter]

Regaled with nonsense. Alright Aimee, what are your picks?

Okay. So, I have been on like a functional programming mission consuming everything I can, kid in

a candy store kind of thing. So, I used to listen to Ruby Rogues a bunch because I started off doing Ruby and Rails.

Wait, what do you mean 'used to'?

I'm offended.

[Laughs] I listen. Actually, it's still in… I still am subscribed to it. I just don't listen to every episode anymore. You know, only so much time in the day. But I went searching for as many programming podcasts, whatever I could consume. And so, I found three that I think are relevant even if you're a JavaScript developer. So, first one was episode 137, Functional Programming for the ObjectOriented Programmer with Brian. I think it's Marick. I'm not sure if I'm saying that correctly. Next one was 115, Functional and Object-Oriented Programming with Jessica Kerr. And last one was episode 65, Functional versus Object-Oriented Programming with Michael Feathers. So, check those out.

Alright.

I thought you like, found a whole set of podcasts…

Not three episodes.

I subscribe to so many podcasts, it's not even funny. [Chuckles]

Did you find any interesting podcasts that are just about functional programming?

I did not. I'm sure there…

Consider this your invitation. [Chuckles]

Someone is going to start one now, though. [Inaudible]

Functional Geekery.

Just let me know when you do, because I'll subscribe.

There's a show called Functional Geekery. It's by Steven…

Oh, okay.

He listens to Ruby Rogues. I think he listens to this show, too. So, I'm going to feel a little bit funny not remembering his last name.

[Chuckles] I'm sure his last name is either Haskell or Curry. [Laughter]

Yes, yes.

Yeah, and I'm pretty sure there are also some Clojure or I know that there's an Elixir podcast or an Erlang podcast. Mostly Erlang. You can go check out. They talk a bit about functional programming. So yeah, a few there. Steven Proctor. Now I don't feel so bad.

Anyway, sorry to interrupt. Anything else?

Oh, you know what? I do need to add too. So last week, one of my picks was Operation Code. And I mistakenly said it was dot com. It's actually dot org. So, if you want to check that out make sure it's OperationCode.org.

Oh man, that helps. I've been staring at this web page full of animated Gopher GIFs for the last seven days. [Laughter]

But it's been amazingly effective, right? [Chuckles]

I haven't written any bugs this week. [Laughter]

Alright. Dave, what are your picks?

Okay, so first pick is a nifty feature from Google which many of you probably already know. But if you search, as I just did, if you put the word define colon and then a term, Google will print the definition of that term. I just looked up the word 'regale' and it's not what I thought Joe meant at all.

But anyway, there you go. Define colon regale, and you can learn.

The Unseen 99%'. And it's an interesting article about the breakdown of the developer industry and how sometimes we think we have our finger on the pulse of the whole industry when really we just have a very myopic view of as little as maybe 1% of how actually people do stuff. Meanwhile, there are these other people doing things we had no idea about. And I thought it was pretty cool. And the other thing is, these 99% will probably not ever listen to this or ever read this article, according to this article. So, there you go. 'Dark Matter Developers'.

You read it on the internet. It must be true. Alright, I've got a couple of picks.

The thing that's been on my mind… so toward the end of the year usually around mid-November I start working on my goals for the next year. I don't like the idea of New Year's resolutions. I feel like New Year's resolutions are kind of a token, “Gee, it'd be nice to lose weight this year,” or, “I want to be a better person this year,” or, “I'm going to be nicer to my wife this year.” And you know, it's just kind of a nebulous, “Okay, I feel good because I said the right words,” kind of thing. And then you show up to the gym for two weeks and then you quit going, which is not what I'm about.

So, I was working on my goals. And right in the middle of that we had a baby right before thanksgiving. And then middle of December, my dad had open heart surgery. And I won't regale you with that story. But basically, I wound up spending the night with him the night that he came home from the hospital because my mom didn't trust him to be able to get around or anything like that, without falling down. And I needed to be able to help him out. Anyway, and then I wound up taking him to dialysis a few times because he has kidney failure. He doesn't know that I'm I guess spelling out all of his health problems. He's had hip problems for the last several years because he's been overweight. And he and I both have type 2 diabetes.

And so, I've kind of had this, I had this wakeup call like over and over and over again every time I went over there to help him. And I realized that I'm kind of headed down the same track. I've kind of half-heartedly taken care of my diabetes. I could probably stand to lose about 50 pounds. And I decided that this year while I was setting those goals, because I was super focused on the business, I needed to focus on my health. So, my picks are very health-related. Basically, just what I'm doing to make sure that this stuff doesn't kick me in the head the way it kicks him in the head. My dad incidentally, he's 60 so he's not that old to be having all of these problems.

So, my first pick is MyFitnessPal. That's MyFitnessPal.com. They have an iPhone app and an iPad app. And that's what I'm using to track my food. It also syncs up nicely with my phone so all the health information on my phone goes in there. I've been using the Nike Running plus app to track my runs and I'm using the 10K app on my phone to work up to a 10K. And that's one of my health goals this year, is to run a 10K. One of my other health goals is to run a half marathon. So, it's probably going to happen by May. I'm going to be running a 10K. So, if you want to come out to Utah or if you want to know which one I'm running, just let me know. And I'll fill you in. You can come run it with me. But anyway, so those are two things that I'm using as well.

30 when I'm running. And it does drown them out pretty well. I can still hear them obviously because it's not an [inaudible] ear in to ear thing but it works well.

My Pebble Time Steel watch, I recently picked up health tracking so it tracks my steps and stairs and everything else. But the other thing is I can control my music. And if I turn the screen off on my phone when I'm doing the 10K app, instead of taking over my headphones while I'm listening to music or listening to the podcasts and saying “Run now, Walk now,” because it does it a lot because it's every minute or two minutes or three minutes, it actually just vibrates my watch and tells me to walk or run that way. So, that's very convenient as well. So, I really enjoy doing that.

And then yeah, the only other thing that I haven't talked about with my health goals that I'm doing is I've quit caffeine about six times. So, I keep relapsing. And the longest I've gone is about three months. So, I decided to see if I could do a year. And so, I'm quitting caffeine for a full year. No more Diet Dr. Pepper for Chuck. But it's one of those things that I think I'll sleep better. I think I'll get used to just working better on things that are good for me like water. Anyway, that's a lot of longwinded stuff. But what I really want to do is just encourage you if you're listening to this and you're feeling like, “Well gee, I'd like to get into shape,” just do something. Make some positive change. And live your life a little bit better. There are so many great benefits to your life and your career that will come from being a little bit more active or getting a little bit more sleep or just taking better care of yourself. So anyway, that was a long-winded sort of serious pick. Anyway, all those links will be in the show notes. So, you can go get any and all of that stuff if you want it.

Rich, what are your picks?

I'll continue on the same theme. I took up climbing towards the end of last year. And it's great. I absolutely love it. Physically it's some of the best exercise I've ever had. It exercises muscles that you didn't know you had. Also, I think it's something that appeals to a lot of programmers because of the problem solving nature of it and the fact that all of the routes on an indoor climbing wall are numbered. So, you get this very tangible sense of progress. So, that's something that I've kind of fallen in love with over the last month or so. And I'm going to be doing a lot more of that in 2016.

My second pick is a website called TheCodelessCode.com. I'm always surprised that more people haven't heard of this. It's absolutely hilarious. It's a collection of programmer fables. Setting is fictional and Asian wilderness. And it's kind of loosely modeled after a book called 'The Gateless Gate' which is this famous book of Zen k_ans. And whenever it pops up in my RSS dashboard it's always the first thing that I read. It's thought provoking. It's funny. It's a lot of comedic [inaudible] and violence if you're into that sort of thing. The programmers in The Codeless Code have a very short life expectancy. So yeah, have a look at that. It's very good.

My final pick, I'm probably a bit late to this. I only saw it at the weekend and I don't know when this podcast is actually going to get put online. But the new Star Wars film. It's great. Everyone should see it. Even if you're not a big Star Wars fan. I don't know yet if it's going to stand the test of time.

But it's a lot of fun. And also the soundtrack that goes with it, great coding music.

So, those are my three picks.

Alright. Oskar, what are your picks?

I just have a single pick. And it's also health-related, kind of. It's related to… it's a talk by some guy. I can't pronounce his name [chuckles]. But it talks about website obesity. The bloat that's going on. How average websites are growing all the time. How they just keep getting larger and how we're causing it. What we're going to do about it. So, I think that's something for everyone to read. I think that's really interesting, working in this business. And particularly since I'm working for an advertising company, it's particularly close to what I do for a living. So, I think you'll enjoy it.

Alright.

There is a video talk as well. So, [inaudible].

That's awesome. Alright, well if people want to find out more about what the two of you are up to, more about Rollup.js or anything else related to what we talked about today, where should they go and what should they do?

RollupJS.org. Or you can find it on GitHub.

And I'm assuming both of you are on Twitter?

Yes.

We are, yes. I'm rich_harris.

The lot more active one.

I'm victorystick.

Alright. We'll go ahead and wrap up. Thank again for coming and talking to us about this.

Thanks for having us.

Thank you very much.

We'll catch everyone next week.