Esbuild: can you clone yourself and make a similar project for babel? :-)

[mreinstein]

@evanw this project is awesome!

I love rollup, but I'm disappointed that when I run my build process on a 2015 macbook laptop vs a 2019 desktop with 8 cores, a ton of ram, and a pci-e drive I get almost identical build times. Clearly performance and parallelism is a problem here in defacto bunder land.

All joking aside in the title, can you envision a way that babel could be used with esbuild?

[ravener]

If we get a way to register some plugins at build time we could integrate something like https://github.com/jvatic/goja-babel although it will be slower because it has to interpret JavaScript with Go.

[sarkiroka]

I think babel is evil 😁

[mreinstein]

Babel isn't evil, it's just a very complicated tool. If it weren't for babel I wouldn't be able to do a lot of things at work that I'm currently able to do.

[sarkiroka]

The browsers are slowly catching up and everyone will support everything. But we can't get rid of the babel, though most things would work without it. That's why I think it's evil. It is a great vendor lock on your code, and never drop out.
PS.: on my projects there is not need to support of IE11-, Chrome current-2, Firefox current-2, etc.

[mreinstein]

At my day job, I need to support ie11 and ie10. That's why babel is important in my workflow. If I want to use modern javascript features, it's really hard to avoid.

My build pipeline basically looks like this:

                     ┌---------------┐            ┌-----------------------┐ 
                     |               |            |                       | 
                     | bundle to es6 ├-----------▶| modern browsers use   | 
┌-------------┐      | (bundle.mjs)  |            | bundle.mjs            | 
|             ├-----▶|               |            |                       | 
| source code |      └---------------┘            └-----------------------┘ 
|             |                                                             
└---------┬---┘                                                             
          |          ┌------------------------┐   ┌------------------------┐
          |          |                        |   | ie browsers use        |
          |          | bundle to es5 (babel)  |   | bundle.js              |
          └---------▶| (bundle.js)            ├--▶|                        |
                     |                        |   |                        |
                     └------------------------┘   └------------------------┘

some day ie will become irrelevant, and I can drop the lower portion of this build pipeline.

[sarkiroka]

Sorry, I don't understand when is the moment that you can drop the dependency. Everybody say "I use just because I need to support IE" but this is a lie. It is a lie because you cannot drop babel when not need to support IE. This is a strong vendor lock

[mreinstein]

Sorry, I don't understand when is the moment that you can drop the dependency

The moment our business no longer needs to support internet explorer. (see the bottom 2 boxes in that diagram.) Today, when you visit our website, if you are _not_ using ie, there is no babel that gets used, at any point in our build process.

Everybody say "I use just because I need to support IE" but this is a lie

Avoid generalizing large groups of people. The company I work for is only using babel for ie users. Our stuff runs on every major retailer website excluding Amazon (Walmart, Costco, BestBuy, Lowes, Target, CircuitCity, and a few hundred more.)
This isn't theoretical, it is how this code runs today. We're living the dream! :)

you cannot drop babel when not need to support IE.

You have a choice in the code you develop: you can choose to use new javascript features that aren't in browers yet, or you can stick to the subset of javascript that is supported "almost everywhere".

I'll give you an example; if you don't need internet explorer support, this code today doesn't need babel:

async function main () {
   let result = await fetch('https://foo.com')
}

main()

If however you start adding fancy new javascript features that aren't supported in browsers, then yes you'd need babel or some alternative compiler. the choice is up to you; use more conservative development techniques or transpile via babel. No one is forcing you to always use the newest beta javascript capabilities. It's your choice to make! Freedom! horrible horrible freedom! :)

[marton78]

@mreinstein did you have a look at https://swc-project.github.io/ ?

[mreinstein]

@marton78 this looks super cool! Is this usable today, or is it more experimental at this point?

[evanw]

can you clone yourself and make a similar project for babel?

I'm not planning on expanding the scope of this project to include everything that Babel does. I'm also not planning to start another similar project to Babel myself.

can you envision a way that babel could be used with esbuild?

Good question. As others have said above, sometimes there is still legitimate need for running your JavaScript code in ancient browsers such as IE. In that case, I could see using Babel (or swc) as a post-process on the output of esbuild to create a special bundle meant just for older browsers.

[evanw]

I'm going to close this because my answer above got a 👍, so it looks like I answered the original question.