These are some fundamental questions I've heard from folks when I discuss built-in modules with JavaScript developers. Have you heard these concerns, or any other concerns that aren't tracked in other issues? Do you agree with my suggested answers here? Is there more we should consider digging into here?

Q: Rather than make new libraries that are built-in, should we standardize existing libraries and put them in the platform? These meet real needs, have adoption in existing code (so speedups will come sooner) and are more ergonomic.

A: Let's figure this out on a case-by-case basis. Typical JavaScript libraries do things that we might not want to bake into the language, but we in the standards world have a lot to learn from them in terms of attractive ergonomics and practicality for direct use.

Q: Should the platform focus exclusively on low-level capabilities, rather than building a standard library? The ecosystem does best at higher-level things, being more agile and not having to worry about rollout across browsers.

A: This project has a longer timescale, so it is complementary to many ecosystem efforts. Built-in modules will be designed to be accurately polyfillable when possible, shrinking the time to become usable, and will have strong tests to ensure consistency across browsers. There's value in standardizing certain core components for reuse, for various motivations that are specific to each library being added.

Q: How will built-in modules avoid the pitfalls of previous standardization efforts, which result in poor ergonomics, not really solving developers' needs, etc.?

A: The standards processes have been improving, incorporating more developer feedback and prototyping, though we still have a way to go. Hopefully, being able to develop standard libraries in JavaScript will help get more people involved. Your ideas here are appreciated.