
Babel 6.0 Released - clessg
https://babeljs.io/blog/2015/10/29/6.0.0/
======
puls
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](https://babeljs.io/docs/setup/#babel_cli))
a very simple way to get started?

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

~~~
coldtea
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._

~~~
thejameskyle
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.

~~~
coldtea
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.

------
wildpeaks
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](https://twitter.com/sebmck/status/659806490904166401)

~~~
babelon5user
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?

~~~
thejameskyle
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](http://slack.babeljs.io)

~~~
babelon5user
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.

~~~
babelon5user
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

~~~
babelon5user
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.

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

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

~~~
danielhgma
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](https://github.com/codemix/babel-plugin-typecheck)

------
msoad
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!

~~~
Cshelton
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.

~~~
davnicwil
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.

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

[https://github.com/babel/babel/issues/631](https://github.com/babel/babel/issues/631)

~~~
Cshelton
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...

------
netcraft
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!

------
steven777400
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.

~~~
strayptr
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.

------
coldtea
> _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.

~~~
thejameskyle
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.

~~~
coldtea
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.

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

~~~
coldtea
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".

~~~
thejameskyle
I'm done responding to you since you've chosen to be a dick throughout this
thread rather than have a productive conversation.

If literally anyone else wants to chat, feel free to ping me on other
channels.

