Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about frontend Web design and development. I'm Dave Rupert.

Chris, how are you doing today?

Chris Coyier: I'm doing absolutely fantastic. It's our second episode of 2019, some 300-something. I don't know. We've done a lot of these shows.

You know last year, Dave, me and you just kind of wrapped up a bit of a miniseries that we called "How to Think Like a Front-end Developer," which I have been working on and turned into a talk. It's just been fueling a lot of my thought recently.

We kind of figured out that there's a lot happening in front-end development. It's the biggest thing going on, on the Web. It's unbelievable what front-end developers are able to do these days, but there does seem to be a little bit of a divide. There are certainly people that are front-end developers who are happily doing a bunch of work that isn't particularly JavaScript-focused and then a whole bunch of people that are doing work that's just absolutely all JavaScript all the time, super deeply JavaScript. It was, I guess, your idea to home in on that latter half for a new bit of a mini-series on the show. Yeah?

Dave: Yeah, I just thought, if we erred on one side, it was more of that front of the front-end that Brad Frost talked about. Now, it's like, let's get in. Let's just go all JavaScript, like all, like full-blown JavaScript for whatever the next X number of episodes.

We have a special guest today who is sort of an umbrella project for the modern JavaScript, Henry Zhu. Hi, Henry. How are you?

Henry Zhu: Hey. Thank you for having me. I'm doing good.

Chris: That's fantastic. Henry, you're probably known for a number of things, have a brand new podcast people can check out called HopeinSource.com, which is a wonderful name. It says, "A podcast about faith and open source." You do a lot of thinking about opensource having one of the bigger open source projects there are, particularly in the world of JavaScript, and that's Babel, right?

Henry: Yeah, that's my full-time thing right now.

Chris: Full time, and that's somewhat new, right? Can you tell us about that?

Henry: Yeah. It's funny. It's been so long now, I guess. I left my job at Adobe in March. I guess it was March 1st, so it's been over ten [months] -- almost a year already.

Chris: Yep.

Henry: I kind of just took the leap, which I guess, looking back, I'm going to write a post about this but I guess I wouldn't suggest people randomly do that.

[Laughter]

Henry: I got, I guess I could say, lucky in a lot of ways and now I can support myself.

Chris: Do you find that, when people find that out, it's surprising there's one person who makes their living off of Babel despite it being absolutely ubiquitous in the world?

Henry: Yeah. Right. Right. I mean I'm surprised all the time. Every time there's something that happens, I'm like, why am I the only one working on this full time? Then even not full time, it's like we only have five or six people, core maintainers that spend their volunteer time working on it. Then just thinking about the scope of what our project does, in a way, it's sad, but also like, wow, it's still working and people are using it somehow.

Yeah, I think there's this overwhelming sense of, like, there's a lot of work to be done. That's probably why I have so much anxiety, so yeah.

[Laughter]

Henry: It's like, I'm technically living the dream for a lot of people. I get to do "open source" full time and not have to worry so much about the money, at least at the moment because, at any point, maybe people just stop donating. But it causes me to think more about these other struggles of, like, managing your time, priorities, how we set our boundaries, helping people, and what should I even do - that kind of thing.

Chris: Yeah, right. You're your own boss, and it's not always the dream. I think even people that are just kind of like generic freelancers go through some of the same struggle. They're like, "Oh, this is amazing. I don't have a boss. I can work from the beach if I want to." But it brings a whole new world of stressors, you know.

Henry: Right. No, exactly. Even just things that, well, I knew about them before, but it's one thing to think about it and one thing to actually live it out. Dealing with insurance, taxes, and making a company.

Chris: Yeah.

Henry: Should I even make a company? All those other things that you don't even need to think about if you're just working on it for fun.

Chris: Right.

Henry: Thinking about not just the future of the project, but how do I fit in that future? Should I code more or code less? I'm finding myself doing that less because I feel like the thing that we need is more, I guess, "managers" type stuff.

Chris: Yeah, leadership.

Henry: Yeah, and even that, I obviously don't know anything about that. I have no experience doing that other than through the context of this project. Maybe a lot of the struggle I have is just because I don't know what I'm doing and have a hard way of judging if I'm doing it right versus--

Chris: Yeah, it's not like you've got six months. You can just take a break and just really bone up on your leadership skills, you know.

Henry: Right. It's hard to get feedback, right? I don't have another manager. I can't move up. There's no sense of -- I don't know. It's just a lot of figuring things out and learning that it's okay to "fail."

I think the problem is, with open source, it's all volunteer, and so a lot of it is this internal struggle. I feel like I might fail the community or the project all the time.

At the same time, you're not even directly making money from it, so it's like what you said, why I feel like I can never take a break. When you're at your job, you're never thinking, "Oh, I'm making too much money," or whatever. You're trying to get a raise and stuff.

Here, I'm struggling. All these people are donating, maybe individual people or companies. Then I feel bad that I'm "wasting my time." Every minute has to be "productive." It's something I need to get over, but it's difficult.

Chris: Yeah, because it's self-imposed to some degree. If those people were unhappy, they could just stop donating. I don't know. It sounds like there's a lot of emotional stuff that's happening with this and you. It also sounds like it really hasn't shaken out yet. It's not like you've come to terms with 100% of this just yet.

Henry: Right. It's funny; you'd think I would. It's almost been a whole year. But, no, it's just getting started.

[Laughter]

Chris: Oh, gosh, a year. That's nothing.

[Laughter]

Dave: Yeah. Well, I think it's cool that you started, again, a project and maintained it. Now it's your job. I think that's certainly cool and novel, right?

Chris: Certainly. I would hope you have some pride of that. Yeah.

Henry: Yeah. I mean, yeah. It's funny. Maybe it's like I'm focusing so much on even the present and the future. I forget how far we've come. Yeah, it's definitely a privilege.

