Intro Video
Dbux is an integrated debugging environment (IDbE) and omniscient debugger for JavaScript runtime analysis.
The following v...
For further actions, you may consider blocking this person and/or reporting abuse
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?
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.