Babel 7 Released(babeljs.io)
babeljs.io
Babel 7 Released
https://babeljs.io/blog/2018/08/27/7.0.0
38 comments
Henry in one of his interviews/podcasts mentioned that Facebook was not ready to employ him full-time to work on babel. Do you know anything about the reasoning about that decision?
> We had to wait until he was 18 before we made him an offer
Out of curiosity, why was that?
Out of curiosity, why was that?
Legal reasons to work in the US have to be 18 I think. Or something with visas
my guess is child labor laws
You can work from when you're 14 in Australia (possibly with parental consent, I can't remember, I was 14); but there's fun issues with contracts and international companies, I'd assume.
From Western New York, when I was 15/16 I got a workers permit to allow me to work at a pizza shop (Mark's Pizzeria) but it had a lot of restrictions like limited hours on a school night. This was over 15 years ago so I am not sure what the laws are now.
A reminder if you or your org use Babel to consider donating to Henry's patreon (https://www.patreon.com/henryzhu)
He's a smart, nice person who plays a large part in software that many of us use on a daily basis. Support open source if you can :)
He's a smart, nice person who plays a large part in software that many of us use on a daily basis. Support open source if you can :)
Of course it is great to see this progress, this big pile of improvements in Babel. Babel plus its ecosystem support both a mountain of production code and a remarkable playground in which upcoming language ideas gradually become mainstream.
But...
While Babel-core isn't overwhelming, the full set of transitive dependencies you get in normal use (with "env") is a lot of code, spread across numerous packages. Many projects care about the provenance of their dependencies, and having a very large number makes such provenance more to think about, more to track down, etc. The voluminous transitive dependencies also make for a slow "npm i" and so on.
I've been able to avoid Babel for some use cases: Even when not using types, the TypeScript compiler can handle a broad swath of typical ES-newish to ES-6-or-5 compilation use cases, with a total of 1 dependency (+0 transitive dependencies), quickly. The main downside of this approach is that people look at you funny when you use "tsc" on a non-TypeScript project.
But...
While Babel-core isn't overwhelming, the full set of transitive dependencies you get in normal use (with "env") is a lot of code, spread across numerous packages. Many projects care about the provenance of their dependencies, and having a very large number makes such provenance more to think about, more to track down, etc. The voluminous transitive dependencies also make for a slow "npm i" and so on.
I've been able to avoid Babel for some use cases: Even when not using types, the TypeScript compiler can handle a broad swath of typical ES-newish to ES-6-or-5 compilation use cases, with a total of 1 dependency (+0 transitive dependencies), quickly. The main downside of this approach is that people look at you funny when you use "tsc" on a non-TypeScript project.
If dependencies are an issue, I would like to make another package that just bundles it all into 1 package (reuse `babel`) so there aren't any "deps" to install but haven't gotten around to doing it, would be a useful contribution opportunity for someone though.
Most of my projects now use babel indirectly and its been removed from all backend projects at work, sometimes replaced with typescript or vanilla es6.
Ex: anyone using facebook's jest, vue-cli, etc will get v7 whenever those packages upgrade.
The typescript support seems interesting for people with large babel pipelines, but I'm not sure what the other use cases are since it doesn't do any of the typechecking tsc does. Would be interested in hearing what people plan to use it for.
https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...
Ex: anyone using facebook's jest, vue-cli, etc will get v7 whenever those packages upgrade.
The typescript support seems interesting for people with large babel pipelines, but I'm not sure what the other use cases are since it doesn't do any of the typechecking tsc does. Would be interested in hearing what people plan to use it for.
https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...
I recently evaluated using Typescript's compiler or Babel + TS plugin, and decided to use Babel. The main reason was keeping access to the Babel plugin ecosystem without needing to do tsc -> babel -> output, which would be a drag in development.
It seems to be more common now to see library-specific Babel plugins that optimize performance or improve developer ux. These plugins are usually optional, but I use them to enhance css-in-js and i18n performance/development.
With good editor support and ts-lint, the dev experience is solid and as-expected. Setting up an explicit tsc command as a pre-commit hook or CI task should provide that extra bit of confidence.
For myself, not being a TS purist, it feels like a good option.
It seems to be more common now to see library-specific Babel plugins that optimize performance or improve developer ux. These plugins are usually optional, but I use them to enhance css-in-js and i18n performance/development.
With good editor support and ts-lint, the dev experience is solid and as-expected. Setting up an explicit tsc command as a pre-commit hook or CI task should provide that extra bit of confidence.
For myself, not being a TS purist, it feels like a good option.
One benefit of running babel in parallel with tsc is that your execution doesn't depend on your code compiling. Sometimes, for example, if I'm hacking something together, it's faster to just disable type checking all together so I can do what needs to be done and save the type checking until later. Having babel + tsc allows you to do just that instead of having to do all the typing as you go.
tsc in --watch mode still outputs even if there are type errors for precisely this reason. You can ignore the cli warnings and still have everything run in the browser or node while developing.
I also haven't been using babel for most node projects; V8 has already implemented most of the major features I'm interested in.
I don't mind setting up a build tool and configuring everything if the project will be actively maintained or if there's a real need for it, but for smaller projects I think it's better to keep things as simple as possible. It's a huge drag when you later revisit a project and a bunch of dependencies are outdated or broken.
One of the holdouts which kept me coming back to babel was JSX, but eventually I learned to love preact and its hyperscript-inspired template function. The code ends up being a bit more verbose but you drastically cut down on dependencies.
Babel is still superb if you're targeting a broad range of browsers. Although during development I usually disable babel-loader from Webpack for the improved performance and debugging experience.
I don't mind setting up a build tool and configuring everything if the project will be actively maintained or if there's a real need for it, but for smaller projects I think it's better to keep things as simple as possible. It's a huge drag when you later revisit a project and a bunch of dependencies are outdated or broken.
One of the holdouts which kept me coming back to babel was JSX, but eventually I learned to love preact and its hyperscript-inspired template function. The code ends up being a bit more verbose but you drastically cut down on dependencies.
Babel is still superb if you're targeting a broad range of browsers. Although during development I usually disable babel-loader from Webpack for the improved performance and debugging experience.
It allows you to add TypeScript to your Babel project like you'd add a linter, i.e. you can optionally run tsc to catch potential problems, but in your build pipeline just skip that and build it using the full Babel ecosystem.
Great job to everyone involved! I've been keeping up with the project since it was 6to5, and these changes look like they'll help clean things up quite a bit and hopefully reduce user confusion.
This change might a bit painful for some, but it had to happen. People shouldn't be relying on such early proposals in production.
I've been using @babel/preset-env since early on and it's superb. You just pick what platforms you're going to target, and you're pretty much good to go.
I'd suggest being a bit weary with automatic polyfills. It's very easy to start using every new feature out there only to have your resulting bundle balloon in size. Depending on the type of project, it might sometimes be better to be explicit about which features can be used, and manually importing those polyfills so you fully understand the price that you're paying.
There will probably be some people complaining about complexity and how certain things are still confusing. Although I would agree that there's still room for improvement, targeting multiple independent platforms just seems like it's a challenging problem to solve well. My experiences with cross-compiling native apps have been fairly limited, but when I've tried it I found it far more overwhelming when compared to setting up babel. Perhaps it's just my limited experience in the native space. Am I the only one, or have others shared similar experiences? If you disagree, I'd be very interested in reading about which tools you've used, and examples of ways in which you believe babel could be simplified or improved.
This change might a bit painful for some, but it had to happen. People shouldn't be relying on such early proposals in production.
I've been using @babel/preset-env since early on and it's superb. You just pick what platforms you're going to target, and you're pretty much good to go.
I'd suggest being a bit weary with automatic polyfills. It's very easy to start using every new feature out there only to have your resulting bundle balloon in size. Depending on the type of project, it might sometimes be better to be explicit about which features can be used, and manually importing those polyfills so you fully understand the price that you're paying.
There will probably be some people complaining about complexity and how certain things are still confusing. Although I would agree that there's still room for improvement, targeting multiple independent platforms just seems like it's a challenging problem to solve well. My experiences with cross-compiling native apps have been fairly limited, but when I've tried it I found it far more overwhelming when compared to setting up babel. Perhaps it's just my limited experience in the native space. Am I the only one, or have others shared similar experiences? If you disagree, I'd be very interested in reading about which tools you've used, and examples of ways in which you believe babel could be simplified or improved.
I've been doing two targets on my most recent projects... one for ES2017+ (async support in browser), and another for legacy (IE>=9). Which wasn't too bad for some things... for one of the projects, got to be too much, and I now just do a test for async, and if it fails redirect to "/legacy.html"
What browsers support generators, but do not support await?
The polyfill for async, converts those calls to generator functions - however i'm not aware of any browsers which support generator functions, but DO NOT support async/await
The polyfill for async, converts those calls to generator functions - however i'm not aware of any browsers which support generator functions, but DO NOT support async/await
Every browser that supports generators is self/auto updating to a version that supports async. (Except maybe Safari)... in any case, that's where I decided to draw the line.
If it supports async, it stays on modern.html, otherwise it redirects to legacy.html. There's also the ability to do some server detection for what payload to deliver. It's just async support is the only feature I test for.
client test;
If it supports async, it stays on modern.html, otherwise it redirects to legacy.html. There's also the ability to do some server detection for what payload to deliver. It's just async support is the only feature I test for.
client test;
try {
eval('(function() { async _ => _; })();');
} catch (e) {
window.location.replace('/legacy.html');
}
import * as capabilities from 'browser-capabilities';
export default userAgent =>
capabilities
.browserCapabilities(userAgent)
.has('es2017');Back when Babel 7 became beta I spent an evening switching over the build at work to it. Would sometimes get a build to start failing with webpack where the require code was leaving stray references to undefined module.exports. Shuffling code about & messing with pipeline options would eventually resolve. Bit of speed up was nice. Lo, by now we've replaced Babel entirely with Typescript
I have been using the alpha, beta and rc so far on a project that's scheduled to go live before the end of the year, and @babel/preset-typescript has been a joy to use (minus can't use const enum)
Congratulations to the @babel team, this release is hard earned
Congratulations to the @babel team, this release is hard earned
Repl (https://babeljs.io/repl) seems to still be on 6.26. I wish I could select the babel version on the official online repl, just like https://flow.org/try/
In the meantime, looks like you can try out 7.0.0 here: https://babeljs.io/repl/build/7.0/
thanks for posting! I personally usually just use https://babeljs.io/repl/build/master!
Will configuration be an less esoteric?
This is the most complicated upgrade guide I've ever seen: https://babeljs.io/docs/en/v7-migration
I really hope this new version is more polished than Babel 6 was at the time of its release.
At my former company, the migration to Babel 6 was such a disaster we jokingly renamed it to «Babel Vista».
At my former company, the migration to Babel 6 was such a disaster we jokingly renamed it to «Babel Vista».
Nice to see this... been sticking with the beta/rc for about a year now. Hopefully some of the edge cases left over (especially wrt webpack) can roll over now.
Congrats Logan!
As much as I want to upgrade my projects to Babel 7, I feel that there will be only pain in that road, so... meh
It is not a COMPILER. It's a TRANSPILER. I got a bit excited for about three seconds until I read the finer print.
We're looking into using 6to5 [what Babel was called at the time] for a project at Facebook -- and although we make the library -- the project is stuck for some time on React v0.11 which used a different transform.
https://github.com/babel/babel/pull/410
Was so impressed by the turnaround time on that PR and the overall quality of the project that I contacted @sebmck to see if we can recruit him to work with us. He was interested and so I referred him to a recruiter. A day later she comes back to me: "did you know this is a 17-year-old kid in the middle-of-nowhere in Australia?" (I didn't). We had to wait until he was 18 before we made him an offer and he joined our team :)
(eventually we got all of Facebook.com to run on Babel and not just React Native https://twitter.com/amasad/status/631251607422787584)
Like Henry mentions: working on 6.0 was hard and really controversial -- our vision for Babel was to serve as compiler infrastructure for JavaScript (which we've achieved to some extent since so many tools build on top of it and most users use it as part of a bigger toolchain like webpack) but many of our users disagreed with the direction and we were at the receiving end of much vitriol from the community (including here on HN). We're now vindicated (many times over) but goes to show how OSS maintainership can not only be a thankless job, but quite a stressful one too.
Thank you Henry and the rest of the team for you dedication.