Chris: Well, let's do the past. Can we do the past? Maybe that's a little easier to talk about just right now. Wasn't there--? I almost forget what the world was like before Babel because, at some point, we tried to -- we wanted to use -- okay.

I've got to set this up in a good way. I still think of Babel as a way to use new JavaScript before my browser targets are ready or it. Is that still the number one use case of Babel? That's how the world thinks of Babel is, like, I want to compile JavaScript to an older version of JavaScript? Is that the number one use case?

Henry: I guess it's hard to know because this gets into analytics and stuff. I think, if you're talking in terms of what do people think Babel is used for, then yes, I think people still think that is the whole goal of it. I think it is. It's just, we have expanded the scope of what that means. Being able to do that allows you to do other things too. Yeah, I'd agree with that.

Chris: Yeah, okay, so that gets tricky. Before Babel came along that did that, as one of the things that it does--I know it's gotten a little bit more complicated these days--wasn't it Tracer or something? There were other projects that maybe they're still around, but you really don't hear them talked about in the community all that much anymore. For whatever reason, Babel struck a cord and that's what it did.

How did it--? What was it like in those early days? What was the point? What was the scope of the project and what were you thinking about while you created the project - that kind of stuff?

Henry: Right. Yeah, I can go into that. I guess, first, I'll say that it's funny. It's kind of like it's so ubiquitous now that people don't even think about it. It just exists. A lot of times I meet people that don't even know the name because it's in some other tool, like say Parcel, Webpack, Next.js or something.

Chris: Yeah.

Henry: Those tools include Babel by itself, so it's there and people don't think about it. Maybe that's why it's so hard for us to raise funding or awareness because it's almost like so used that it's gone now, which is a good thing in a way where it shouldn't be a thing you have to think about, but it also makes it hard for us to talk about it.

First, I guess I'll just say that Babel is a compiler. In other terms, nonprogramming terms, I would say it's a language translator, but the language happens to be programming languages.

History wise, I didn't actually start with Babel. It's funny because now that I'm the main person working on it, I think it's easy to assume that I made everything and stuff, but it was actually created by another engineer, Sabastian McKenzie. Right now, he works at Facebook. He also made a bunch of other tools that we all know like Yarn, Lerna, Prepack, and a lot of other things. Yeah, it was created. The first command, I think, was 2014, like September the 28th.

Chris: On that day, was it like, "This is a new tool for writing future JavaScript"?

Henry: Yeah, so no. He basically made it for fun, and he wanted to learn how languages worked. He had some experience with JavaScript, but he never was like, "How does this actually work?"

Then at that time, people were still learning about, like, what is ES6? We didn't even call it ES6. I think we called it, like, ES Next or something.

He was just curious about how things worked. He just wanted to learn that and decided to basically create. You mentioned Tracer before, and so that, I think that just came out at some point. That was by Google. He was like, "This is really cool. I want to basically create my own."

I think he said something like he has this "not invented here" syndrome, personally, which is good because it's the curiosity asks you, like, "Hey, how does this work? I want to learn. I'm going to try to make it myself," which we don't have a lot of all the time, right?

Chris: Then what did it do? Another way I think of it is, like, an AST creator kind of thing, right? It looks at a chunk of code and it turns it into tokens and stuff so that it can be programmatically worked with. Was that the original intent of that first commit?

Henry: Yeah, so this actually goes into the name, right? Why is it called Babel now? When it first came out, it was actually called 6to5. It makes sense because all it literally did was convert ES6 to ES5 and so, yeah, that was the point. It was literally just to convert that language.

Chris: Meaning, you write an arrow function. It turns into a regular function. You write let, it turns to var, or whatever - that kind of stuff.

Henry: Yep, exactly.

Chris: Yep.

Henry: I think what happened was, you know, Tracer was already out, but I think I might be wrong, but it was more of a research type thing. They weren't intending people to literally use it in production and turn into this thing where we write the new syntax and then it compiles it automatically and you can pretend like you're already using it.

I kind of think of Babel like jQuery. JQuery will let you write all this stuff and not have to think about the browser incompatibilities and stuff, right? It kind of is a layer in between so that it works in IE, Firefox, Chrome, and all that. Babel did the same thing, but actually for syntax.

Chris: Yeah, and people were excited about that because maybe there are some global JavaScript mindset that's just like, "I love this new syntax! I want to write in it right now. And if I need to put a tool in my build step to let me do that, I'm going to do it."

Maybe that's the spirit even still today. I mean I know we have ES5 code in our codebase at CodePen that is like that on purpose because it needs to be for some old browser support stuff, but we're constantly like, "Oh, it would be so nice to rewrite this and make sure that that particular area of our code gets Babelized. I think that spirit is still there. I still am excited about these things.

Then it got more; then it just got deeper, right? The language of JavaScript is constantly moving. It still is. I want to use promises now. I want to use whatever, decorator functions, whatever those are. [Laughter] I'm sure, on day one, it didn't support all that stuff, right? That became--

Henry: Right.

Chris: It turned into plugins eventually. Was plugins a later idea?

Henry: Yeah. I would first say that I wasn't even involved, actually, until it was called Babel, which is pretty hilarious.

Chris: Oh!

Henry: That's way further in. I'm assuming that, yeah, it didn't implement everything at first. Over time, people were asking for certain things. If it's called 6to5, then the goal would be to implement as much of ES6 as possible. Eventually, it's like, well, there are more features in the pipeline, so "ES7, ES8," that kind of thing.

Then it's like, how do we implement that? Eventually, it's like, wait; the way we implement those proposals or arrow functions and stuff in Babel itself, maybe they're just files. He realized, "Oh, we can make a plugin system," so that was added in, I think, Babel 5 or something.

Then, through Babel 6, it was like, okay, now we have presets where each plugin -- if a plugin is just one feature, like concerting arrow functions, and you want to install that one thing, maybe you don't want to install ten things because you want all of them, so you can create your own preset, which you could think of it as a config or an array of plugins.

