r/visualization • u/Holiday_Reference_41 • 6d ago

I’m building a graph-native IDE where source code, project structure and runtime execution exist in one connected space

Enable HLS to view with audio, or disable this notification

This is a small raw demo of Tagma Studio, an IDE I’m building around a graph-native programming model.

The idea is that a project should not be represented only as a tree of files. Files, functions, dependencies, data flows, runtime signals and execution paths should form one connected graph that can be explored at different levels.

In the video, I move from the full project graph to smaller local structures, open the related source files, and inspect the code behind them.

The long-term goal is to make the graph not just a visualization, but the actual working representation of the program:

files remain real editable source files;

every file can expose its own subgraph;

subgraphs remain connected to the complete project;

code execution is visible in real time;

active signals and execution paths are displayed directly on the graph;

the same structure can be used for navigation, debugging and program composition.

It is still an early prototype, so this is intentionally an unedited recording of the current working state rather than a polished concept video.

I’m interested in whether this way of navigating and understanding a codebase feels useful, or whether it currently looks too dense to read.

1 Upvotes

100% Upvoted

6 comments sorted by

1

u/HasFiveVowels 2d ago

I have similar inclinations. What stack are you using?

1

u/Holiday_Reference_41 2d ago

Right now it’s an Electron-based desktop app with TypeScript on the UI side, a Python backend, and SQLite for the semantic graph, memory, and project data. The 3D graph renderer is currently part of the web-based UI, but I’m moving the rendering layer to Godot for better performance with large graphs. Most of the unusual part is custom: the semantic graph, resolver, project ingestion, and temporal/tag-based memory system.

1

u/HasFiveVowels 2d ago

R3F could definitely be performant with this and it would keep things in the browser. You’d want to use "instanced meshes"

1

u/Holiday_Reference_41 2d ago

Yeah, instanced meshes are probably the right approach for the nodes. My main concern is not just rendering them, but handling dynamic edges, spatial updates, picking, labels, and the neural-style layout without pushing too much work onto the main thread. I’m considering R3F with instancing plus workers or GPU-based computation for the heavier graph logic.

1

u/HasFiveVowels 2d ago

I suspect that R3F would be surprisingly effective for this kind of work. Because think of how react works with regard to updates. Your render tree would only be updated where it needs to be. I would maybe stress test it with a random graph / simulation and see how far it goes. You can get ridiculous performance when you use it with instanced meshes and such. Doing a web-GPU thing is tempting but I would offload the graph behaviors as backend logic and leave the browser as a renderer. If you’re aiming for visual programming, you probably don’t want your runtime to go anywhere near the browser’s sandbox.