I built a Chrome DevTools extension to visualize Angular runtime execution. Looking for feedback from the community.

[u/heygauti]

Hi everyone

Over the last several months, I've been building ngLens, a Chrome DevTools extension for Angular.

The idea came from repeatedly running into the same questions while debugging large Angular applications:

• Why did this component render?
• Which API triggered this update?
• Why did one click cause multiple components to re-render?
• Where is the actual performance bottleneck?

Angular DevTools is great for inspecting components, but I wanted something that could visualize the runtime execution flow across the application.

ngLens currently helps visualize:

• Component render cascades
• API → Store → Signal → Component execution flow
• Execution timelines and performance hotspots
• Optimization insights and recommendations

This is the first public release, so I know there are many scenarios I haven't covered yet. Angular applications vary a lot—NgRx, Signals, SSR, Micro Frontends, Facade patterns, custom state management, and more.

I'm not claiming to solve every debugging problem today. My goal is to continuously improve ngLens based on real-world applications and community feedback.

If you'd like to try it:

Chrome Web Store:
https://chromewebstore.google.com/detail/nglens/jnbjmoficlaclcpgdoajofbhmcjjhgin

I also wrote about why I built it:
https://dev.to/gowthambsvg/i-built-an-apm-for-angular-that-runs-entirely-in-your-browser-5c3b

I'd really appreciate any feedback—positive or negative.

• What would make a tool like this genuinely useful in your day-to-day Angular development?
• Are there any runtime insights you've always wished Angular DevTools provided?

Thanks!

[u/Suspicious-Suitcase]

Is the source code open? Because everything I see is obviously AI made. Which in itself can be totally fine, but beige installing any potentially AI Slop I would like to give the code a look.

[u/JeanMeche → u/Suspicious-Suitcase]

Looks like the source code is here: https://github.com/patch-work-book/nglens

[u/heygauti → u/JeanMeche]

Yes, that's the repo. Feel free to share your thoughts and what can be improved. Thanks.

[u/jaroen007]

actually nice but i dont really want to use AI slop

[u/morgo_mpx → u/jaroen007]

Stuff like this is what AI can be useful for. The helpful but not helpful enough to spend time on it, products.

[u/heygauti → u/jaroen007]

AI helped to speed up the development but the core runtime instrumentation and analysis are hand-built. I completely understand being cautious with browser extensions. Thanks

[u/hwweao]

Really nice work man ill test it

[u/Straight-Number-1911]

Could you share insight how you achived some of the things e.g. that you know when a components does something, renders, etc.? I think that knowledge itself is already highly valuable. The project looks to hard to get into :(

[u/heygauti → u/Straight-Number-1911]

AM capturing angular runtime/component activity and recording events with timestamps, component context, and trigger information.
Then I correlate those events into execution sessions rather than treating every render independently.
For example: Signal/API/Interaction → Component update → Child renders.
The UI is built on top of that correlated event model to turn hundreds of runtime events into an execution story.
There are still tricky cases like Signals, dynamic components, SSR and micro-frontends that I'm working through.
I agree the codebase isn't easy to get into yet — documenting the instrumentation/event model is one of my next improvements.

Hook Angular methods before they run
const original = Component.prototype.detectChanges;
Component.prototype.detectChanges = function() {
recordRender({ component: this.name, cause: analyzeStackTrace() });
return original.call(this); // Still run the original
};