6 ms·

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/Webp

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

by dexwiz 9y ago

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.