When I read

> This means when you install Babel it will no longer transpile your ES2015 code by default.

what I really see is "This means that Babel no longer works out of the box and is now harder to use."

Was any thought given to how much additional complexity this adds to what was previously (https://babeljs.io/docs/setup/#babel_cli) a very simple way to get started?

Keep reading the blog post, we introduced presets for this very reason. It not hard to setup at all.

To quote Jamie Jawinsky (Jwz):

>You have invoked the "Oh, but there's a setting to turn off that stupid behavior" defense. I am showering you with negativity.

You must really enjoy going through threads to say the same negative thing over and over. This is exactly why I can't stand Hacker News.

I've posted two comments discussing default behavior. Too many ("over and over")? And I can see several others raising the same issue in this very thread -- all wrong to focus on that issue?

My main concern was raised in the longer thread with you. It is negative because I don't see this as a positive move. Nobody explained why changing the default behavior is a good move (even if it's easy to add back), or what it has to do with a desire for modular internals (since those don't preclude that).

In any case, Babel has been a valuable tool and I really hope this direction comes out for the best.

i think it's entirely ridiculous it will do nothing unless you specify a preset. a default preset is likely what most users would expect

Meh, that's becoming less and less true. We're definitely never going to do that again.

The positives outweigh the 37 extra keystrokes you have to make to do the exact same thing as before.

There's a pretty lengthy discussion about it here https://github.com/babel/babel/issues/2168

I may do a followup blog post about it.

Quick start for Babel 6:

  npm install babel-cli babel-preset-es2015
  echo "class Foo {}" > test.js
  babel --presets es2015 test.js

From: https://twitter.com/sebmck/status/659806490904166401

Not crazy about the lack of defaults for the old behavior, but this concerns me more...

Time to transpile "class Foo {}"

  babel 5.8.23: 0.55 real, 0.54 user, 0.05 sys

  babel 6.0.2:  2.37 real, 2.19 user, 0.23 sys

Why is babel 6.0 four times slower than 5.8?

That's concerning, this is what I'm seeing on my system:

    babel 5: 0.47s user 0.06s system 101% cpu 0.519 total
    babel 6: 0.47s user 0.06s system 102% cpu 0.508 total

Want to hop in our Slack channel? http://slack.babeljs.io

Regarding the very slow babel 6.0.2 timings - something odd is going on. I removed the babel 6.0.2 install, installed node 5.0.0 which ships with npm 3.3.6, ran the install commands at the top of this thread and the babel 6.0.2 speed reached parity with babel 5.8 - both babel versions ran at around 0.55s.

(edit) Then I leave the babel 6.0.2 install as is and then run it against a node 4.2.1 binary - the babel 6.0.2 speed is once again 0.55s - no difference.

So I removed both the node 5.0.0 and babel 6.0.2 installs, re-installed node 4.2.1 with npm 2.14.7 and ran the following commands:

  npm install babel
  npm install babel-cli
  npm install babel-preset-es2015
  node_modules/.bin/babel -V
  6.0.2 (babel-core 6.0.2)
  echo "class Foo {}" | time node_modules/.bin/babel --presets es2015
    2.55 real, 2.37 user, 0.23 sys

So the babel 6.0.2 speed difference is not due the node version, but may have something to do with the different npm versions and how they install node_modules, or the fact that I installed the modules one at a time.

Using Mac OS X 10.9.5 if it matters.

Babel 6.0.2 slowness reproduced on Ubuntu 14.04 using only node 4.2.1 and npm 2.14.7:

  $ uname -v
  #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC 2015
  $ node -v
  v4.2.1
  $ npm -v
  2.14.7
  $ npm install babel
  $ npm install babel-cli
  $ npm install babel-preset-es2015
  $ node_modules/.bin/babel -V
  6.0.2 (babel-core 6.0.2)
  $ echo "class Foo {}" | time node_modules/.bin/babel --presets es2015
  2.49user 0.12system 0:02.58elapsed 101%CPU

Compared to babel 5.8.23 on same Linux VM:

  $ babel -V
  5.8.23 (babel-core 5.8.24)
  $ echo "class Foo {}" | time babel
  0.58user 0.02system 0:00.57elapsed 106%CPU

So I've isolated the problem - babel 6.0.2 installed with npm 2.14.7 is slow, and when installed with npm 3.3.6 is fast. OS and node version is not a factor.

Contributor to Babel 6 and author of this blog post. If anyone has any questions, feel free to ask me here.

I've seen some discussion between the TypeScript and Babel teams on Twitter. Any plans/thoughts about optional static typing in Babel?

This plugin is pretty cool. It provides runtime flow-ish typechecking. It shows how easy it can be to consume type signatures and operate on them https://github.com/codemix/babel-plugin-typecheck

Likely a separate tool using Babel modules. Flow is more likely at this point. TypeScript syntax might be in the future too. There hasn't been a whole lot of desire for it yet.

Do you foresee {webpack, browserify} eventually being replaced by a Babel plugin? Dan is doing HMR in Babel now with babel-transform, which makes me think it's not that far out-of-bounds.

Using various Babel modules? Likely. Using Babel plugins? No, it wouldn't be a good way of building a tool like that.

Take a look at Rollup.

Links:

https://www.npmjs.com/package/rollup

https://www.npmjs.com/package/rollup-babel

First I thought after ES6 is landed in all browsers Babel would be unnecessary in near future but now that ES guys decided to release a new version each year it seems that we're going to see Babel around for a long time!

Great job btw!

If you look at which ES6 features are actually supported by the major browsers (https://kangax.github.io/compat-table/es6/) it doesn't look like you can drop Babel any time soon.

Some features are pretty well supported in the major desktop browsers, but if you also include mobile browsers it doesn't look that good.

It's just hard knowing which browsers will support something and when. It's be nice to have a browser target config nicely built in to babel. Like, I want to support any major browser version after Aug. 2015. If something is supported in all of the browsers, drop the transpiler for it.

Yes, fantastic idea.

I have been wondering about this a lot. It feels like about a year since writing then transpiling ES6 became a fairly mainstream approach, and we're nowhere near having full ES6 support in enough (or actually any, for now at least) browsers with a high proportion of usage.

This is manageable because you can just reason "well, I'll transpile everything to ES5" and be done with it. But what happens when most browsers do support ES6, but not ES7, or ES8 - what about when people don't update browsers, etc. I am really worried about this becoming such a nightmare that the default will always to be to transpile everything to an older version (probably 5 or 6) for the next 2-3 years just for safety, even when some browsers do support new versions coming out.

Can anyone point me to any resources which address and discuss this issue? Your idea about specific browser version targeting in the transpiler is a great one, and one I'd not even considered before, thanks.

Well I haven't contributed anything to babel, but if I get some free time (it's rare), I might see if I can figure something out and make a thread to discuss it. I'm sure they have thought about it already...

Even if you can list a version number for each of the major browsers you need to support, that'd be awesome.

We actually tell all of our clients using our Web app to update to the latest browser when possible. Hopefully the days of companies not upgrading their browsers are almost behind us... But I'm sure many will be stuck supporting Safari 8 for example, which has very little es6 support, for a while. I know of some large corporations who can't upgrade to IOS 9 and thus Safari 9 because of ivp6 issues...

> Can anyone point me to any resources which address and discuss this issue?

https://github.com/babel/babel/issues/631

Hmm, it was closed because it was considered 'out of scope'. Who does the testing on every browser/device combination seems to be the big question. Seems like something Babel should set up internally as it's their tool and thus people will need to trust when they say "on these devices and these browser versions, block scoping 'let' works." Rather than a 3rd party just saying, yeah it works...

Autoprefixer uses caniuse.com data to decide which prefixes to add. Not sure how exactly they do that and if that is a manual process or automated.

Caniuse has some data on Javascript support, but I'm not sure if it is at a sufficiently detailed level for this purpose.

Stop thinking about Babel as an ES* to ES5 transpiler. That's just one of the things Babel can do. http://babeljs.io/blog/2015/02/15/not-born-to-die/

Babel has been indispensable for us in the last year and looks to only be getting better. Congrats on the new version and I look forward to being able to transpile all the things!

Given that transpiling (one of the main features of Babel) seems to be increasingly popular, whatever happened to asm.js? Naively, it seems like targeting a highly optimizable subset of JS would be a smart idea if transpiling is being used anyways. Seems like I don't hear about asm.js much anymore.

When I targeted asm.js, the result wasn't much faster than plain js. Also, asm.js recently made it into Node, but Node doesn't tell you when your asm.js code is valid or not. And when it's invalid, it doesn't produce any errors.

I decided to check back in a couple years.

>Babel has spent the last year finding its place in the JavaScript community. In February we decided that Babel wasn’t just going to be a ES6 transpiler. Instead, it needed to become a platform. A suite of tools designed to create the next generation of JavaScript tooling.

Hmm, while this might work out for Babel, this is exactly how projects lose focus and falter.

The Eclipse IDE is a prime example of this BS -- there are tons of others.

Babel already had to build all of the things to do this, we're just exposing them to the world.

I can only see this improving things as people start using what was Babel internals directly and reporting issues on them as they are discovered.

Facebook has been doing this a lot the past few weeks and they've found a bunch of issues that we never caught.

Having modular and re-usable internals is a good thing.

But "we're now becoming a platform" raises red flags that it could mean things further than that -- the kitchen sink approach.

Well modular and re-usable internals is exactly what we mean by "platform"

But then why "modular and re-usable internals" also arrive with the removal of the default behavior of transpiling code?

(Which is what people used Babel for in the first place).

To me this signals: "we're now an abstract collection of tools for various js related tasks, no singular focus on being the best transpiler".