I'm so happy that I get to do mostly native apps. Building a good UI is hard enough without having to shoe-horn HTML into doing things it was never intended to do.
Did people voting up this comment just not read the linked docs, or do you maybe not have the context to understand what this library does?
It instruments your code so you can get call stack traces with timing information associated. Unless your calls into the DOM are blocking, they aren't going to show up there (that's what the browser dev tools are for). There's a reason that the only HTML element explicitly mentioned in the docs is the canvas element. It even says, explicitly, "Though it's certainly useful to see the ways your application is interacting with the browser and vice versa, often there is much more work occurring within your call trees than not."
This has almost nothing to do with HTML. It's a profiling tool for a garbage-collected scripting language, and it looks more than a little useful.
On native platforms - if I stick to standard, well-known, stable components and if I follow good coding practices and recommended techniques - my apps are fast by default. And I'm just gluing things together most of the time. Easy, scrumptious pie! I can save the work of "squeezing every drop of performance out of my code" for back-end processes.
Things just work for the most part - unlike the web where half the sites that try to do something "fancy" like fixed elements just serve to make scrolling slow and clunky - hence the need for this tool.