Babel Team

A JavaScript compiler that lets you use next gen JavaScript, today

Hosted by

11th September 2017, 6:00 pm

This AMA is over!

Thank the host

Message from the host 馃挰

Thanks for participating and asking the questions!

If you want to get more involved:

How do you all manage to be so awesome?

Lots of practice :P

Curiosity and practice, like @loganfsmyth said.

Not thinking about being awesome and working on things for the future/vision of what they can be. Balancing learning to do things out of joy/passion while doing things I know are good for me but I don't want to do - aka. practice

Hanging out and working alongside awesome people 馃挴

How can one join the core maintainers team?

If you are a contributor that seems to be invested in the project itself and not just your own issues/bugs/requests then you can probably join as a maintainer.

Although I'd probably ask, "Why do you want to be a maintainer"? (not to push anyone away). It's a question I (should) ask myself periodically. What kinds of things do maintainers do? I talk about this somewhat in my two talks:, It's not the most glorious thing, a lot of the work may seem tedious, github issues and dealing with people can be draining, and you end up not really writing that much code but doing a lot of project management.

For me personally though, it is worth it and fulfilling. It's an opportunity to learn JavaScript, getting involved in a programming community, learn many aspects of software engineering, and to serve others.

What are the biggest (technical and not technical) problems you are experiencing right now?

The biggest questions/problems at the forefront of my mind are probably:

  • How do we improve Babel's API so that it has fewer rough edges and foot guns?
  • How do we keep Babel useful as people use fewer ES6 transforms because environments support them?
  • How do we ensure that Babel's community stays active and evolves over time rather than stagnating?

I'd say we also have a lot of the same issues other volunteer-based open source projects have, e.g.

  • Who reviews PRs?
  • How do we ensure that PRs don't just sit forever / who gets to say "we're not accepting this"?
  • Who gets final say when we disagree on the direction/solution to something?
  • How do we encourage new people to join to help out?
  • How do we prevent burnout, since many people help with Babel alongside their full-time job?
  • What is the best way to reinvest donated money into Babel's community without introducing conflicts?

Compilers are something which I really want to learn about. Is there any good resources where I can learn about how Babel works?

I think it is mostly a question of which parts of compilation you want to learn. Babel is a pipeline for source-to-source code transformation, which means it is suited well for cases like compilation of ES* features. Most low-level compiler toolchains are going to do a lot more than that because they are converting from source code into a lower-level representation, whether that's LLVM's IR or bytecode or assembly. For a small overview of Babel you might consider looking at

When implementing a new spec, how closely does babel stick to it? Does it add any extra things to the feature?

Good question!

I made a new repo: to track the progess/implementation of new proposals. Also partially answered the question in

We try to stick to the "spec" as close as possible, especially now as we are working more with TC39 itself and ask them to review. Sometimes there is no spec yet anyway because it's a Stage 0/1 feature so the implementation will also inform the spec, etc. No, we don't add anything to the feature.

We may move out somethings that are too slow to a "spec" option in the plugin, and possible non-spec behavior to a "loose" option but we intend to keep the default behavior as close as reasonable to the spec behavior. A reason for this is simply that when browsers implement the spec and people use babel-preset-env to not compile supported syntax (or just not use Babel anymore), it will seamlessly work without any transition issues. For those that need a faster output (code size/speed), we will allow those people to knowingly opt-in to non-spec behavior.

Is there any talk about Babel being more involved in bundling? Babel already does a great job converting es6 imports to require but the bundling side has to defer to webpack/rollup/browserify. Would be great if one tool managed all this.

There're no internal discussions on it yet, but it's something I've thought of tackling a few times. I've written a few advanced introspection features for personal projects that break down at the module boundaries due to babel being only a per-file transformer, and there are definitely other cool things that could be accomplished with a full project level transform.

Just don't expect it in the short time, though. We're already fully loaded just trying to keep up with the syntax transforms.