Chris: Right. It seems like a big deal, right? I don't know that I necessarily have the expertise to decide which tandem that I want.

Henry: Right. Yeah, and so either you can trust someone else's pre-set, like, "Hey, I like this the way they do it and I'm just going to use that," or maybe you have one person at your company that handles that. Then you just use the same preset in all of your projects, which is helpful.

Chris: That's interesting. Pardon me if this is really basic stuff, but it's just where I'm at, I guess, in my understanding of the thing. Then that preset evolves too, right? Maybe the next time I yarn install or whatever, there's an update to the pre-set because JavaScript has just evolved a bit, those plugins have changed a bit, and I get those now too, so I have now unlocked some new feature of JavaScript just by virtue of the pre-set changing.

Yeah, kind of. The difference is that, yeah, it's hard. We can have docs, and I give talks and stuff but, in the end, it's hard to get everyone to understand everything that it can do.

There's a difference between the "official" presets that we create for people and the ones that you can make. Maybe you don't like what we have or you have a specific thing. Everyone can make their own preset and you can even publish it on NPM. If you use that and they update it, and you update your NPM packaged JSON, then it will get the new whatever change in that preset. It could be a new plugin. It could be an update. It could remove a plugin.

That gets into more complicated things in terms of just the idea of SemVer and breaking changes. Say they remove a plugin and you are using it, then that's technically a breaking change because now it's not compiling that thing. People have to be cognizant about that.

Chris: I mean that comes up with us at CodePen all the time because we offer Babel and we want to offer a fairly liberal version of it that lets you play with lots of different stuff, but we do not allow you to configure it either. So, we need to make these changes and we can't just rely on anything that might just change overnight. As we evolve and change things, we have to be really careful about that. That's interesting.

I'm sure other big projects are like that too, like, "Please don't change anything on me overnight," so they make their own config that they know that won't change.

Henry: Yep, or you would have to make sure that every change is basically a major version.

[Banjo music]

Chris: This episode of ShopTalk Show was brought to you by Jetpack, you know the WordPress plugin that does all kinds of stuff for your self-hosted WordPress site. I use it on every single self-hosted WordPress site I have because I just love the feature set. One of the feature-set things that's pretty cool is, you just flip it on.

There are a bunch of these, like, light switch features in Jetpack where you're just like, "Do you want this?" Yes. Switch it on. Now you have it. It requires no configuration, no fancy stuff. You just get some improvement from it.

One of them is that they have an image CND called Photon. If you have no image solution other than just hosting your own images on your own website, you'll almost certainly benefit from this. You just flip it on and then your images are hosted on their CDN called Photon, which is already good because CND hosted images are just an improvement, of course, but it helps optimize them. Because your site already does responsive images anyway, you have that.

I've talked about this before. They just improved this feature. They call it Site Accelerator now that does your images as well, but it's starting to host more and more files on their CND for you. This new one is that anything that ships with WordPress Core, any file that they can count on that is hosted in that way that your site uses for some reason, when you flip this feature on, it is also CDN hosted now. That's pretty cool.

I'm going to run some tests pretty soon, I think, on a self-hosted WordPress site with none of this stuff turned on and then flip it on and see what kind of speed improvements are there because they're definitely there, especially if you test in different locations around the world farther away from your home-based server and all that. The new Site Accelerator feature in Jetpack 6.7, I've just been like, "Hey, cool. Hey, thanks for the help." [Laughter]

[Banjo music]

Chris: And so, what about the concept of stages? Isn't that something you tried to move away from? Some people would just be like, "I don't know. I just want it all, so give me stage zero." Can you explain the concept of stages even though you don't use them anymore?

Henry: Right.

Chris: That was maybe a misstep?

Henry: Mm-hmm. Yep. Maybe you can link this in the show notes or something. I wrote a blog post on the Babel blog basically explaining. The title is something like Removing the Stage Presets in Babel - or something.

Chris: Yeah, I have the link here.

Henry: Oh, cool.

Chris: I'm sure this does go into it way more.

Henry: Yeah. No, I think it's a great question because it's not just about stages, but why I decided to do that. Why did I decide to write a whole blog post?

Chris: Yeah.

Henry: Because I knew there'd be some kind of backlash. This has to go into--I don't know--even just JS fatigue and configuration. We have lots of different views on the stuff where, like, some people think that we shouldn't have config at all and you should just make the defaults. Other people think you should be able to configure everything. Other people are like, you should have a good default. Maybe you can still override it. There are a lot of opinions with that.

Henry: The reason why we added stages is because TC39 itself, which is the committee of people that work on designing the language, stands for Technical Committee 39.

Before ES6, there weren't this idea of stages. It's funny. The whole specification of JavaScript was in a Word document, and that was really bad. Eventually, it got moved to GitHub.

[Laughter]

Henry: Yeah, I know. It's crazy.

Dave: Yowzah! I guess that explains a lot, to be honest.

[Laughter]

Henry: Well, you know, it's just updating to modern stuff.

Chris: Yeah, that's the way it is. Did they speak in the language of stages? That's how they talk about stuff?

Henry: Well, I guess the problem is, how do you--? This gets into, I guess, programming language theory. How do you know when something is ready to "be standardized"? Do you just get in a room with a bunch of people and they just vote on it? They're like, "Okay, I think we're good," and we just add it to JavaScript?

It's good, in a sense. It's good in a sense that, okay, "experts" are there and they know the history. They have context. They understand language design, but that doesn't mean they know.

They're not developers. They might not be developers. Maybe they're just people that work on languages, and they don't understand what it's like to write JavaScript every day.

The committee itself have grown so that it's not just people that work on languages, but the implementers of the browsers, so the engines like V8 and stuff, and then now, also, developers.

Chris: It's the same story, for the record, in CSS. It's good to have a room full of people that represent lots of different interests. it would really be a bummer if there are not just day-to-day authors in the room, so now there is.

