9 ms·

Babel 6.0 Released

74 points by clessg 11y ago

thejameskyle 11y ago
Contributor to Babel 6 and author of this blog post. If anyone has any questions, feel free to ask me here.
- bsimpson 11y ago
  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.
  - thejameskyle 11y ago
    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.
    - bsimpson 11y ago
      Links: https://www.npmjs.com/package/rollup https://www.npmjs.com/package/rollup https://www.npmjs.com/package/rollup-babel https://www.npmjs.com/package/rollup-babel
- joshuacc 11y ago
  I've seen some discussion between the TypeScript and Babel teams on Twitter. Any plans/thoughts about optional static typing in Babel?
  - danielhgma 11y ago
    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
  - thejameskyle 11y ago
    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.
msoad 11y ago
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 11y ago
  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 11y ago
    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.
    - fabian2k 11y ago
      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.
    - Cshelton 11y ago
wildpeaks 11y ago
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 11y ago
  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?
  - deleted 11y ago
    [deleted]
    - thejameskyle 11y ago
      You're cool, thanks for the productive input.
      - coldtea 11y ago
        OK, OK, I took it back. Just don't want to see a project I like lose focus -- I had that happen with other projects and it's bad.
  - thejameskyle 11y ago
    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 11y ago
      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.
netcraft 11y ago
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 11y ago
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 11y ago
  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.
puls 11y ago
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 11y ago
  Keep reading the blog post, we introduced presets for this very reason. It not hard to setup at all.
  - k__ 11y ago
    Not too hard, but still harder than before.
    - thejameskyle 11y ago
      The positives outweigh the 37 extra keystrokes you have to make to do the exact same thing as before.
      - puls 11y ago
        What was the downside to doing the same thing as before by default?
        coldtea 11y ago
        Backwards compatibility? Keeping with users expectations? Sensible defaults? Where's the fun in that?
        thejameskyle 11y ago
        There's a pretty lengthy discussion about it here https://github.com/babel/babel/issues/2168 https://github.com/babel/babel/issues/2168 I may do a followup blog post about it.
coldtea 11y ago
>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 11y ago
  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 11y ago
    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 11y ago
      Well modular and re-usable internals is exactly what we mean by "platform"
      - coldtea 11y ago
        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".
        11y ago

Babel 6.0 Released

74 points by clessg 11y ago

thejameskyle 11y ago

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

bsimpson 11y ago
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.
- thejameskyle 11y ago
  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.
  - bsimpson 11y ago
    Links: https://www.npmjs.com/package/rollup https://www.npmjs.com/package/rollup https://www.npmjs.com/package/rollup-babel https://www.npmjs.com/package/rollup-babel
joshuacc 11y ago
I've seen some discussion between the TypeScript and Babel teams on Twitter. Any plans/thoughts about optional static typing in Babel?
- danielhgma 11y ago
  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
- thejameskyle 11y ago
  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.

msoad 11y ago

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 11y ago
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 11y ago
  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.
  - fabian2k 11y ago
    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.
  - Cshelton 11y ago

wildpeaks 11y ago

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 11y ago
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?
- deleted 11y ago
  [deleted]
  - thejameskyle 11y ago
    You're cool, thanks for the productive input.
    - coldtea 11y ago
      OK, OK, I took it back. Just don't want to see a project I like lose focus -- I had that happen with other projects and it's bad.
- thejameskyle 11y ago
  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 11y ago
    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.

netcraft 11y ago

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 11y ago

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 11y ago
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.

puls 11y ago

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 11y ago
Keep reading the blog post, we introduced presets for this very reason. It not hard to setup at all.
- k__ 11y ago
  Not too hard, but still harder than before.
  - thejameskyle 11y ago
    The positives outweigh the 37 extra keystrokes you have to make to do the exact same thing as before.
    - puls 11y ago
      What was the downside to doing the same thing as before by default?
      - coldtea 11y ago
        Backwards compatibility? Keeping with users expectations? Sensible defaults? Where's the fun in that?
      - thejameskyle 11y ago
        There's a pretty lengthy discussion about it here https://github.com/babel/babel/issues/2168 https://github.com/babel/babel/issues/2168 I may do a followup blog post about it.

coldtea 11y ago

>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 11y ago
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 11y ago
  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 11y ago
    Well modular and re-usable internals is exactly what we mean by "platform"
    - coldtea 11y ago
      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".
      - 11y ago