@Henry I don't remember where you wrote it, but you said you were willing to discuss with managers (?) to try to convince some companies to start contributing to Babel. Have you already done that? If yes, how did it go?

Yeah I'l talk to people if they want, I don't remember everyone who reached out already

Babel was formerly called 6to5. How the name got changed?

Haha, this is a common question! I believe this is either before or right when some of the current team got involved with the project. TL;DR is probably just that Babel was compiling more than 6to5: 7to5, 8to5, ES2015toES5, etc. Babel is well known name regarding languages/translation via the Towel of Babel and Babelfish.

It's also our most commented on issue yet: (217 comments). In the end, Sebastian chose to go with Babel. James wrote a blog post on the rename:

Will Babel support workflow like autoprefixer - one will be able to define target support group "last 4 version" or "> 5%" and resulting transformations will reflect that?

We already have for a long time, with!

  "presets": [
    ["env", {
      "targets": {
        "browsers": ["last 2 versions", "safari >= 7"]

And we have support for reading a browserslist file instead of using the config option in the 2.0 version of the preset (in alpha with Babel 7).

To slightly expand on Henry's answer... the upcoming release of babel-preset-env 2.x has reading targets from the browserslist key in your package.json or .browserslistrc file enabled by default! This allows you to maintain a single config for both autoprefixer and Babel!

Are you a robot?

I'm not... but I've heard rumors that @hzoo is 馃

Is it possible to use Babel to convert a jQuery-dependent codebase -> vanilla JavaScript?

Definitely, though it'll be very hard to quickly translate 100% of jQuery code to just JS. This is because babel really shines as a syntax transformer (where crystal clear what's intended to happen in source code) vs jQuery which is a runtime library (which it's impossible to handle every case, because you can do crazy things in JS at times).

But if you're looking for something as simple as transforming $.each(array, () => {}) to array.forEach(() => {}, there shouldn't be any issues at all. Try checking out babel-codemod

Yeah you could use it as a codemod like Justin said to cover the 90% usecase and then manually convert the rest of it that isn't worth trying to code (which is advice for codemods in general).

How's your daily life while working on company and doing OSS project?

Busy and tiring :D I'm currently between jobs, but when I was working full-time it was definitely a tiring balancing act. I was generally triaging issues on the bus to work, helping on Slack when I had a free moment during the day, and then going home after work to fix issues and respond to anything that had come up during the day.

Having a fulltime job and also working on OSS projects can be a challenging balance act. I usually have phases where I have more energy and spend evenings and weekends on doing open source stuff but then there are also weeks were I don't do anything and rather watch TV or play games.

The good thing about the babel project is that even if I don't have time, I know that there enough other people looking after it and I don't need to feel guilty for not doing anything.

For me, my passion for side projects rises and falls. Some weeks I'll spend several hours at night reviewing and coding. And others I'll have no desire to look at my computer, let alone review someone else's code.

It definitely helps to be given time at work to contribute to open source work.

As both a new dad and startup co-founder, I often feel lucky to have even a few spare moments to help on the project where I can. I'll also echo Daniel's sentiments: one of the nicest parts of working on Babel is working alongside the community and everyone on the team.

What do you all think about babel-macros?

I haven't personally had the time to look into it much 馃槄

It's an interesting idea on meta programing! It kinda feels like the magic of using underscore templates, than realizing you can precompile them before serving.

how crazy/feasible would it be to allow for different backends using babel? (e.g. wasm, llvm...) (assuming a runtime is included)

It sounds like you want to run JS though babel, but have it output into wasm or c code? You'd have to write a new Printer, and translate unimaginable semantics. This is probably something of a 12 out of 10 on a difficulty scale.

What do you think are qualities of a good maintainer (instead of a contributor/starter)?

What kind of proficiencies must an aspiring Babel core contributor aim to have?

Depends on what things you want to tackle. We have quite a few features being written by summer interns the Google Summer of Code and Rails Girls Summer of Code projects, so you definitely don't need to be a superstar 20-year JS veteran to contribute.

For syntax transforms: A strong understanding of current ES5 code is helpful, then just the imagination to "desugar" ESnext code into whatever the ES5 equivalent is.

Or you can work with code health. @hzoo got started with updating out code linter. Documentation is sorely needed, test cases, or even build steps. So, just the ability to read someone else's source code and understand the intention.

Is babel-core/register production ready?

Quoting James Kyle:

> No and it's never going to be, it's a bad idea for production because it requires recompilation at runtime, which is the whole point of the register hook. source

Is it still valid?

babel-register can be used in production and I also did that at a company I worked for, but I wouldn't recommend to do it if it can be avoided.

What we mean by not production ready are more the technical limitations that babel-register has and that cannot be avoided which is why we do not recommend to use it for critical infrastructure.

James is correct that babel-register is build to transpile the code at runtime and in order to do that it needs to load babel, needs to load the sourcemap mapping module and also needs to keep the transpiled modules in the cache. This makes your NodeJS script have a longer startup time, and also consume more memory. Especially if you have a lot of files that babel-register needs to transpile this can lead to massive increase in runtime and memory.

An alternative recommended way is to use babel-cli and compile all the files for NodeJS during your build process or deployment beforehand and then use these files to run you NodeJS application. This way you don't need to load babel during runtime or hold anything in cache and you get the full performance that NodeJS can offer.

So the decision if you want to use it or not is always up to you. babel-register works stable but because of it's nature it will always be slower and more memory intensive than using regular pre-transpiled files.

Yes, that's our official position. But that may be a fine tradeoff for you. The issue is startup performance (or runtime performance if you lazy load things). Why would you want the first customer to wait an extra 1s while we compile the JS code, when you can run babel over the entire project first then start the server.

"A JavaScript compiler that lets you use next gen JavaScript, today" is too overwhelming for a beginner developer.

How would you explain Babel to them?

I'd probably descibe it as

A tool for transforming sourcecode from one form to another, with the most popular usecase being converting newer JavaScript syntax into older syntax to support older browsers and environments.

How to prevent people from using non-standard / unstable plugins in production?

Babel's architecture means that developers have to opt into experimental features, which hopefully provides an easy way to keep to see what experimental features are in use. We're also discussing doing some renaming of plugins in Babel's 7.x release to make it clearer when something is a proposal, e.g. "babel-plugin-transform-decorators" might be "babel-plugin-proposal-decorators" instead, so "babel-plugin-transform-*" would mean it's an ECMA-standard feature.

If you're aiming to use 100% standard features, ESLint would also make that easy, since you need to opt into using Babel's parser for it to support non-standard syntax.

Which editors do you guys use to code?

I have been using WebStorm for a very long time until I recently tried VSCode and I haven't switched back. :) All the extensions and integrations make it an awesome editor even when not writing TypeScript.

I'm a long time vim user who switched to VSCode a while back 馃槣

Vim/MacVim. I learned to code in notepad, then switched to TextMate and stuck there for years. In college, I was too scarred by Eclipse and Java to ever try an IDE again.

I've always been using Sublime

I use Sublime 3.x for general stuff, with vim for in-terminal editing like git rebase -i and such.

Is the project formally sponsored? Are any of you formally sponsored? Would the project be at risk if it wasn鈥檛 sponsored?

I think I'm the closest to being officially sponsored. I'm a Google engineer that spends my 20% time working on babel, and my direct team donates $100 on top of that.

@hzoo is a Behance engineer, and I think he spends roughly 50% of his time on babel?

Other than that, we're all unpaid volunteers. There's some backers on, but not nearly enough to sponsor a full time engineer.

A couple of Babel's contributors are able to work on Babel part-time at their day job, which helps keep things moving. Otherwise our team is primarily volunteers. Babel currently accepts donations on, but there's an open question around how best to reinvest those donations into Babel's community to keep things going.

Which upcoming spec features are you most excited about? pipe operator? observables (etc)?

For me, probably class private syntax. Any time I have to write a library I want to keep the implementation details hidden, and manually using WeakMaps isn't very ergonomic. Even in Babel's own codebase, it gets very unclear what is and is not supposed to be a publicly-accessible property.

(Maybe it's weird) I'm not particularly excited about any of them 馃檪 , same with the ones we've already landed

Hi Awesome Babel team! What was the initial motivation behind creating Babel.js?

I would just read Sebastian's post (the creator) on this 馃檪 :

Summary: Sebastian knew JS but wanted to actually understand how it all worked: what's the grammar, how do features interact, what's parsing, etc. He found Traceur and wanted to learn how compilers/ES6 worked so he just went ahead and combined a few js libraries to make it all work.

What's been your favorite experience/story from working on Babel?

Would you recommend newbies to learn and get comfortable with new stuff right away (promises, awaits, etc...) or go through established ways first?

The older ways work fine, and there are a lot of tutorials about them! I think there is a lot of advice on this but people like to say you may need to feel the pain in order to know why you would use the new thing. I don't think it matters that much: if you think it's too complicated to do something new, stick with what works. Chasing the new thing is tiring, unless using it is actually helpful enough?

Not everyone "has" to use the latest syntax or Babel

There's nothing wrong with using new standardized (as in, accepted and official JS syntax and runtime code). The ones you list are prefect examples of official code. Promises are everywhere, and essential to understanding async in JS. Awaits are well on there way to becoming best practice (and mandatory) learning, too.

But be careful with "experimental" codes that are not fully standardized (still in the proposal process, per the TC39).

Which module of Babel would you recommend first, if I needed to start contributing to Babel?

Hard to answer in terms of a specific "module", but a couple ideas:

  • Check out any issues (especially those tagged with beginner-friendly)

  • Anything related to documentation or the website

  • Do you use Babel? Have you set it up yourself? We'd love to improve the developer experience overall, which includes both contributing to the code base as well as usage.

What are the tools you use to test the product?

We use babel to test itself. Our fixture tests are hand written "source files" (called actual.js) that are then run through babel and byte checked against our expected output files (called expected.js). For advanced runtime tests, we run exec.js code, which is source code that is run through babel then executed as actual JS code with tests assertions.

We currently use Mocha unit tests with a large dataset of expected inputs and outputs for transformations.

For more info on what Justin said:

These are all fixture tests that some people know now as "snapshot" tests (we have our own naming, etc)

We're working with folks on TC39 like Leo, Rick, and Mike at Bocoup to get test262 tests in Babel - And ideally we would run Babel on itself before publishing as well as have smoke test for top npm packages. (these are all important contributions someone could make)

How is your development lifecycle structured?

Can check out This is kinda generic so not sure how to answer. Like a lot of projects, it's not that organized. People tend to work on what they like and we push those people to lead that effort and find more people to get involved. We try to have meetings to focus on certain efforts but ultimately we can't/don't really have deadlines.

what is main scope of the babel project? how to organize your team? please tell your developing story of the project?

For a beginner like me who just knows that Babel can transpile ES6/7 to ES5, how can I get deep into the transpiling part of Babel.

An invaluable resource in learning about how Babel plugins/transforms work is James Kyle's awesome babel-handbook.

Also, be sure to examine the plugins that are part of Babel and play around with astexplorer... they're both fantastic ways to learn as well.

As always, feel free to join our Slack if you need help or have any questions!

Babel has support for few stage-0 proposals but not everything. How do you choose which feature to add to babel?

Same as Which ones aren't supported? pretty sure we cover most if not all, it's definetely not a few haha?

We follow the TC39 proposal process, mainly. Anything that's been accepted as a stage-0 proposal by TC39 (and was presented to the committee or has a clear understanding of the semantics). We've tried to outline this at babel/proposals

There are a few primary factors that come to mind:

  • Proposals that are not syntax-related are usually left up to core-js to polyfill, and some new features just can't be polyfilled
  • We're a volunteer team, so someone needs to come forward with the interest to implement a given proposal, and ideally keep it updated.
  • Some stage 0 proposals are expected to iterate quickly, which it less likely that someone will want to maintain it.

We try to support as much as possible for all proposals where we get the signal from their champions that a basic consensus for this exists in TC39.

In the past we were very slow in getting new proposals implemented because we did not have enough people on the team. Luckily this changed in the last months and the next major version of babel will include a lot of the new proposals.

Babel adds bootstrap code to every single file which becomes repetitive across files. Is there any way to overcome this?

not sure what "bootstrap" code is, but I assume you mean helper methods. If it's the same then gzip covers it and otherwise you can use babel-plugin-transform-runtime

Definitely recommend checking out babel-plugin-transform-runtime. Specifically, only enable helpers and disable polyfill and regenerator.

How can I get babel compiler logs when there is an error in compilation?

You should already be getting a stack trace and the exact source code that causes the issue. If you're asking about badly transformed code (as in, the output is incorrect), then you'd have to do some digging like disabling plugins 1 by 1 until you track down the offender.

We don't have a specific log. Generally if an error is encountered, Babel will throw an exception, and it would be up to whatever is calling Babel to handle that. Usually that means it will be displayed in the console.

Hey! Any plans for compiling Typescript?

Yep 馃槑 ! we already landed this for 7.0 with the help of the Typescript team. (It took a lot of work on their part, and a lot to review for us), so look out for a blog post/guide soon on how to make this work.

Basically, babel-preset-typescript will work the same as babel-preset-flow to remove the types from your code.

Is there any way to omit a commonly added plugin or preset under environment configuration in babelrc file? Right now because of non common required in a particular environment, I have to copy all the common config to each environment.

In Babel 7.x we're adding support for a .babelrc.js file, so you can potentially programmatically build up the config you'd like based on environmental variables, to try to address cases like this more easily. Feel free to join our Slack if you want to chat more.

The spec option in babel-preset-env makes the transformation more spec complaint. But, not activating it will create any problems in how it works?

This is similar to It might but we try to make the default as spec compliant as possible so the things in spec might be too slow to add in.

6to5 was an upstart competing with Google Closure Compiler and... Traceur, I think? Now it's the status quo. Do you foresee a smaller JS compiler coming along and having the same kind of success as Babel?

There is which is "smaller" but I don't think it's use case is the same. There is almost no configuration (not a bad thing at all) so no custom plugins, and it only compiles performant ES5. It's scope has expanded a bit (used to only be ES6, but now JSX, and people will continue to ask for more), and tries to compile to readable ES5 rather than be spec compliant.

However like any open source project you need a lot of maintainers to continually update it over the months/years. If someone wants to make something new instead, that sounds fine but depends on the goals and why you wouldn't contribute back to Babel already or refactor internally. No, I don't really see it happening, it's already hard enough to maintain Babel as is 馃槢

What was the last shell script you installed in your machine? 馃榾

I know this is off topic, but I am just curious.

i think the last one I coded up was to let me checkout Github PRs locally:

When is Babel v7 releasing? What's the estimated date?

I was planning on doing our first beta release today - Might have to delay since other work, doing this AMA, Kent's blog post today as well

How does your team maintain such huge code base and most importantly how do you find time for this apart from the day job?

It's impossible to know everything that's going on in a codebase - not that different from work, even more so for an open source project where you aren't reviewing every single PR or know about each aspect or part of the code.

We try to have team leads for different packages/areas which are mostly determined based on interest/history

We have to invest in getting more people involved so that we can get more reviewers ultimately.

You can find the time if it's (hopefully) fun enough to do, otherwise live your life with other hobbies, family, friends,et c.

Why do you continue working on Babel? What makes maintaining a project worth the time/effort?

What's it like to do a release? (what's involved, hows the stress level, handling regressions, changelog, community feedback, semver, etc)

What does the loose option in babel-preset-env does? - not as spec compliant, smaller output, may be faster. Try it in the REPL