7 ms·

Nearing the Babel 7.0 Release

113 points by edmorley 9y ago

dexwiz 9y ago
Babel is one the few pieces of the modern JS stack that "just works." Most projects work by just including `babel-preset-env`. It gets lumped in with Grunt/Webpack as being a pain, but I rarely fight with it. Compare that to Webpack where a minor config change can suck up a days worth of time wading through mountains of semi-complete documentation.
- celim307 9y ago
  Yup. sane progression of their various packages, plays well with other libraries, well explain changes and depreciation. So good you forget about it
  - Klathmon 9y ago
    It might be a bit of hyperbole, but I think Babel is a big part of why JavaScript has become the powerhouse of a language that it is today. Not only did it slingshot the usable version of the language to the latest version at a time when standards were languishing for years, and it also provided some much needed documentation. And I genuinely believe that babel had a large effect on the improvement of the language. The process for proposing new language features and getting them proposed was streamlined by babel, and after having looked into the process, it's honestly simple enough that anyone that knows Javascript well enough would be able to submit new proposals.
- Jeaye 9y ago
  In my experience, babel is the single most unreliable and unusable piece of the build machine. The issue to blame is https://github.com/facebook/react-native/issues/12590 https://github.com/facebook/react-native/issues/12590 which has been "iceboxed" and not fixed. In short, I have to patch metro each build, to increase the time it waits before killing babel, since the 5 minute timeout simply doesn't cut it. Debug builds would take over 30m to transform with babel.
  - Klathmon 9y ago
    If you are still having the issue, why not comment to reopen it? The "icebox" was automatic after a period of inactivity, if you are still having the problem, they give pretty explicit instructions on how to respond. Also, that doesn't sound like a Babel issue, as I've compiled JS files that were several MB before without taking an unreasonable amount of time.
    - Jeaye 9y ago
      Primarily since it's been an issue for over a year, reported here https://github.com/facebook/react-native/issues/8475 https://github.com/facebook/react-native/issues/8475 as well, with no help from the RN team. > Also, that doesn't sound like a Babel issue, as I've compiled JS files that were several MB before without taking an unreasonable amount of time. The error is specifically that transformation of the JS times out, so it very much appears to be a babel issue. It might be something specific to the RN preset though.
  - hzoo 9y ago
    Hmm, sorry it feels that way! I don't use react-native and don't think anyone on the team was informed of that issue - but is it really an issue from Babel itself? I guess in that case I would suggest not transforming files like ".json" which if it's a wrapper around Babel could do for you automatically? It's not intended to transform JSON since it would just have the same output, not sure how it's related to compiling JS specifically.
    - Jeaye 9y ago
      This is strictly for transforming JS. It has existed for over a year, here https://github.com/facebook/react-native/issues/8475 https://github.com/facebook/react-native/issues/8475 as well. It's certainly possible that the babel team was never aware of it, but I'd imagine this has to do with the seemingly exponential growth of transformation time per source KB.
  - EngVagabond 9y ago
    I'm on the React Native team and if this is still an issue, we still want to know about it. As others said, the icebox occurs automatically after a period of inactivity. From quick glance, this seems more related to Metro, the packager that React Native uses. It was split out from the React Native repo and the team working on it is extremely receptive. I'd recommend opening a new issue on https://github.com/facebook/metro https://github.com/facebook/metro and linking to the issue in the RN repo.
- smhg 9y ago
  Did you use browserify before webpack? If yes, in retrospect, was the switch worth it? If no, it might be a way out of the configuration pains.
JeremyBanks 9y ago
Why would anyone use Babel instead of TypeScript's compiler these days?
- RussianCow 9y ago
  Because they don't want to use TypeScript?
  - JeremyBanks 9y ago
    TypeScript is very effective as a JS to JS transpiler for newer ES features. I've used the compiler many times without using the language.
    - RussianCow 9y ago
      Sure, but if you're not going to use TypeScript, why use its compiler over Babel? I find Babel much nicer to work with.
- lastofus 9y ago
  Probably due to the fact that we are not writing Typescript for sundry reasons.
- Klathmon 9y ago
  I actually use both babel and typescript on one project, because babel gives us more control over the output javascript using things like `babel-preset-env`.
- lhnz 9y ago
  Maybe because Babel is much faster at transpiling TypeScript.
- seattle_spring 9y ago
  We're using Flow instead of TypeScript, so I think that's a pretty good reason.
