Yes, it sure is great that you never have to profile performance, trace call stacks, or find out where your heap is going in native app development.

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.

For native front-ends most of that work has been done for me already though. I can't remember the last time I've had to worry about performance profiling or heap management in a native front-end - and we build iOS, Android and Windows apps that process huge amounts of (medical) data. Hell, I don't even have to make my own animations to have good looking apps because that's all built into the rich native components that I use.

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.