Super job, Paul! This made me really think that the abstraction level at which we usually think about “node-and-wire” programming (typically the AST level) might not be optimal for exploring codebases. Just sort of spewing my thoughts here, but perhaps it would be better to expose different representations at different “zoom levels”: for instance, if I zoomed into a file inside the code browser, it would turn into a graphical editor, but if I zoom out, I get a text representation. Or maybe it would be more reasonable to give the user a choice of which representation they wanted to see at a particular level of abstraction. It just seems like there is no “one size fits all” representation that can encompass all levels of abstraction.
It also made me think deeper about the notion of “incrementalism”, and how we might do well to embrace some of those ideas as a community: don’t get me wrong, there are some things that you can only do by taking a “greenfield” approach to development, but I think there is so much room for improving the status quo, that even “small” changes in representation with existing languages/tools (in this case, JavaScript and the Monaco editor from VS Code) could have on the “near-term future of coding”.
I think it would be really neat to explore breaking out the “show references” functionality into separate editor windows (or “blocks”) as well, something along the lines of what Dark has done in their editor (image below).
Maybe the “find references” command could draw temporary arrows to the files in the file explorer window, or highlight open windows that contain references to the item in question.
Finally, I think this would be absolutely killer for doing collaborative code reviews/pair programming. Stellar work!