Debugging Node with Editors

[00:00:00]
>> Mike North: Debugging Node with editors. It turns out that this is bad. We as JavaScript developers, as web developers, we have learned to tolerate a pretty miserable experience.
>> Mike North: If you work with people who have been back end developers or game developers and they start to move towards the web, all of this context switching that we're so used to, this is really horrifying.

[00:00:24]
And it hurts our productivity and it means that we have to learn like seven or eight different tools as supposed to like one or two. And we've been trying for a while to consolidate around a single tool, so here's a little showcase. This is NetBeans which I used a long time ago, and I used it a lot and actually developed on their platform.

[00:00:49]
But they had an embedded little browser here with sort of an elements tree and sort of looks like a browser. But it was never really standards compliant, really, really basic. There was very limited support for debugging. But the benefit here was you're in one environment and you don't have to have two windows open with a multi-monitor setup.

[00:01:13]
It is one workspace that sort of works. So, never really took off. So this is the flip side. This is Chrome adding features to try to make their dev tools look more like an editor. So we've got like syntax highlighting and different themes and now you can drop folders into your sources, folder in dev tools.

[00:01:40]
But frankly, I do not expect these like subset of browser functionality, dev tools, to become the place where we're all writing our code. If there is a single destination to do this kind of stuff, I doubt it's going to be in the bottom 50% of your browser Windows, right?

[00:02:01]
>> Mike North: So this is interesting. This was a pretty promising step forward and I learned about this the first time I started working with the Visual Studio code team. I was up at Microsoft, they have developer days once in a while. And they just survey the open source community about what features are you interested, where should we deploy our resources?

[00:02:22]
They even had exercises where they gave us like points to spend. And we 'd go up on walls and say, debugging web applications. And I've heard a bunch of points in automated testing around like Cordova style apps where it's not just the JavaScript that's being tested. Test the whole app.

[00:02:41]
And they were working on this simultaneously to Visual Studio code, just trying to chase down some way to get a good solution here.
>> Mike North: It worked. It was incredibly difficult to set up. It is clearly a hack, right? Because everything here it is,
>> Mike North: In our JavaScript call stack we've got lines, line numbers starting one, two, three.

[00:03:07]
Line two is the buttons. This is all text with a little bit of decoration around it, trying to simulate a UI using Unicode characters to try to create rounded button corners and things like that. And what's more, the step-in-step-over, that's all built into this omni-box, the single drop down that drives Sublime.

[00:03:29]
So that they managed to implement everything that's necessary for this protocol to work but it was brittle, really, really, hard to set up, and the contributors to this effort had to know Perl and JavaScript and browser internals really well. And so you're starting to approach a really, really small subset of developers that can maintain this kind of thing.

[00:03:54]
>> Mike North: So yeah, this was cool. It didn't really work incredibly well but it was a very promising step to take. So here, this is a world's better than other approaches we've just looked at. This is Adam, with some plugins, and you can see, we have real buttons there.

[00:04:15]
Break points are obvious, we have proper UI for call stacks and things. This is not like an editor tab that we're trying to squeeze a call stack into. This is starting to look right. However, you'll note that like this is still very basic. This is step in, step out, step forward and stop.

[00:04:35]
And over time more advanced debugging functionality is being added. And so you may be able to get the basics right, but this is not a theme. This is not add Spotify to your editor so that you can change which track your listening to. And by the way, I love those extensions, they're fantastic.

[00:04:57]
>> Mike North: But you want something like this to be handled by a really dedicated team that is committed to comprehensively solving this problem. And that's where you want the following things to be handled properly. Source maps are really hard to get right. For really smart people it is hard to get source maps right.

[00:05:19]
They're broken all over the place. They're broken in Ember and in React. And I don't mean for the basic Hello World cases, but you can do things that will just make it so you're in this familiar situation that I can guarantee everyone in here who's tried to debug stuff in a real app you set a break point and then you look at your dev tools.

[00:05:45]
And it thinks you're on the last line of this file which is an empty line and there's no code there. But clearly there's something there. If you start logging stuff in the console you're not where it thinks you are. So source maps can break. Advance debugging features, we're gonna look at something we can do in Node which is amazing, where you can like pick a stack frame and restart execution at the top of that stock frame again.

[00:06:11]
So this is something that only node can do. Chakra, which is the JavaScript runtime for Edge, it's another Microsoft project, there they have something called time travel debugging. So that's another ability to go backwards and to see what happened earlier. I overshot, take me a few steps back.

[00:06:33]
And anyone who's ever overshot a problem where you find your break point, or you say stop on all exceptions and then you find you're in an error, and getting back upstream to where that error was thrown is really difficult. So, handling asynchrony is hard. Finding that you're in an error that happened because some random promise failed, particularly, I work on a bunch of Ember apps where we have something called the Ember run loop.

[00:07:01]
I have not worked with fibers enough in this new version of React but it's another scheduling idea. And without handling asynchronous call stacks well, where you're not just saying, what happened? Let's trace this back to our roots. It's a function that was passed to set time at zero.

[00:07:18]
That is not useful information. You wanna know, well, what scheduled that task? What was the async thing that led to another async thing, that finally led to this blowing up? And I would not trust a community-sourced debugger to handle all of the important cases there. And then, finally, multiple threads and multiple debugging sessions.

[00:07:41]
So that was something Sublime could never do, where you'd say, I've got a web worker or I've got a service worker. More than one thread going on, I've got break points. Do we wanna freeze them all at once or do we want to just freeze one thread and let the rest of them run?

[00:07:56]
There are good uses for both of those ideas, but you need to be able to handle that properly. And then finally, multiple debugging sessions. I've never seen that handled right. And we're gonna do that today where we've basically got Node and Chrome, and we wanna be able to, within the same environment, transition from one to the other pretty seamlessly.