Henry: Right. There needs to be this diversity of knowing, yeah, exactly, the different use cases and different viewpoints. That makes it hard because now everything means maybe it'll feel slower or where are we going? There's no direction because everyone has their own viewpoint and it's not singular.

The staged idea is just that, instead of going from zero to one where it's like zero is not in the language of one, it's in the language; we have these intermediate steps. I think of the steps in terms of how confident that we want this feature to be in the language.

Chris: If it's stage three, it's really close to being in the language if not already in browsers, some.

Henry: Right. I mean I guess it's kind of unfortunate that the stages are numbered because, obviously, semantically it doesn't mean anything, but I can explain it a little bit on how some people think about the numbers.

Stage zero, I would actually say that it's just an idea. That means that if you're using stage zero, there is no -- like, you shouldn't be confident at all that this will be in the language. It's literally like if someone thought, "Hey, why don't we do this?"

Chris: Yeah.

Henry: And I'm going to present it to the committee.

Chris: Yeah.

Henry: There is no implementation. Yeah.

Dave: That's like bootleg ideas, basically.

Chris: But it was super popular, wasn't it? People liked that because JavaScript people are crazy. They want weird stuff in their language.

Henry: I mean I don't fault people for that because everyone always wants to use the new, shiny thing, and they want to use it as soon as possible. It's just, they don't really think about the consequences of doing that. And we didn't do a good job of helping people think that way.

It's kind of like you don't have to think about it. You're just like, I want the most convenient thing, the thing that has no config. It's like, I don't want to have to add every plugin myself manually, so I might as well just do stage zero. There's a whole meme about how we could just use stage zero, which is really funny. [Laughter]

Chris: I get that, but what's wild to me is that couldn't there be a massive change from what that idea was in stage zero to, let's say, it does get some adoption, people like it, and it's starting to move towards a real language thing? We see this in CSS. There's an early idea. Then by the time it's further along and in a language, things have really changed with it. If you wrote a bunch of code at stage zero, it might quite literally break your code when it moves up a step, right?

Henry: Yes. That's totally true. It's inherent that it will probably break. It's very unlikely for something. It's kind of like if your idea that you made right now is exactly what it's going to be later. How is that remotely possible when it's a language, right?

Chris: Never. It'll never, ever happen.

Henry: Maybe the reason why it wasn't a big deal is because it just so happened that a lot of the things that we implemented didn't change that much. I'm thinking of class properties and object�.

Chris: You got lucky early on.

Henry: Yeah, and so we have a really good example of this actually happening with decorators. This is the epitome of the problem that we're talking about where we had stage zero decorators implemented and TypeScript implemented that too.

Everyone started using it. It got adopted by various frameworks like Ember and other things, Angular, and so, eventually, I think we implemented stage 1. But then that's probably going to change to 2. Then stage 2 is going to change.

That's for the user side. It's already hard enough to modify your code. Then from our point of view, like Babel, how do we create a system to allow people to continue to use the old thing but also upgrade to the new thing? That's so complicated. It's crazy. Do we create a new�?

Chris: It really sounds like a nightmare, you know?

Henry: Yeah, it is a nightmare. We have thousands of projects using it. Maybe even frameworks are using it. How do we upgrade people to the next thing? Do we create code mods? Do we need guides? - All of these things.

It is a nightmare but, in some sense, this is kind of like what Babel is for. There are no tools that help you use new syntax before it's out. It's almost like, why would you even waste your time doing it because it's going to change anyway?

This is kind of like the point of, I think, why is Babel special? Not just because of that compiling the new syntax to old, but making that pre-new syntax, proposal syntax, and influencing the language. There are no -- I think there aren't any other languages at all that would have this kind of concept because you don't need it.

Babel allows the community to be involved in the language design in the sense, they can use that new idea, then give feedback, and then, eventually, it should be better than it's just the people that worked on the language in the committee that made it. If it was just them, it would turn out a lot differently than if they showed people, like, "Hey, this is an idea."

I think, other languages, they might have a proposal, but that doesn't mean they're going to implement it, right? With Babel it's like we can actually do it, you can use it, and you can give real feedback based on your actual usage versus just thinking about it in your head.

Chris: Yeah. In a sense, it really benefits the language evolving in a good way because people have got a chance to play with something really early in a way that didn't break anything. It's just unfortunate. It's kind of a small subset of the problem is, when it does evolve, then how do you handle that?

This also exists in CSS. Vendor prefixes, for example, are a big thing in CSS. I think the industry smartly moved away from it because, the second they're available in browsers, people used it. Then, by the second, there's a critical mass of people using it, it can never change. They're like, "Oh, we really need to stop putting those in browsers right away and have a different way for people to test out these features," and they went with feature flags and stuff.

Crucially, there is, really, no Babel of CSS, really. I think PostCSS is probably the closest--

Henry: Right.

Chris: --because people make little modules that try to replicate some future feature. But even then, I think people realize it's a little dangerous because there's, okay, a PostCSS plugin that compiles down variables, those dash, dash variables in CSS. Well, immediately, they're not the same because now they're being compiled down to regular CSS and there's no way for a compiled down version of those to behave in the same way that they do naturally in the browser. There isn't, and I just don't see there ever being a Babel of CSS because of the nature of it, in a way. If there was, it would just face all the same problems that you're facing, I think.

Henry: Right. I think that's mostly because maybe there isn't an equivalent with the right behavior. A lot of the syntax in JavaScript is just sugar, and so it is "easy." [Laughter]

Chris: Yeah.

Henry: Obviously, it's a lot of work to do it. Sometimes, there is a one-to-one transformation that you can make. There are things on JavaScript that we can't compile.

Chris: What about something like a promise? Is there some way to un-promise, some elaborate way to write ES5 JavaScript? I can't even wrap my mind around that, but I reckon there is, I guess.

