Closure --> esbuild/babel/terser/tsc

This I2I is to spark the discussion on whether we'd like to migrate off of Closure for production builds, as well as move off of its type system. While technically both the compilation and type checking aspects of this I2I could be pursued separately, I don't believe it would make sense to do that. For example, using TS types while compiling with Closure means that as time goes on Closure will slowly become less and less efficient as it understands less of our typing.

POCs for the migration

• 🚀 🚀 esbuild for production builds 🚀 🚀  #35201
• Migrate check-types from closure to tsc #35243

Related I2I on using TS in AMP: #13791

Motivation

DevEx:

• We can significantly reduce build times for prod builds. For example, in my current PR prod builds goes from 12m --> 7.5m (with further low hanging fruit).
• We can take advantage of the much more powerful (and pleasant to use) TS type system in new code.
• We could seamlessly start writing Bento components with TS markup.

Community alignment:

• Most OSS projects do not use Closure -- and instead choose alternatives. Using its API is not easy, and we've written thousands of LOC to make it work.

Cons:

• Bundle size: Currently, even with prop mangling turned on, the terser output is still ~2kb larger for v0.mjs. Hopefully we can further close the gap, but a bigger bundle size is directly at odds with our project policy of prioritizing end user over developer.
• Project stability: We are confident in Closure's stability and staying power (Google is heavily invested in it). We can't be sure of this with a new project like esbuild maintained by an individual.

Alternative Solutions

Do nothing.

Launch Tracker

No response

Notifications

/cc @ampproject/wg-approvers @ampproject/wg-performance @ampproject/wg-infra