git-pull 9y ago
All the stuff babel includes is really impressive. Checkout the pipeline operator: https://github.com/babel/proposals/issues/29 https://github.com/babel/proposals/issues/29 (https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator) That's some cutting-edge stuff. I wouldn't want to use it until it was official, but it's cool to have the opportunity to try TC39 (https://github.com/tc39 https://github.com/tc39) proposals via babel. In addition to the normal compiler usage for the latest standards. > We received a $1k/month donation from Facebook Open Source! > This the highest monthly donation we have gotten since the start (next highest is $100/month). When I read this, I kind of mumbled to myself, "that's all?" It goes to show how poorly funded open source projects are. We rely on these tools, file issues, and want them to work, yet there isn't enough to even pay someone to work on it full time. https://twitter.com/ShiyaLuo/status/931230821976907776 https://twitter.com/ShiyaLuo/status/931230821976907776 > Engineer: There's a thing we need in babel, can I spent 2 days with a PR for it > Company: lol no it's their job Yep, the problem is cultural. The whole system of reciprocity is out of whack. The system would work more smoothly if more people took on responsibilities, QA'd, contributed patches. Give engineers a % of time to contribute back to the libraries they use. And yea, contributing back upstream to libraries isn't always glorious as releasing your own stuff, but it's part of what open source is. These big companies (not naming names) would rather make totally new projects than pitch in maintaining current ones. I admit it, it's not fun to do, but it's necessary. > TL;DR: use babel-preset-env This is convenient.
- Klathmon 9y ago
  >This is convenient. Understatement of the year. It's not just convenient, it's an absolute gamechanger. JS gets a shit reputation for being mountains of config before you can do any work, but because of `babel-preset-env` I can start a new project, put `> 5%` in the babel config, and write in the latest and greatest version of JavaScript and have it just work.
  - krapp 9y ago
    >JS gets a shit reputation for being mountains of config before you can do any work But... that has nothing to do with JS and everything to do with the unnecessary complexity added by the ecosystem. Are developers no longer aware that they can literally just open any text editor and write JS and it will work? That no one actually has to use NPM or Babel or anything?
Klathmon 9y ago
I love the move to scoped packages. I encourage everyone to switch to scoped packages if possible, it gives you much more freedom over your name, reduces the chances of typosquatting causing your users problems, and can even help get your name out there a bit more! It's a no brainer, and I'm surprised more people don't use them.
- hzoo 9y ago
  Yeah I was hesitant due to not that much support in the community, etc but after hitting the typo-squatting issue over like 5 times (you'd think once would be enough) it just had to be done. There are other issues for our plugin ecosystem since people fail to know which ones are from us and which are just another plugin. I think before they were part of the paid npm plain or just not enough information about them, and the questions on what being an npm org meant, etc. Maybe Babel switching to them will help move that forward even?
hzoo 9y ago
Oh cool, didn't realize someone posted to HN (I haven't been on HN in a while =D)! Open to questions and clarifications (on the actual content of the upcoming release, process, how to help, future, whatever)! There are a few things we need to do like a upgrade tool and some other things that haven't been addressed like how library/module authors should publish to npm (do you include/exclude polyfills, do you compile down to ES5 or start introducing ES6+ code under a different folder or package.json string like "module" or "es2015" which will be out of date, etc) Also didn't write much about the Typescript support yet but we want to help people use that too if that helps with their development
- renchap 9y ago
  I am very interested about publishing ES6+ code. https://philipwalton.com/articles/deploying-es2015-code-in-production-today/ https://philipwalton.com/articles/deploying-es2015-code-in-p... was very inspirational on this topic, but the fact that 99% of the libraries I use are publishing transpiled code (+ polyfill) is a big disappointment. From what I understood, there is currently nothing to allow both ES5 and ES6 code to be published and let the bundler choose which one to include. Any ideas on how to change this?
  - hzoo 9y ago
    > From what I understood, there is currently nothing to allow both ES5 and ES6 code to be published and let the bundler choose which one to include. Any ideas on how to change this? Yeah it's mostly a conventional then we have to figure out. Some people have different "dist" folders like say with redux_- https://unpkg.com/redux@3.7.2/ https://unpkg.com/redux@3.7.2/ there is `src`, `lib`, `es`, `dist`. In package.json, you can specify "main": "lib/index.js", "module": "es/index.js", "jsnext:main": "es/index.js", "typings": "./index.d.ts", which a bundler like webpack will look at. The problem now mostly is that "module" assumes es modules but not a specific level of ES/polyfills and we want a way to do that instead. Making a yearly "es2015", "es2016" field seems weird and we want one that is up to date like preset-env?

