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 <a href="https://twitter.com/_paulshen/status/1346583010691321856" rel="nofollow">https://twitter.com/_paulshen/status/1346583010691321856</a><p>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.<p>Here is another iteration with a canvas where you can drag panes around. <a href="https://artifacts.bypaulshen.com/code-explorer/01/?snapshot=9feb3d1a-b41e-44e6-adff-9b522414dc0b" rel="nofollow">https://artifacts.bypaulshen.com/code-explorer/01/?snapshot=...</a> I have more ideas/iterations coming. My goal is to productionize this for real use :)
Miller columns! I have fallen in love with this UI paradigm after using them for graph-based tools. Some thoughts:<p>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).<p>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.<p>3. The header breadcrumbs are brilliant.<p>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.<p>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)
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.<p>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.<p>To be fair, I have seen much worse. At least there’s plenty of comments, and the naming is ok.
There's a text editor being developed that edits code based on nodes of its AST representation - <a href="https://github.com/kneasle/sapling" rel="nofollow">https://github.com/kneasle/sapling</a>