Intro Video
Dbux is an integrated debugging environment (IDbE) and omniscient debugger for JavaScript runtime analysis.
The following video:
- explains why we need better Debuggers,
- demonstrates all of Dbux's tools with plenty of examples,
- is fully timestamped (if you are impatient, we recommend taking a quick glimpse by skipping around a bunch).
On a Personal Note
I have been programming for some 20+ years, in all kinds of languages. And until recently, I could not quite figure out why sometimes even some of the easiest bugs take some 10+ minutes to find.
It was that frustration that moved me to start this project on 2019/11/16 (2+ years ago). The project has been driven by the wish to better and more intuitively understand what is going on under the hood, not only in the applications that I build myself, but also in all that third-party code that I am making such heavy use of.
At this point, I feel, this project has started providing some very good answers to those mind-boggling questions I had before. I start to feel a greater sense of clarity when confronting that "dark matter" of debugging, even when Dbux is not available.
Call to Action
If you are so inclined, please check it out, and just bombard me with any questions, complaints, any kind of feedback. I would greatly appreciate it!
References
GitHub: https://github.com/Domiii/dbux/
Documentation: https://domiii.github.io/dbux/
Discord: https://discord.gg/QKgq9ZE
Install: https://marketplace.visualstudio.com/items?itemName=Domi.dbux-code
The video briefly mentions Henry Lieberman's informal The Debugging Scandal and What to Do About It. I strongly recommend the avid reader to check that out as well.
Also: shout-out to https://www.replay.io/!
Credit
Lastly, thanks go out to Michael who has been with me from the beginning, and everyone else, who, for a brief period of time, contributed whatever they could!
Top comments (21)
Great job and good luck!
I agree it's time for back in time debuggers to make a breakthrough. Definitely with UI improvements that we can offer in this day and age. They're an amazing tool that's sadly missing from most of our tool-chests.
Thank you.
I imagine, your toolbelt already has some of the new types of debuggers in it? How do you do yours?
Right now I'm mostly focused on production debugging and teaching the existing debugging technologies.
From my experience even seasoned developers don't use 5% of what regular debuggers offer... Getting them to use even more advanced tools is a challenge. But it's doable. The educational and promotional work is extensive though.
I agree, getting people to use new tools is tough... it requires training, a new approach to thinking and problem solving and it is sometimes not worth the effort, especially when one is not aware of the datastructures underpinning runtime behavior.
I'm curious: how do you compute
5%?I'm totally guesstimating based on the people I meet and talk to. I'm not aware of good studies here.
You are mostly doing Java, right?
This paper "On the Dichotomy of Debugging Behavior Among Programmers" (2018) reporting on WatchDog 2.0 results might give you some numbers - especially Fig. 2.
Edit: You might also be interested into the Swarm Debug Infrastructure project?
Thanks!
I don't have access to that. What's on fig 2?
Woops! Here is the article link: dl.acm.org/doi/10.1145/3180155.318...
It sucks... due to antiquated licensing policies, research is generally still not open access (unless authors pay even more money). I also don't have a license to re-distribute anything here in public.
I recommend contacting (sending an email to) the authors (first author). They usually love to share. (I don't know them, if you were wondering, just thought you would definitey be interested in the article, which is one of hundreds of articles in my "related work" database.)
Edit: Nevermind - here it is - https://www.google.com/search?q=On+the+dichotomy+of+debugging+behavior+among+programmers+pdf&hl=en
Turns out my boss read it before they seed funded Lightrun... He's got the academic angle better than I do, I'm more up on the industry internals usually.
Anyway the chart looks completely disconnected from my experience in the industry. I honestly don't know many people who would know what a field watchpoint is. Very few people use exception breakpoints (at least in Java) since they don't know they can filter them (and it's off by default). Very few know about tracepoints or marker objects.
But it's really hard to research developer behavior. I'm guessing only JetBrains can give us the inner details from their analytics results.
Well, a lot of people are certainly trying... LaToza is another big name to throw out there (in addition to the names I named above) :)
But then again, at the end of the day, trying to generalize on findings of human behavior ultimately is going to be flawed...
Either way, nice talking to you, and good luck with those "antiquated tools" :P
Thanks. Great talking to you too!
That's part of why I think it's time for these tools... Back when these ideas were first floated, there was no DevRel profession. There was no developer-first culture. We now have the tools to educate the market which didn't exist even 10 years ago. There's also amazing funding for developer tools and if it's used correctly it can make a huge difference.
I might have to look at some sources of funding... I'm currently funding it all out of my own pocket...
But then again, I have a few things left to do before I can even consider taking on investment... hah...
Probably, I suggest a more business oriented partner who you trust. My employers are a couple of young guys. One is super technical and the other is more business oriented. Raised funding relatively easily. But you don't need much to raise cash in this day and age, just a bit of traction and technology that shows promise/value.
I also see other people's investment into my stuff as a form of debt, so thus far, I have been hesitant. Maybe next year, I can find a way to see it through, in a way that is not to limiting of my freedom, or risky to accept. I'd prefer something where promises are clear, realistic, time-bound, and with some flexibility...
no matter what I use, I always come back to good old 'console.log'......
I know the feeling.
Looks great. Yet, in a world divided increasingly between client side JS, server side JS (Node.js) and desktop JS (Electron) I think it worth headlining the context(s) in which Dbux can be used.
Not sure if this is what you are asking (or if you have a question to begin with), but let me try this:
I tested it on Node and in the browser. Have not tested it with electron yet. Generally speaking, it should run in most places, however it requires the target application to be
babeled. For Node applications: due to really bad source map support in earlier versions,Node@16+is strongly recommended.Thanks Domi. I guess it was an indirect sort of question, and a request, that any presentation of a JS debugger today should make clear the contexts it works in. I haven't had a chance to try Dbux yet myself, but my interest would be in client side JS primarily (as I don't do any Server side or Desktop JS development at present) and so client side I guess it's competing with the built-in debuggers (F12 in Firefox or Chrome based browsers) and I'd need to know how to invoke Dbux in that context. Is it a browser extension to install? I'd be happy to trial it some time, as I do use the client side debuggers a fair bit and am acutely aware of both their awesome power (compared with what was available a decade or two ago ;-) and their limitations. I use them for debugging my own code, and for reverse engineering other people's code. Webpack is our enemy in that latter space, because while browser debuggers have awesome pretty-printing (reformatting) options for single stepping code, Webpack tosses all the symbols (replaces everything with single letter names) making lucid reading of intent sehr difficult ;-)
But anything that makes async stack tracing easier is a blessing!
Hi Bernd,
Do you want to send me a message on Discord? Would love to personally help anyone who wants to give it a spin.
About your other points:
todomvc), if you are interested.Domi, fret not, I'm a tad short on time to experiment just now but I don't use VSCode at all really (Eclipse is my IDE of choice if you will) and in-browser would be my context of greatest interest (replacing or augmenting the default in-browser debug tools - which as I said are stunningly excellent but regular use also highlights shortcomings).
Given how commonly I encounter Webpack output which is rather obfuscated indeed (I think not with security as the driving intent mind you, I suspect it is driven by the goal of package size minimisation - when all symbols are down to one or two chars I'm sure it has a fairly hefty file size saving). It might be nice for debuggers to support on the fly refactoring (renaming of symbols) that sticks between page reloads (becomes an asset for a given .js file and could be associated with a .js file etc). Just a pipe-dream really.
Fortunately for packages I use, there is generally a .js and a .min.js version available and if I configure my site for debugging it loads the .js in preference to the .min.js to facilitate in-browser JS debugging. For thrid party web-sites that is harder to control, all the more so if they don't use a common CDN with variants, and/or it's running their own webpacked code.