113 points by edmorley 9y ago

Babel is one the few pieces of the modern JS stack that "just works." Most projects work by just including `babel-preset-env`. It gets lumped in with Grunt/Webpack as being a pain, but I rarely fight with it. Compare that to Webpack where a minor config change can suck up a days worth of time wading through mountains of semi-complete documentation.

celim307 9y ago
Yup. sane progression of their various packages, plays well with other libraries, well explain changes and depreciation. So good you forget about it
- Klathmon 9y ago
  It might be a bit of hyperbole, but I think Babel is a big part of why JavaScript has become the powerhouse of a language that it is today. Not only did it slingshot the usable version of the language to the latest version at a time when standards were languishing for years, and it also provided some much needed documentation. And I genuinely believe that babel had a large effect on the improvement of the language. The process for proposing new language features and getting them proposed was streamlined by babel, and after having looked into the process, it's honestly simple enough that anyone that knows Javascript well enough would be able to submit new proposals.
Jeaye 9y ago
In my experience, babel is the single most unreliable and unusable piece of the build machine. The issue to blame is https://github.com/facebook/react-native/issues/12590 https://github.com/facebook/react-native/issues/12590 which has been "iceboxed" and not fixed. In short, I have to patch metro each build, to increase the time it waits before killing babel, since the 5 minute timeout simply doesn't cut it. Debug builds would take over 30m to transform with babel.
- Klathmon 9y ago
  If you are still having the issue, why not comment to reopen it? The "icebox" was automatic after a period of inactivity, if you are still having the problem, they give pretty explicit instructions on how to respond. Also, that doesn't sound like a Babel issue, as I've compiled JS files that were several MB before without taking an unreasonable amount of time.
  - Jeaye 9y ago
    Primarily since it's been an issue for over a year, reported here https://github.com/facebook/react-native/issues/8475 https://github.com/facebook/react-native/issues/8475 as well, with no help from the RN team. > Also, that doesn't sound like a Babel issue, as I've compiled JS files that were several MB before without taking an unreasonable amount of time. The error is specifically that transformation of the JS times out, so it very much appears to be a babel issue. It might be something specific to the RN preset though.
- hzoo 9y ago
  Hmm, sorry it feels that way! I don't use react-native and don't think anyone on the team was informed of that issue - but is it really an issue from Babel itself? I guess in that case I would suggest not transforming files like ".json" which if it's a wrapper around Babel could do for you automatically? It's not intended to transform JSON since it would just have the same output, not sure how it's related to compiling JS specifically.
  - Jeaye 9y ago
    This is strictly for transforming JS. It has existed for over a year, here https://github.com/facebook/react-native/issues/8475 https://github.com/facebook/react-native/issues/8475 as well. It's certainly possible that the babel team was never aware of it, but I'd imagine this has to do with the seemingly exponential growth of transformation time per source KB.
- EngVagabond 9y ago
  I'm on the React Native team and if this is still an issue, we still want to know about it. As others said, the icebox occurs automatically after a period of inactivity. From quick glance, this seems more related to Metro, the packager that React Native uses. It was split out from the React Native repo and the team working on it is extremely receptive. I'd recommend opening a new issue on https://github.com/facebook/metro https://github.com/facebook/metro and linking to the issue in the RN repo.
smhg 9y ago
Did you use browserify before webpack? If yes, in retrospect, was the switch worth it? If no, it might be a way out of the configuration pains.

JeremyBanks 9y ago

Why would anyone use Babel instead of TypeScript's compiler these days?

RussianCow 9y ago
Because they don't want to use TypeScript?
- JeremyBanks 9y ago
  TypeScript is very effective as a JS to JS transpiler for newer ES features. I've used the compiler many times without using the language.
  - RussianCow 9y ago
    Sure, but if you're not going to use TypeScript, why use its compiler over Babel? I find Babel much nicer to work with.
lastofus 9y ago
Probably due to the fact that we are not writing Typescript for sundry reasons.
Klathmon 9y ago
I actually use both babel and typescript on one project, because babel gives us more control over the output javascript using things like `babel-preset-env`.
lhnz 9y ago
Maybe because Babel is much faster at transpiling TypeScript.
seattle_spring 9y ago
We're using Flow instead of TypeScript, so I think that's a pretty good reason.

git-pull 9y ago