Henry: Right. That's a good question. What I would say for that is that we need to differentiate between syntax and this "standard library." Babel only converts syntax where it's like a new keyword, class, or arrow function. I would say that promise isn't actually a syntax. It's just a variable name that's a function.

In that sense, if Babel sees promise, it actually doesn't do anything to it. It just assumes that it's there. That's where the idea of polyfills come in. A polyfill is just doing promise equals some implementation. That has all the same problems where it's like maybe that polyfill had a bug and then now you're using that thing, or the browser version has a bug and stuff like that.

Chris: Mm-hmm. But Babel helps you with your polyfills too or not? Isn't there a thing called Babel Polyfill?

Henry: It's not something that Babel originally did, but I figured that it makes sense to add it in. This goes into preset ENV, but Babel Polyfill is just, yeah, a polyfill you can add. But if anyone looks at the source code, it's just like two import statements. It's like import of Core JS and Regenerator.

Core JS is a polyfill, and you don't have to use Babel Polyfill. There are all these options. We just do that because it has the name and you can use it.

Chris: Oh.

Henry: I almost feel like we should deprecate it just because then people will understand that it's not anything special. It's just a name that substitutes for something else.

[Laughter]

Henry: But we'll figure that out.

Chris: You heard it here first, everybody. Henry has officially announced [laughter] the deprecation. Just kidding. He didn't do that, but he might.

Henry: Maybe, yeah.

Chris: Fascinating.

[Banjo music]

Chris Enns: This episode of ShopTalk Show is also brought to you by Netlify. At its core, Netlify is a static file host that makes it extremely easy to deploy sites. Just a command line entry, a commit to a repo, or even drag and drop.

They do a lot of things you might think a static file host couldn't do, like allow your cloud functions to run, help you with processing forms, and even help with authenticating your users. When I'm not editing ShopTalk Show, I run a podcast network and we're using Netlify to host the entire site, other than the MP3 files, of course.

Their free plan is a great way to start out a personal website or project. I recently set up a new blog for podcasters using Netlify and Gatsby, all from the click of a button. By using Netlify's DNS for my domain, I'm able to share and preview branches of changes to the site before going live. They call it automatic branch subdomains. It's something I honestly wouldn't ever have bothered to set up or configure without Netlify.

Follow the link on the episode page or the chapter marker in your podcast player and check out Netlify for your next project. Our thanks to Netlify for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: Okay. This is such a great background. Dave, what's on your mind right now?

Dave: I think you've had already some success migrating people to the pre-set, ENV Preset, right? Maybe this is last year's news. [Laughter]

Chris: It does sound like a success story, though.

Dave: It was kind of like an issue, right? Everyone was on Babel Preset 2015, or something, and you were like, "Let's move to ENV." I'm sure things like create React app and things like that that had that built-in sort of helped that. What was that like to move--I'm thinking--millions of users over to something new? You know what I mean?

Henry: Yeah. I haven't really thought -- that's a good point, actually. It's like it is really hard for people to upgrade. I kind of just gloss over the fact that, yeah, we were able to finally do that.

One way of knowing this is looking at our NPM downloads. You would check Babel Preset ES 2015, and then checking them out for Preset ENV. At some point, it was higher, like downloads for ENV, which is great. There are a lot of things I could say about that.

We talked about presets. At first, we created Babel Preset ES 2015, which is basically ES6, because we knew that if you're going to use Babel for ES6, why would you want to ask people to add each plugin individually when they probably want all of them, right? And so, we added that.

Then eventually it was like, well, what are we going to do about next year? And so, I made 2016 and 2017. That was fine for a while. Then I was like, "Wait. Why would you need to do that every year?" It's like it's just going to get bigger over time, as well.

Then I made something called Babel Preset Latest. That was like, oh, naming is so hard. It's like, what do we call the thing that is just all the years combined that are not in the proposals? I was like, is it "latest"? Is it "standard"? - all these things.

Chris: There's some metric of success. If you get it wrong, maybe it doesn't click with people as well. It's not as adopted.

Dave: Just saying that, it makes me realize, every time I NPM install and let's say Babel updates or something like that, there's a chance I get a whole new ENV or, I guess--I don't know--ES 2019 snuck in there and now I have all those features. Is that kind of how it works?

Henry: Yes, in the sense that it'll be there because it's not breaking a chain just to add it in because, if you're not using that syntax, it won't break, so we might as well add in the new stuff. It goes back to communication on, how do we get people to do the best practice, to understand what the new features are, how to use them effectively, what the tradeoffs are, all that stuff. We've never really had a good job of that. I think it's obviously a really hard problem.

It's hard to do that through the tooling. Do we do it through the command line? Are people even looking at that? If we do it on Twitter, that's only a certain subset of people, on GitHub as well. It's hard to communicate to our user base when I don't even know how they're using it. Are they using it through a different tool? Should we instead be talking to the tooling people, like the frameworks and then, through them, it goes to other people? At the same time, there are people that are writing articles and videos that are about Babel and might not even be correct because they just found that out by themselves or something like that.

Dave: Yeah.

Chris: Oh, that's got to be tricky too because it is such a big name, of course. Surely, there is like Lynda.com videos that go all into it that you had no idea was even happening.

Dave: Yeah.

Chris: Not to call out them specifically. I have no idea. I just use it as an example.

Henry: Yeah, yeah, yeah. Right.

Dave: Yeah, totally unrelated. I was like, "I want to consume an API in view. Let me just look for examples." Somebody in a view method, the created method, they spin up an XML HTTP request inside that. That was their way to solve, which is fine and correct; it works. But I was like, "You can use Fetch [laughter] or Axios or something modern." I don't know. Anyway, there's a lot of bad code out there.

Chris: I've got a question about this because I wonder if this is not a big deal for Babel or a really big deal. One of them is that I've stopped supporting, let's say on my project, all versions of IEE. When I look at my browser support target, I can start shipping ES6 and I kind of want to because I've read, when we don't compile down to ES 2015 or whatever it is, it's faster. It's better.

