Consider a zoneless policy

[dyladan]

I am proposing that the instrumentations developed by the browser SIG adopt a pure zoneless policy in favor of explicit and stack context propagation.

Steps

1. Remove any implicit or explicit zone dependencies. Do not include it in any default browser bundles.
   • an implicit dependency would be any instrumentation that calls context.* API functions which assume there is an async context implementation available
2. Internally, instrumentations should manually handle explicit context
3. Instrumentations should use the synchronous StackContextManager to re-establish context at continuation boundaries. If the user has registered the zone context manager these will continue to work. It may be useful to publish a small helper library for common tasks like binding promises or event emitters.

Benefits

• Reduced bundle size
• Avoids zone.js patching and its overhead
• Explicit re-entry points make context propagation easier to reason about and debug
• Works in apps that cannot or will not include zone.js

[martinkuba]

I am in favor of removing this dependency - Zone.js is too heavy and no longer supported. I also consider tracing within a client-app code as a secondary use case.

Generating a span for fetch/xhr calls that link to backend traces does not need zone.js. But instrumentations that would want to link multiple spans inside the client code over async boundaries would still need something like zone (e.g. the user interaction instrumentation).

Are you suggesting that the helper library would be something app developers use in their own code to manually propagate context across async boundaries?