The screenshot above demonstrates several of Dbux's features, including:
- Left: omni-directional navigation, values, executions and data flow.
- Middle: code decorations and trace selection.
- Right: asynchronous call graph.
Furthermore, this (slightly outdated) video [20 min] explains how Dbux came to be and shows two basic examples of how to use a subset of its features.
I (Dominik) started this project on 11/16/2019 because I felt that after programming/designing software, and debugging for 20 years, I have not fully mastered my craft. This became particularly apparent during problem solving sessions with clients, when I'm rather, or at least quite, unfamiliar with the code. Being stuck for 30 minutes or longer to locate a single bug was not a rare occasion. I felt like I was lacking something, lacking an approach, lacking strategy, and also lacking a sufficiently deep understanding of the semantics of the program at hand. It was this frustration that lead me on the journey to build Dbux.
I started to realize that I wanted to be able to answer (seemingly always the same type of) questions, like: How did THAT happen? Where did THAT data come from? Where did the execution take THAT turn?
I wanted to be able to more easily see (not just guess/assume/theorize/conjecture/suppose/opine/test/prod/verify) what is going on. I wanted to interact more with the runtime structure, not just indirectly through print statements, or one single small step at a time. I wanted to see the whole thing, zoom in and out, whenever necessary be able to zoom in real close, and then interact with it in order to investigate some of the non-obvious connections from where I am to where the bug is.
The goal was clear: collect all relevant run-time data, record it and make it easily accessible. And thus, Dbux was born.
We (Dominik and Michael) believe that Dbux does NOT make someone good at debugging. However, it can help better see (and appreciate?) what is going on in our applications by revealing the hidden structures beneath it. What you do with that information, is up to you! Luckily, it is (speaking from a rather biased position) kinda fun to interact with Dbux to poke around the actual recorded behavior of the code, navigating along the connections, and uncovering interesting little insights into what is actually going on in our applications. It is at least more fun (or so we feel) than just staring at the code guessing, more fun than adding/removing print/console statements, and more fun than waiting for the debugging session to re-start for the 5th time, after overshooting a crucial line of code yet again.
- Dbux's global view lists third-party modules, files and console log events. Takes user to the relevant code in a single click.
- Trace selection and the Trace Details view allow overviewing and investigating all executions of any piece of code and their respective values.
- Instead of only a call stack, Dbux presents us with the entire call graph.
- A complete asynchronous call stack is also available.
- Instead of using the traditional debugger as a "magnifying glass" to slowly crawl along the execution timeline, Dbux offers random-access navigation, in both directions of the timeline.
- Code decorations can make it a lot more obvious what code executed at all, and how.
- Executed files, functions and values can be searched for/through (culls a lot of noise when compared to code-based search).
- Data flow analysis allows us to quickly trace the reads, writes and creation of a selected value. This can also take us to the place of creation of a value in a single click.
Word of Caution: ALPHA Phase!
Dbux is currently still in ALPHA. While we have been testing it on many small samples and several real-world projects, there is always a chance, that the next one does not exactly work the way it should. For example, tracing the internals of
react is currently (01/2022) bugged.
If you run into any problems when using Dbux, please let us know.