Review of the second half of Philip Roberts' talk What the heck is the event loop, anyway?
Okay, got back to the video :) <3 the tool! We need more stuff like this, Hoping to make something similar for Ruby. At one point I got as far as drawing it, but then wound up rewriting it a few times. Hoping to get to visualizing again. Also know of an instructor at Dev Bootcamp who has explored ideas like this (link). I'd really like to see our communities learn to heavily value discoverable (especially visual) models like your tool gives.
Best part was "writing a tool which can visualize the javascript runtime at runtime", keep that line, I got more excited about it than about keynote burning down, b/c I thought that was a joke, but when you said this, I realized what was happening and how epic it was!
2 improvements:
- Really hammer in why the event loop is necessary. I think it got an example and a sentence, but the inflections need to slap me in the face. I've found students are eager to identify things they can ignore. Been interrupted an hour into essentially this talk for Ruby by the question "Okay, but do I really need this? When will I use it". The student knew enough to write a program that did what we assigned, but didn't realize the depth of their ignorance, or how it crippled their ability to find solutions or reason about code they'd never seen before. I, of course, berated them to tears and sent them home to set an example, lest the other students shirk such valuable knowledge. But if I'd sold it better, they wouldn't be spending brainpower evaluating whether they could ignore it, but would rather be eager and imaginative with the material, envisioning what they could do with this new knowledge, and having epiphanies about all the code that previously befuddled them, that they could now reason about. Your talk would probably benefit from the same thing mine would: really make them realize there is a gap in their knowledge and they can't figure out what is happening or why, with the current model of just the stack. Probably that's vocal inflections, maybe also offering several possible explanations, each of which seems reasonable, but has different implications. That might pique their curiosity and thus their engagement, while also allowing them to see that it affects what code they would write, and explains things that will eventually trip them up (I once put an infinite loop in my JS code to wait for the web request's callback that obviously never came).
- The tool is wonderful :) It would be wonderfuler if there were easier to understand how the boxes correlated to the code. I don't know what that looks like, perhaps a line from the box to the spot in the source that added it, or perhaps colouring each thing that can add a callback, and giving the same colour to the events it spawns, so we can quickly look at the queue and map it to the synchronous event foreach or the asynchronous foreach. Basically, the reader still has to pause and do some bookkeeping in their brains, but the code itself isn't actually all that important, it's the understanding of how it flows through the event loop and blocks execution by occupying the callstack. In many ways you've optimized for this already, eg by highlighting the code being executed, including the source in the callstack as it executes. But it still needs more. It needs to be as easy as possible for the viewer to acquire this info, like they should have to put conscious effort into not seeing it.