Ask anything to Babel Team

Babel is a JavaScript compiler. It lets you use next generation JavaScript, today. It's pluggable, debuggable and is being adopted by many popular companies such as Facebook, NetFlix, PayPal and more.

Ask Babel Team about:

  • Babel
  • Future of JavaScript
  • ECMAScript
  • TC39
  • Maintaining OSS
  • Contributing to OSS
  • Plugin Ecosystem
  • Releases

Hosted by:


Thanks for participating and asking the questions!

If you want to get more involved:

Ask a Question

116 discussions

How do you all manage to be so awesome?

Show all replies

Hanging out and working alongside awesome people 💯

Reply to this…

Share your programming knowledge and learn from the best developers on Hashnode

Get started

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: https://github.com/hzoo/maintaining-an-oss-project, https://github.com/hzoo/so-how-does-babel-even-work. 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.

Reply to this…

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?

Reply to this…

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: https://github.com/babel/proposals to track the progess/implementation of new proposals. Also partially answered the question in https://github.com/babel/proposals#when-does-babel-implement-new-features.

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.

Reply to this…

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.

Reply to this…

Load more responses