All the stuff babel includes is really impressive. Checkout the pipeline operator: https://github.com/babel/proposals/issues/29 https://github.com/babel/proposals/issues/29 (https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator) That's some cutting-edge stuff. I wouldn't want to use it until it was official, but it's cool to have the opportunity to try TC39 (https://github.com/tc39 https://github.com/tc39) proposals via babel. In addition to the normal compiler usage for the latest standards. > We received a $1k/month donation from Facebook Open Source! > This the highest monthly donation we have gotten since the start (next highest is $100/month). When I read this, I kind of mumbled to myself, "that's all?" It goes to show how poorly funded open source projects are. We rely on these tools, file issues, and want them to work, yet there isn't enough to even pay someone to work on it full time. https://twitter.com/ShiyaLuo/status/931230821976907776 https://twitter.com/ShiyaLuo/status/931230821976907776 > Engineer: There's a thing we need in babel, can I spent 2 days with a PR for it > Company: lol no it's their job Yep, the problem is cultural. The whole system of reciprocity is out of whack. The system would work more smoothly if more people took on responsibilities, QA'd, contributed patches. Give engineers a % of time to contribute back to the libraries they use. And yea, contributing back upstream to libraries isn't always glorious as releasing your own stuff, but it's part of what open source is. These big companies (not naming names) would rather make totally new projects than pitch in maintaining current ones. I admit it, it's not fun to do, but it's necessary. > TL;DR: use babel-preset-env This is convenient.

Klathmon 9y ago
>This is convenient. Understatement of the year. It's not just convenient, it's an absolute gamechanger. JS gets a shit reputation for being mountains of config before you can do any work, but because of `babel-preset-env` I can start a new project, put `> 5%` in the babel config, and write in the latest and greatest version of JavaScript and have it just work.
- krapp 9y ago
  >JS gets a shit reputation for being mountains of config before you can do any work But... that has nothing to do with JS and everything to do with the unnecessary complexity added by the ecosystem. Are developers no longer aware that they can literally just open any text editor and write JS and it will work? That no one actually has to use NPM or Babel or anything?

Klathmon 9y ago

I love the move to scoped packages. I encourage everyone to switch to scoped packages if possible, it gives you much more freedom over your name, reduces the chances of typosquatting causing your users problems, and can even help get your name out there a bit more! It's a no brainer, and I'm surprised more people don't use them.

hzoo 9y ago
Yeah I was hesitant due to not that much support in the community, etc but after hitting the typo-squatting issue over like 5 times (you'd think once would be enough) it just had to be done. There are other issues for our plugin ecosystem since people fail to know which ones are from us and which are just another plugin. I think before they were part of the paid npm plain or just not enough information about them, and the questions on what being an npm org meant, etc. Maybe Babel switching to them will help move that forward even?

hzoo 9y ago

Oh cool, didn't realize someone posted to HN (I haven't been on HN in a while =D)! Open to questions and clarifications (on the actual content of the upcoming release, process, how to help, future, whatever)! There are a few things we need to do like a upgrade tool and some other things that haven't been addressed like how library/module authors should publish to npm (do you include/exclude polyfills, do you compile down to ES5 or start introducing ES6+ code under a different folder or package.json string like "module" or "es2015" which will be out of date, etc) Also didn't write much about the Typescript support yet but we want to help people use that too if that helps with their development

renchap 9y ago
I am very interested about publishing ES6+ code. https://philipwalton.com/articles/deploying-es2015-code-in-production-today/ https://philipwalton.com/articles/deploying-es2015-code-in-p... was very inspirational on this topic, but the fact that 99% of the libraries I use are publishing transpiled code (+ polyfill) is a big disappointment. From what I understood, there is currently nothing to allow both ES5 and ES6 code to be published and let the bundler choose which one to include. Any ideas on how to change this?
- hzoo 9y ago
  > From what I understood, there is currently nothing to allow both ES5 and ES6 code to be published and let the bundler choose which one to include. Any ideas on how to change this? Yeah it's mostly a conventional then we have to figure out. Some people have different "dist" folders like say with redux_- https://unpkg.com/redux@3.7.2/ https://unpkg.com/redux@3.7.2/ there is `src`, `lib`, `es`, `dist`. In package.json, you can specify "main": "lib/index.js", "module": "es/index.js", "jsnext:main": "es/index.js", "typings": "./index.d.ts", which a bundler like webpack will look at. The problem now mostly is that "module" assumes es modules but not a specific level of ES/polyfills and we want a way to do that instead. Making a yearly "es2015", "es2016" field seems weird and we want one that is up to date like preset-env?