It's generic enough for JavaScript/TypeScript codebases. Under the hood, it's using TypeScript's language server which conveniently runs in the browser. Other languages would require running the respective language service elsewhere or caching the results (ala LSIF https://lsif.dev/)
I've been thinking about how we can make devtools smarter and more fun to use. We write code with text but programs contain a lot of structure that we can take advantage of! If you're on mobile, you can find a video here https://twitter.com/_paulshen/status/1346583010691321856
This demo is an iteration of my code browser exploration where jump to definition always opens in a column to the right. I use TypeScript's language server to get the program's semantics which allows features such as showing only the item (eg function) that you're jumping to.
One thing I noticed is that Cmd-Clicking a variable only shows where it was defined. I think it would be pretty useful if you could also see the places it was changed.
That spatial canvas organization is the closest thing I've ever seen to my dream coding space.
The 1-dimensionality of a linear string of code always seemed like it ignored so much of the brain's processing abilities. I first noticed this when playing real time strategy games – I would always have a 2D mental model of where all my infrastructure was, my troops, various battles, etc. It was easy to keep track of, despite the complexity.
I suspect many (most) programmers also have a rich mental model of their codebase, instantiated by reading and jumping around these mostly linear streams of text (our brains "fold" linear code like amino-acid sequences fold into 3d protein shapes). Mapping between mind-space and editor-space takes a lot of work, and is the source of many many bugs.
Being able to map my higher dimensional space to a richer coding space – to group related functions and objects together, and maybe draw some boxes around them, or toggle various layers of meta-information (such as connections, code paths, etc.) would be amazing.
Strongly agreed. I wanted to have this ever since I saw the video of "Code Bubbles" some decade ago.
The problem with how we currently develop is, IMO, low control over screen space. We have files, which are strongly linearized. We can open more than one file side by side. Most tools provide some way to jump across references. Some tools provide these as inline inserts ("popouts"), instead of opening more files. But still, for any given thing you're focused on, most of the file you have on your screen is likely unrelated.
I'd love to see an experiment around such code bubbles, but taken to further extremes. Make it easier to pop up bubbles with a single function, that can optionally be expanded to cover more - and also, importantly, shrunk down to cover less. Let me see and retain the graph of connections on the screen. And edit code directly in these bubbles. All on a densely packed, 2D slate, scrollable in both dimensions and fully navigable with a keyboard.
> I'd love to see an experiment around such code bubbles, but taken to further extremes. Make it easier to pop up bubbles with a single function, that can optionally be expanded to cover more - and also, importantly, shrunk down to cover less. Let me see and retain the graph of connections on the screen.
I also want the same for web sites.
With the old Firefox extension API that should have been doable.
Thanks! I wonder why spatial organizations haven't caught on in programming. Maybe the extra degrees of control have more costs than benefits? With rigid tiling, it's easier to switch between panes, layout, etc..
What I want to explore is creating multiple views for the connections you care about. I imagine that would benefit from richer visualization than a list of text. like the ones you mention!
I’ve been dreaming of organizing code in two dimensions too. Maybe even three dimensions. But at least two. My own thinking is that perhaps with higher resolutions like we have now, and very wide screen monitors becoming popular, more people might start to look into organizing code in more spatial dimensions.
Your paned approach is very interesting. Seems more tidy than purely graphical node-based programming.
Now I am wondering if your approach could also lend itself to debugging code. Where you’d step through the code and each time you step into a function in the debugger it would open a pane with the code of the function to the right. And same for breakpoints so if you ran your code to a breakpoint then it would show each function in a pane organized horizontally corresponding to the stack trace at the point where execution was stopped.
please consider accessibility to nojs users, perhaps by sharing plaintext website or screenshots.
i am using device where enabling js is not an option, and feel left out by current presentation.
good luck to you in your work, sounds very exciting!
twitter recently changed their accessibility policy to not allow nojs clients at all, whereas before one only had to click through a dialog each tweet.
I think maybe Facebook should stop asking for complicated algorithms questions in their interviews, and instead ask to debug code like this with 7 indentation levels per function and behavior affected by a dozen flags.
The tool is nice, but it would have been better if the code was more readable in the first place, such that any editor would have sufficed.
To be fair, I have seen much worse. At least there’s plenty of comments, and the naming is ok.
Miller columns! I have fallen in love with this UI paradigm after using them for graph-based tools. Some thoughts:
1. Once you open multiple panes from the same column, and go out to 2+ levels deep, it quickly becomes unclear which panes followed from which. There is an underlying tree structure that you are hiding from the user. Explicitly surfacing this tree somehow could greatly increase the usability of the tool. At the moment, opening two reference panes from the same parent column immediately becomes difficult to manage. Some ideas: clicking on a reference pane should highlight the code pane that it is associated with, something similar for code panes might also be appropriate. Highlighting up- and down-stream dependencies would make it much clearer what panes I'm about to delete by deleting a given pane (the user can drag a pane to a different column in order to "disconnect" it and keep it around).
2. If I delete a pane from a column, its descendants stay open, making it even more confusing why I had them open in the first place.
3. The header breadcrumbs are brilliant.
4. You have two types of panes: reference panes and code panes. I'm not sure that's a good idea, since a reference pane is tightly tied to the code pane it came from. It may make more sense to show references in code pane itself, and then let me follow references from there into the next column.
5. I'm on a Mac with a trackpad, which makes horizontal scrolling very very easy. This is not true for all your users. It might make sense to add thin left/right buttons so that I can quickly move a column at a time. At the very least: if I open a new column, the window should scroll to make it visible if it is about to be cut off. Since users screens will most likely be able to handle at least two columns, this shouldn't be too jarring (as long as you use a smooth scroll! quick but clear, 100-200ms)
> There is an underlying tree structure that you are hiding from the user.
There shouldn't be, though. You're following a graph structure of cross-references, in both directions (though it's less obvious here how to open panes for back references). It's not a tree.
> If I delete a pane from a column, its descendants stay open, making it even more confusing why I had them open in the first place.
Again, not a tree. Deleting panes opened from the pane you're deleting would be a bad thing, because some panes may be just intermediaries you used to find the semantic units you were interested in.
The GUI here is similar to Miller columns, but it's not actually Miller columns - it doesn't represent a tree.
> You're following a graph structure of cross-references
Yeah, that's tree-like. I've worked on a similar problem, giving users the tools they need to explore extremely large, dense connected graphs. When you go-to-definition, then show-references, then go to a usage from the first file, you don't go back. You continue forward to the next column, even though the fourth column is identical to the first. The columnar navigation guides you towards tree-like exploration, which is necessary because the actual web of relationships is impossible to effectively visualize all at once. Trees make it manageable.
> some panes may be just intermediaries you used to find the semantic units you were interested in.
That's true, which is why dragging panes is important. You can explore down a path, find the pane you're interested in, drag it over to the second column, then delete the cruft in one step. The problem with it now is that once you find the pane you like, you have to go back and manually delete every single node that you don't care about.
Good feedback. Thank you! This iteration explores my question that while navigation history is a tree, what do people want on the screen at the same time? Personally, I find myself usually wanting 2-3 units of information on the screen (most often, a caller and callee). That's why panes are draggable from one column to another. The navigation is semantic but the panes are unopinionated.
26 comments
[ 4.0 ms ] story [ 70.6 ms ] threadThis demo is an iteration of my code browser exploration where jump to definition always opens in a column to the right. I use TypeScript's language server to get the program's semantics which allows features such as showing only the item (eg function) that you're jumping to.
Here is another iteration with a canvas where you can drag panes around. https://artifacts.bypaulshen.com/code-explorer/01/?snapshot=... I have more ideas/iterations coming. My goal is to productionize this for real use :)
One thing I noticed is that Cmd-Clicking a variable only shows where it was defined. I think it would be pretty useful if you could also see the places it was changed.
But agreed. Would be a nice feature for the cases where this can not be avoided.
I suspect many (most) programmers also have a rich mental model of their codebase, instantiated by reading and jumping around these mostly linear streams of text (our brains "fold" linear code like amino-acid sequences fold into 3d protein shapes). Mapping between mind-space and editor-space takes a lot of work, and is the source of many many bugs.
Being able to map my higher dimensional space to a richer coding space – to group related functions and objects together, and maybe draw some boxes around them, or toggle various layers of meta-information (such as connections, code paths, etc.) would be amazing.
Please keep doing this.
The problem with how we currently develop is, IMO, low control over screen space. We have files, which are strongly linearized. We can open more than one file side by side. Most tools provide some way to jump across references. Some tools provide these as inline inserts ("popouts"), instead of opening more files. But still, for any given thing you're focused on, most of the file you have on your screen is likely unrelated.
I'd love to see an experiment around such code bubbles, but taken to further extremes. Make it easier to pop up bubbles with a single function, that can optionally be expanded to cover more - and also, importantly, shrunk down to cover less. Let me see and retain the graph of connections on the screen. And edit code directly in these bubbles. All on a densely packed, 2D slate, scrollable in both dimensions and fully navigable with a keyboard.
I also want the same for web sites.
With the old Firefox extension API that should have been doable.
(I caught myself considering Palemoon yesterday.)
Here's an image of one of my darklang projects https://twitter.com/_paulshen/status/1321872376234082305/pho... My conclusion was that it's an interesting experience but needs refinement for "power usage".
What I want to explore is creating multiple views for the connections you care about. I imagine that would benefit from richer visualization than a list of text. like the ones you mention!
Your paned approach is very interesting. Seems more tidy than purely graphical node-based programming.
Now I am wondering if your approach could also lend itself to debugging code. Where you’d step through the code and each time you step into a function in the debugger it would open a pane with the code of the function to the right. And same for breakpoints so if you ran your code to a breakpoint then it would show each function in a pane organized horizontally corresponding to the stack trace at the point where execution was stopped.
please consider accessibility to nojs users, perhaps by sharing plaintext website or screenshots.
i am using device where enabling js is not an option, and feel left out by current presentation.
good luck to you in your work, sounds very exciting!
twitter recently changed their accessibility policy to not allow nojs clients at all, whereas before one only had to click through a dialog each tweet.
Or setting your user agent to Googlebot/2.1 for Twitter should work as well[1].
[1]: https://raw.githubusercontent.com/tats/w3m/master/doc/README...
The tool is nice, but it would have been better if the code was more readable in the first place, such that any editor would have sufficed.
To be fair, I have seen much worse. At least there’s plenty of comments, and the naming is ok.
1. Once you open multiple panes from the same column, and go out to 2+ levels deep, it quickly becomes unclear which panes followed from which. There is an underlying tree structure that you are hiding from the user. Explicitly surfacing this tree somehow could greatly increase the usability of the tool. At the moment, opening two reference panes from the same parent column immediately becomes difficult to manage. Some ideas: clicking on a reference pane should highlight the code pane that it is associated with, something similar for code panes might also be appropriate. Highlighting up- and down-stream dependencies would make it much clearer what panes I'm about to delete by deleting a given pane (the user can drag a pane to a different column in order to "disconnect" it and keep it around).
2. If I delete a pane from a column, its descendants stay open, making it even more confusing why I had them open in the first place.
3. The header breadcrumbs are brilliant.
4. You have two types of panes: reference panes and code panes. I'm not sure that's a good idea, since a reference pane is tightly tied to the code pane it came from. It may make more sense to show references in code pane itself, and then let me follow references from there into the next column.
5. I'm on a Mac with a trackpad, which makes horizontal scrolling very very easy. This is not true for all your users. It might make sense to add thin left/right buttons so that I can quickly move a column at a time. At the very least: if I open a new column, the window should scroll to make it visible if it is about to be cut off. Since users screens will most likely be able to handle at least two columns, this shouldn't be too jarring (as long as you use a smooth scroll! quick but clear, 100-200ms)
There shouldn't be, though. You're following a graph structure of cross-references, in both directions (though it's less obvious here how to open panes for back references). It's not a tree.
> If I delete a pane from a column, its descendants stay open, making it even more confusing why I had them open in the first place.
Again, not a tree. Deleting panes opened from the pane you're deleting would be a bad thing, because some panes may be just intermediaries you used to find the semantic units you were interested in.
The GUI here is similar to Miller columns, but it's not actually Miller columns - it doesn't represent a tree.
Yeah, that's tree-like. I've worked on a similar problem, giving users the tools they need to explore extremely large, dense connected graphs. When you go-to-definition, then show-references, then go to a usage from the first file, you don't go back. You continue forward to the next column, even though the fourth column is identical to the first. The columnar navigation guides you towards tree-like exploration, which is necessary because the actual web of relationships is impossible to effectively visualize all at once. Trees make it manageable.
> some panes may be just intermediaries you used to find the semantic units you were interested in.
That's true, which is why dragging panes is important. You can explore down a path, find the pane you're interested in, drag it over to the second column, then delete the cruft in one step. The problem with it now is that once you find the pane you like, you have to go back and manually delete every single node that you don't care about.
Iteration 01 https://artifacts.bypaulshen.com/code-explorer/01/?snapshot=... implements exactly what you suggest with showing connections. Closing a pane will recursively close children. Also references are tied to the pane (point 4)
5. yes! I'm going through iterations of exploration but will consider these important points when/if productionizing.