Scope of project?

[jenanwise]

Thanks for making tracing-wasm!

Would it be possible to something to the README about the scope of the project? Currently, it says "Leverage performance profiling with your browser tools with the tracing crate", but the library name implies something broader.

Specifically:

• is the goal to be browser-only, or anywhere that wasm is valid? (e.g. node, deno, limited environments like cloudflare workers)
• is the goal to have feature parity (where relevant) with tracing_subscriber::fmt for log lines, or just focus on performance timings?

Thank you!

[colelawrence]

Hi @jenanwise, at the moment, until someone offers to share how we could expand to support other wasm targets, we are specifically focused on the browser context.

I'm open to suggestions on how to manage / communicate the scope of this project.

[jenanwise]

console exists consistently across all targets (AFAIK). Allowing opting out of performance usage and dynamically finding the global performance object (if available) as discussed in #4 would be best. Alternatively, you could add a short note to the readme along the lines of:

Note: tracing_wasm uses the global JavaScript console and performance objects. It will not work in environments where one or both of these are not available, such as Node.js or Cloudflare Workers.

[colelawrence]

I'll look into this further, soon. I believe I understand the goal, and have an idea for how we could expose this configurability properly.

@jenanwise, do you think that we should still support timing measurements, even if we don't have access to a performance API? I suppose by allowing a customizable WASMTracingConfig::set_performance_now_fn(f: FnMut() -> usize)?

[jenanwise]

@colelawrence You'd need to allow all setting all of now, mark, and measure, right? That ends up being sort of a strange API. Ideally something like js_sys could find the global performance object (performance vs perf_hooks.performance vs null) and you could defer to that, but in the absence of such a function I would personally just implement that within tracing_wasm and keep the config surface area the same as it is.