The browser digests that stuff better, can optimize it better, so I want to still use Babel because, for some reason, I have to. Let's say I'm using JSX, which is another whole thing I want to ask you about. I wonder if transformations like that are just as big of a deal for Babel as convert new JavaScript to old JavaScript stuff.

Henry: Mm-hmm.

Chris: Now, I want to configure my Babel to just leave my arrow functions alone. How are you dealing with that? Is Preset ENV already there? Is it already past that point where it has stopped transforming arrow functions or not quite?

Henry: Mm-hmm. Yeah, so that's exactly what Preset ENV helps you do. Yeah. [Laughter] I feel like I can just talk about everything.

After we did Preset Latest, I figured at some point, like what you're saying, browsers will implement the features that Babel will implement. They're just lagging behind because it takes longer to get standardized and it also takes longer to write that code in C++ and ship it in the browser.

Eventually, Chrome and basically every browser now, they all support arrow functions, that are modern at least, not IE. Then I was thinking, well, I want to help people transition "off of Babel." It's kind of like the question of, when do I not need to use Babel anymore? It's not really not using Babel.

Chris: Have you--?

Henry: Uh-huh.

Chris: It's never, in a way, because there'll always be new stuff you want to do.

Henry: Yeah. Right. It's kind of a weird question to ask because it's like if you're using it now, you want to use it for some new, fancy syntax. There's always going to be some new fancy syntax that you want to use, so why wouldn't you want to use Babel with it? I think, in that sense, it will always be used, but it will just turn off the old transforms and you'll turn on new ones. Preset ENV should help you with that and do that automatically.

The way that works is that you could think of it as like a giant Excel sheet of every feature or plugin and of every browser and which version that they started supporting that. Then when you're using Preset ENV it, by defaults, compiles everything to the lowest common denominator. Say it'll compile all the arrow functions to regular functions. But if you say what browsers you support, explicitly, then it knows, "Oh, all these browsers are already supported, so I'll just turn it off." It's just like an on and off switch for all that stuff.

Chris: Wonderful. What a great idea, right?

Henry: Yeah, and so that happened. I don't even remember when I made that. I think that was the only thing I actually created. [Laughter] Everything else is just maintaining.

[Laughter]

Henry: That, in itself, that could be its own full-time thing. How do you manage that whole system and making sure it works? That can create its own set of bugs, obviously. Yeah, I think it's really helpful before now it helps people transition to not just thinking about JavaScript in terms of ES6, but just thinking about JavaScript beyond, like in the future.

We're always going to add new things to JavaScript. Browsers are always going to implement new features, eventually. Babel will implement new features. Then you will eventually drop old browsers. There are four different things, all these variables, and we need to figure out the smallest amount of code that we should send to the browser and then Babel can help you with that.

Chris: You have this two-sided problem that's interesting. If we think about Sass, the CSS compiler, they don't really have to care how the language of CSS evolves. They have to a little bit because they need to compile stuff that's compatible with that or if there's some new weird syntax; they have to make sure it doesn't choke in the Sass compiler. But when they ship a feature, they say, "We think this feature is going to be good for CSS authors. It's our invented syntax that we intend to support, not something that needs to be in the core language. It will just always be that way. This is our version of variables that we support."

It's too late now, but you could have done that in the early days, say, like, "We just think this is a good thing for the JavaScript language. This is how we're going to do it, and we'll always compile it to what the native browser does, but this is just our idea that we'll support," and that's not where you're going. You're saying, "We want to support where the language is going to go kind of on both sides."

Henry: Yeah, I think that is very unique, like you said. If we did it one way, then it would just be another language, right?

Chris: Right.

Henry: Like Elm, PureScript, Reason, or any of those things. Those are just languages that they have their own standard. They can do as they want, and they compile it down to JavaScript.

It's funny in that sense. I was just hearing about Dart. They're going to try to compile to a more modern syntax instead of ES5. Then their suggestion is that if you need ES5, you can use Babel. In that sense, Babel supports every other language that compiles to JavaScript because they might not compile all the way down to the lowest, right?

[Laughter]

Henry: They just want to compile to that.

Chris: Because you're open source, you can't be like, "That's a great idea, Dart. I'll offer that to you for $10,000 a month."

[Laughter]

Henry: Yeah, exactly.

[Laughter]

Dave: Thanks for the req, Dart.

[Laughter]

Chris: Not quite.

Dave: This sort of gets me into just the scope of Babel. One thing, I think, originally, I struggled with, like, okay, it's changing my syntax build. I'm not getting the features. You kind of covered that. It's not the polyfill. It's not really polyfill. It's just a syntax. It broadens your syntax compatibility, which I think is really sweet.

Another kind of core feature of Babel are these plugins. I think I always struggle with, "Oh, why isn't this working?" It's like, "Oh, you dummy; you didn't install Babel React - some weird thing, style, component, plugin, transform," you idiot. Then it's like, "Oh, yeah, of course I didn't. [Laughter]

Can you give us a scope of that plugin ecosystem? How many plugins are there? How many--I don't know--does the average build employ?

Henry: Yeah. First, I'll mention about the polyfill thing. Babel doesn't transform polyfills. But because of Preset ENV, we know which browsers support what, like what version of a browser supports promise. Then we can use that to turn on or turn off adding the polyfill for you. That's another thing that it does automatically.

Dave: Oh, that's cool.

Henry: Okay, so plugins, I guess it's another analytics problem that is hard to know. I don't know how many plugins there are, other than looking at NPM. You can just go to NPM. Search Babel-plugin, and I see, say, 3,000 results.

Dave: Oh, wow.

Henry: There's a lot. [Laughter] That doesn't mean you should use all of them.

[Laughter]

