Anyone who has been using import in a javascript backend codebase for more than a year is probably using babel. Same for async-await. Same for typing features like TS / flow.

I just tried out node 12 in a large JS backend codebase that’s currently running on babel and it was not a good experience.


  • node 12 imports don’t work in the REPL
  • import is less compatible with require in node 12 compared to babel, and it’s harder to make them work together.

My fault, right? Shouldn’t use babel on the backend, shouldn’t use import over require, but it’s difficult to set best practices around this stuff in a language as novelty-hungry and fragmented as JS.

What babel means for standards

Who knows if this was intentional but babel has the connotation of fragmenting a language to reduce production efficiency and for my team it totally delivered.

Javascript is totally at the mercy of these trends – it has a large, slow-moving standards body, numerous targets in the wild (= browsers) that are hard to patch, and an eager transpiler community that wants to jump the gun before the standards are finalized. The standards are also pretty complex.

If tools like babel are here to stay, standards bodies need to decide how they’ll deal with toolmakers who release an early or wrong version of the standard. It’s the nature of programming languages to be fragmented, and the more the adoption the more the fragmentation, but transpilation is such a lightweight form of customization vs forking that the pace is out of control.