4 ms·
Show HN: A Satellite View for Python Code
Hi HN,
I built ast-visualizer.com because I wanted a way to visualize the architecture/structure of a Python repo before dived into the code.
Most tools tell you what the code does; I wanted to see how it's built.
The Problem: Onboarding onto a large codebase is a nightmare. LLMs help with single functions, but they struggle to show you the "God Objects," circular dependencies, or high-complexity hotspots across 50+ files.
What it does:
Dependency Graph: Visualizes imports and file complexity to find architectural bottlenecks.
Radial AST Heatmaps: Maps individual files and color-codes them by Cyclomatic Complexity (McCabe). If a node is red, the section of code is a refactoring candidate.
Complexity Dashboard: High-level metrics like nesting depth and maintainability scores as well as files recommended to be refactored.
Privacy & Security (The Big One): I know how sensitive source code is. We do not store your code. Files are processed in (RAM) on our servers and discarded immediately after the visualization is generated. No permanent storage, no databases of your source, and zero training on your data.
Early Adopter Offer: I’m looking for feedback from the community to improve the UI and parsing. I’ve opened an Early Adopter tier that enables all features (including repo-wide analysis) completely free in exchange for your honest feedback.
Let me know: What’s the one thing you wish you could "see" visually when you open a new repository for the first time?
- treeliker 8mo agoA few technical details for those interested in the behind the scenes: Why AST? -> Simple regex or string parsing fails as soon as you hit complex decorators or nested classes. By using Python’s native AST module, we can get an objective map of the logic flow that doesn't care about formatting or comments. The Visualization Challenge-> Rendering a dependency graph for a repo with hundreds of files can quickly turn into a laggy hairball. We spent a lot of time tweaking the D3.js force-directed graph parameters to ensure that nodes self-organize in a way that highlights clusters rather than just creating a mess. Why Server-side? -> We chose server-side processing to handle larger repositories without crashing the user's browser (Numpy, FastAPI etc.), but we've architected it to be non permanent. The code lives in RAM just long enough to be parsed into a JSON structure for the frontend, then it's gone. Next steps: -> I’m looking into adding Javascript, html and css support to make debugging the frontend much easier.
- swupel 8mo agoAre you also planning on adding GO support anytime soon?
- codeviewer 8mo agoWould definitely be cool. Especially interesting for getting into large full stack codebases
- codeviewer 8mo agoHow much load does the render engine put on the user end?
- treeliker 8mo agoFor big projects its quite noticable.. but this only really starts to become a probleme once project sizes exceed 200k LOC
- codeviewer 8mo agoMy poor 2018 Mac is currently dead at around 10 FPS on numpy. Desktop works fine tho
- s_u_d_o 8mo agoHey, cool project! I saw you are planning to add javascript/html/css support soon. This will still work for React based frontends right? Or support will be for vanilla codebases only? Thx!
- treeliker 8mo agoCurrently aiming to make it work for react, especially spotting how components relate to each other would be extremly helpful when dealing with local vs global css conflicts and similar issues
- adityashukla_ 8mo agoWhile parsing, you might have considered tree-sitter which supports multiple languages, any particular reasons you didn't choose that?
- treeliker 8mo agoThis started out as a passion project so funnily enough our spaghetti code detector has quite some technical debt itself. But I have a dev branch where I am trying to get tree-sitter to work. As its ecosystem is an absolute beast when it comes to the amount of languages it supports this would definetly be my preferred method over doing all the languages manually. The main challenge is normalizing the Trees and making sure all nodes are in a comparable state when we visualize them. (otherwise vsiualizing multilingual Codebases would be a real Pain)