Henry: I'm sure 100 of them are just our plugins, right? There are a lot.

Chris: JSX has to be a huge one, doesn't it? That's how, if you write JSX, you probably use Babel to un-JSX it, right?

Henry: Right. Yeah. That's just the amount of plugins. I think it's funny in a sense that I don't think it's a bad thing that there are so many. It doesn't mean everyone is using all of them. But there is also a weird thing where it's like, are people just adding random plugins because they feel like and then that's causing bugs? Then that goes back to us. It's like, oh, why doesn't this work? It's because you're using this plugin.

[Laughter]

Chris: I always thought of that as a combination of Sass versus PostCSS. Sass, if you use it, you just use it, for the most part. The ecosystem, largely, there are some plugins and stuff, but they're not really core alterations of what it does whereas PostCSS does nothing by itself.

Henry: Right.

Chris: I don't know if that's similar with Babel. You have to add little pieces of it to do it, which means that every single project on earth that uses PostCSS has hand-pieced together all the little plugins that they use. I don't know what that means for the larger ecosystem of them.

Henry: Yeah.

Chris: It's weird. It's certainly like, eh, I don't know. It means every codebase is a little different.

Henry: Right. I think there are a few things that I don't like the fact that we have so many plugins either. It's not like, ah-ha, I want people to configure everything. I wish it was really simple, too. I just don't know the best tradeoff on how to have a really good default and then also somehow enabling people to add plugins and make it easy. I don't want it to be hard to use Babel at all.

Also, I don't want to force people to use Babel either. People feel bad that they're not using it. You never have to use it. It's an optional thing. If you don't want to write that kind of code then you don't. It's just hard to get that balance of all those things.

Dave: Well, and like you said at the top of the show. A lot of people aren't using just Babel right now. They're probably using it through another interface, probably Webpack, Parcel, or something.

Yeah, you copy/pasted some config you found on Stack Overflow and it's got some transforms that are happening. It all seems tough to figure out what's happening.

Henry: Yeah, there are multiple layers to it. It's like, do we add new docs? Do we make it easier? Are we supposed to reach out to the tool people? Do people even configure themselves? It's just weird to figure out exactly how to do it the right way without, I guess, pissing people off, which is weird.

It almost feels like everything we do is going to piss people off. [Laughter] Or, I just keep seeing the negative stuff and I only hear positive stuff when I talk to people in person. I go to a conference and everyone is like, "Wow! Thanks for all your work." I'm like, dang, this is great. Then you go online and everything is negative. [Laughter]

Dave: Yeah. Well, I'm sorry. I'm sure I've contributed to that. [Laughter]

I have a question. You've patiently worked with issues for me specifically, so I appreciate that. I want to get into that maintaining because I feel like that's a big thing you do. You're maintaining this repo for millions of developers, it seems. I'm sure that's stressful, but I think we had a conversation at a conference once.

You were just kind of like, "Oh, yeah, Microsoft did this giant PR on me to support all of TypeScript or something like that." But you're like, "And now it will take me a month or something to get through." You were just kind of like, "You know that's a lot of work, time, money, and all that."

Yeah, I think you've settled on kind of a Patreon sort of approach. I think there's another way: Opensource Initiative or something.

Henry: Open Collective, yeah.

Dave: Open Collective, yeah. I guess, what's the state of being a maintainer here in 2019?

Henry: Yeah. Even using that example, obviously, it's really cool that the TypeScript team made all those PRs. But in some sense, obviously, it helps them because it's about getting their adoption higher. They're really great, too, and I love working with them. It's just, in the end, they have a whole team of people that are funded by a big company to do this full time, and then we have a bunch of volunteers. It's kind of like, well, when am I going to prioritize doing this or that? Instead of spending a lot of time reviewing it, I'll just merge it anyway and then just see what happens because I just don't have enough time.

[Laughter]

Henry: Then when the bugs come in, you fix it.

Dave: Then you get the event stream problem, possibly.

Henry: Right. Yeah, you might be like, "Well, we only have six people, so should I start adding people?" Now the worst part is when stuff like event stream happens, it kind of makes every maintainer most cautious into adding people, which is not a bad thing, in some sense, because we don't want that to happen again. But it might get you a little bit more paranoid about, like, "Oh, maybe I should wait longer for them to get added, or I have to vet them and stuff."

It's like, yeah, we're all vetting people all the time, but how do you know when to trust somebody? They could be working for a whole year on something and then, at the end, they decide to do something bad. You can't fault yourself for that, right? You can't fault that guy for wanting to do that, and it's hard.

You only do that because you feel like you need to add more people or you don't have enough money to do it yourself. Even getting paid full time to do it, I'm not going to spend all my time reviewing PRs because, at this point, talking about maintenance now, it's like, "Is that really the best use of my time?" If all I did was look at issues and fix bugs, I don't think the project is going not move forward because no one is really thinking about that.

I'm finding myself, I guess, in the last months, thinking, "Yeah, maybe that "leadership management thing" is more important because we're thinking long term, right? We don't want to just take out the fires but figure out where is this project going and stuff like that."

Chris: You're in good company. I think that everybody eventually struggles with that, especially as you're years and years deep into a project. In the early days, it's just different. You're just like, "Oh, this is cool and fun. I'm going to do this." Then you're years and years deep into this important project that serves a lot of people and you need to think about, where is this thing going? Why are we doing what we're doing here? Who is steering the ship?

I only mention that to say I know it's stressful. There's no answer to the stress, but it's also, you're not alone.

Henry: Yeah. No, I think that's important to know. Sometimes it's better to know that there isn't really an answer because, I guess for any entrepreneurial thing, especially for open source, I guess, because there are few people doing it full time without a company, there isn't really a lot of people to look up, and I can't read some book and it'll tell me what to do, either. It's kind of like, in some weird way, people are looking at me to figure it out. I'm like, I don't know.

[Laughter]

