Nicolò Ribaudo

CommonJS has been the go-to module system for Node.js for more than a decade, but the ecosystem is slowly moving to ECMAScript Modules. CommonJS and ESM have different features, and they are not fully compatible with each other: should existing libraries migrate to ESM? Should they keep using ESM forever? Are JavaScript tools ready for native ESM? Babel is one of the most used packages on npm, and we have been slowly working to move away from CommonJS. What obstacles have we found? How did we overcome them? What have we learned in the process? How do we ensure a smooth transition for our users?

For decades, JavaScript developers have relied on a multitude of module systems to organize and share code. But in 2015, ECMAScript finally introduced built-in standard semantics for modules, providing a long-awaited solution for the language. While ECMAScript modules have quickly become a popular format for writing code, most published code is still compiled to a single bundle or to a legacy module system. The TC39 committee, which designs the ECMAScript language, is actively exploring this design space: are there any missing functionalities compared to previous systems? Do JavaScript developers need any capabilities that the language does not currently provide? What problems do ECMAScript modules currently cause? This talk will walk you through the answers to those questions and show you current developments, giving a sneak peek at possible future modules features!

Immutability and deep equality. Two keywords that were initially relegated to strict functional programming environments, but have been popularized across the JavaScript community thanks to libraries like Immutable.js, Immer and React. 'Records & Tuples' is a new ECMAScript proposal that brings two new immutable primitives to the language: what do they look like, what capabilities do they bring, and when will you finally be able to use them?

Development is a creative act. However, we spend a lot of time cleaning up our code, refactoring and doing other repetitive tasks. What if we could automate it? This talk will show an alternative way of using Babel: usually, everyone thinks about it as a modern-to-old ECMAScript compiler, which also supports a few additional syntaxes like JSX or types. But what if it wasn't just that? Babel is a general-purpose ECMAScript code analyzer and transformer. It could be used to create linters, minifiers, static analysis in IDEs, or... codemods! How can we leverage the Babel APIs to efficiently refactor hundreds of files, without manually doing the same thing over and over?

More and more developers are using Babel in their build process, but do you know how it internally works? We will first briefly discuss the different parts that compose a JavaScript to JavaScript compiler, and how it tries to reduce the complexity of implementing a custom code transformer: it's not just a search & replace based on regular expressions! Then, we will learn how Babel implements support for new ECMAScript proposals, by going through a plugin which will transform future syntax to old ECMAScript. In order to code it correctly, we will need to understand the proposed semantics, and we will discuss the trade-offs between specification compliance and output complexity.