Better JavaScript through JavaScript

JavaScript for Everyone. Launching Autumn 2025

Something that has always bothered me abo— oh, sorry, hey everyone. Welcome back to the JavaScript for Everyone newsletter. I'm already on a tear here; strap in.

Anyway, something that has always bothered me about teaching JavaScript is how quickly it falls apart when it comes to the execution, literally and figuratively. I can spend hours lecturing about where the semicolons go, pointing at copy-and-paste-able snippets of code, and putting red circles on screenshots like so many YouTube thumbnails, but nothing is gonna make a syntax or a concept stick half as well as trying it out for yourself. You're don't learn JavaScript from a multiple-choice "which one of these is a string literal" quiz. You learn JavaScript by writing JavaScript.

So how's that play out in practice, when you're putting together an end-all-be-all guide to how JavaScript works? In my experience, it goes a little something like this:

Before we do anything, you'll probably want to make a directory, and put an HTML file in there, and fill all that out, and down at the bottom, near </body>, chuck a <script> in there. Now we’re cooking; pop that file right open in your browser, 1997-style. Or I guess do php -S localhost:8000 (no, that’s not JavaScript — that's very not-JavaScript). Or we could learn what Node is, but uh, maybe later. Now, abandon this page you’re reading with all the code and the explanation of what it is you’re meant to be doing, and check out that blank— wait, did I explain what an IDE is? Well, have one of those, and do all that, then paste this snippet in the <script>, hit save, and there it is!

600 characters, a filesystem, two browser tabs, and an IDE before we get to "hello world". Alternately:

Why, we'll just use your browser's dev console! Pop that open right here on this very page and paste this snippet in there; good to go! Now, try changing— wait, okay, that had a const in it. Reload and hopefully you won't lose your place. Great. Now, we're gonna make a quick change. It kinda sucks to work on multi-line snippets in the console, so... Hey, did I explain what an IDE is? No, there's no best one, stay focuse— no, yeah, take a second to choose a nice code theme, I get that. Okay, paste this snippet into there, make the change, copy it, paste it back into the dev console, and there you go! Now we’ll— right, sorry, the const. Reload again?

Thus did I spend the better part of my initial course planning: in the black-and-white “there’s got to be a better way” part of the infomercial, burning the roast and spilling JSON down the front of my nice white shirt. All the “play along at home” parts felt too disconnected from the source material, and too persistent in one way or another. It's hard enough to learn about prototypal inheritance without a bunch of peripheral distractions.

So on the basis that JavaScript is pretty good at running JavaScript, I used CodeMirror to build a quick prototype for what I really want: a way to enhance snippets of code up into fully editable fields, with their own dev consoles attached.

Screenshot of a small embedded code editor under the heading “interactive console test.” It contains, on each line: an object literal, a console.log, a console.warn, a console.error, a custom console.hint method, and a string reading “this string literal is the right answer.” Below it, an embedded console contains the output of the object literal, each of the console method messages, and “you got the right answer” to correspond with the “this string literal is the right answer” line in the editor.

When you hit the button to run the code, returned values and calls to the any of the console methods will be intercepted and mirrored in the attached console. I’m still thinking this part through, but the result could even be checked against an expected result.

Here’s the best part: if you re-run it, the console persists, but code-wise everything works as though you’re running it for the first time — no reloading necessary, const or no const. Hit the reset button and the snippet is set back to how it was when you first landed on the page. I may or may not have added a “ghost in the machine” method that allows me to fire messages in the console; that’ll be our little secret for now.

I tell you, I feel pretty good about this as a proof-of-concept. I talked it through briefly with Chris and Dave on the Shoptalk podcast last week — CodePen uses CodeMirror too — and while the older version of CodeMirror I’m using definitely doesn’t sound like the way forward, it feels like a solid pattern at a high level. Like I said on the show, I just want something where you can get in there and break stuff — try something out, see if it throws an error, and move on as though it never happened. No fuss, no muss, no stubborn JSON stains that just won’t wash out.

And between you and me, “owning” the dev environment means I’d get to do cool things with, say, visual feedback. I mean, that’s not not a factor.