Dave: No, because, on the surface, all features sound great to any kind of project or repo. But then it could also -- I don't know. One overcommitment could kind of break the camel's back, so to speak. It could really overburden the project, crash performance, or any kind of thing. It's tough work.

Henry: Yeah, and I guess, into maintenance, adding a feature doesn't mean adding that PR. It means supporting it forever, right? If it's something like adding, say, TypeScript, it doesn't mean that we're adding the current version of TypeScript. We're adding all of it. That's also a commitment on their team's part too, obviously, because if Babel only supports part of it, then it's going to look bad for them anyway.

It's a good thing, in that sense. We're working together. It's just that, on our side, we still need people to work on it and that's another thing that we have to think about. Everything we add is another piece of scope. I think it's worth doing it. Obviously, hearing about all these people that are switching to it, the reason why they're able to switch to it is because of this feature.

Dave: Yeah. I think I saw Dan Abramov from React kind of tweeting. He said something about code moding.

Chris: Mm-hmm.

Dave: You know, like, wouldn't you just code mod whatever anyway? Just kind of, hey, it's a given; you're code moding. You're throwing it through Babel and changing it anyway.

Henry: Mm-hmm.

Dave: I was like, "Oh, man." I don't always code mod everything, but I guess most people probably do. Even to the point, I was like, you could probably write in Swift of Objective C and run it through some kind of transform to get JavaScript out at the end. It wouldn't be impossible.

You could even--whatever--talk like a Piratscript or something.

Henry: Mm-hmm.

Dave: It could transpile to an actual JavaScript. I don't know. It's a lot of work there. That's all to say it's just kind of incredible what people are using it all for.

Henry: Yeah.

Chris: How should we wrap this up best? I should say, Henry has got a Patreon. If the entire ShopTalk Show audience could head over that, I'm sure Henry would appreciate that. He also has a new podcast, Hope in Source.

Dave: If we all gave $1 to Henry right now, committed $1--

Chris: I know.

Dave: --he would be rich.

Chris: What is Henry going to do with those extra $7?

Dave: I know.

[Laughter]

Dave: Seven whole dollars a month from ShopTalk. There you go.

[Laughter]

Dave: Yeah, Henry. Thank you so much for coming on the show. For people who aren't following you and giving you money, how can they do that?

Henry: Yeah, you can donate to the Patreon. It's Patreon.com/HenryZhu. That's if you want to donate to me individually. You don't have to do that. You can also donate to our Babel. We have an Open Collective, which is OpenCollective.com/Babel.

I don't have that much money on Patreon. I don't know exactly why, but it makes sense that we have a lot more on Open Collective because, from the company point of view, it looks good to say, "Oh, our company is supporting Babel." It would be weird if someone is like, "Oh, we're donating to Henry." [Laughter] Even though I'm the one working on it.

If you're a company or you work at a company then, yeah, you can look into that. We actually have a lot of sponsors now, so even Amp, which is a part of Google. They just committed or they just donated $2,000 a month for this year, so $24,000.

Chris: There you go, companies.

Henry: Yeah.

Chris: Look at that as an example. I mean Amp, Amp, Amp, there you go. You're welcome.

Henry: We have other companies too, like Facebook. They're donating like $1,000 a month. And various companies. It's just funny that it's almost like the company that donates the most, it kind of sets the bar for people. It's like, well, why aren't you donating? [Laughter] Why are you only donating $100?

Chris: Yeah.

Henry: You should donate that much too. It's like each company that donates more--

Chris: I don't know. The Price is Right rules. If you want to make a difference, you have to donate at least $2,001 a month.

Henry: Exactly. Hopefully, it's an increasing cycle, not just for Babel; for other projects too. It's like how do we make it normal for companies to donate back and stuff instead of just being like just for us.

It's like if we're only making a certain amount, then every other project is making 100 times less. It's like we need to be more visible so that it becomes a normal thing for everyone to donate.

Dave: I think that's true. I'm sure there's an NPM plugin that does it, but just analyzes your bundles and just is like, "Hey, here is a bunch of links. Here's what you should do."

[Laughter]

Dave: It would just be -- I don't know.

Chris: It'd be nice.

Dave: Yeah. I think most people listening to this podcast probably have something that depends on Babel. If we all gave $2 a month, it'd be no problem.

Chris: I wish there was some way to make it compile, like 0.001% better somehow, if you were a contributor.

[Laughter]

Chris: That'd be nice.

Henry: I mean we could totally do that, but I don't know if we would want to.

Chris: Okay. Okay.

Dave: We're talking $24 a year, the price of a Blu-ray, to write future JavaScript. No big deal. This is great. This is worth it.

[Laughter]

Chris: Well, Dave, I know you've got to run and I do, too.

Dave: Yeah, I've got to go. I have a hard stop. Thank you, Henry. Please follow him on Twitter. Yeah, thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter at @ShopTalkShow for tons of tweets a month. If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. I think we have a special announcement related to that.

Chris: Hey, we've got a job opening to let you know about. Actually, two of them, and it's at Clock. That's Clock.co.uk. They're an award-winning agency in Hertfordshire over in the U.K. They have all kinds of prestigious clients like New U.K., Riot Games, and you'll be working on big digital marketing campaigns with them. It's just the kind of people that, you know, probably listen to this show - extensive knowledge of semantic HTML and CSS, experience using JavaScript. Ideally, some React in there would be good. You're familiar with Git, GitHub, UX, and you're a detailed kind of person, at least a couple years' experience. They're asking about preprocessors like Sass, Less. Generally familiar with CSS architecture kind of things. Just the kind of stuff we talk about on this show. Hit them up. It's just such a beautiful place over there and such a cool company. Again, that's Clock.co.uk, but come over to our show notes to find a link right to this exact job position so you know how to apply.

Dave: Thank you for listening. Chris, do you got anything else you'd like to say?

Chris: Oh, ShopTalkShow.com.