Heads up! This blog post hasn't been updated in over 2 years. CodePen is an ever changing place, so if this post references features, you're probably better off checking the docs. Get in touch with support if you have further questions.

We have a JS console now! Hopefully it works exactly as you expect it to. As in, you can log things to the console and see the results, and you can type things into the console and see the results.

Doesn’t the browser already have a console?

It sure does. Pretty much all desktop browsers, anyway. We’re big fans of the ol’ Command-Option-J ourselves. There are a couple of fairly big reasons why having a console right in the CodePen Editor is pretty nice.

You don’t have to context-switch to use this console

Literally every time the preview refreshes, you lose the “context” of the console in the native DevTools. You have to change it to back to the “CodePen (index.html)” to get in the right context.

Changing this all the time gets tedious fast.

With the CodePen console, you don’t have to worry about that.

You can share code with the console open. Even with ONLY the console open.

Perhaps what you are trying to demonstrate with your Pen is something specifically with console output. It’s not a visual concept, it’s a code concept.

There is no way to send someone a link to a Pen and have it open the browser’s console for them. But you can do that with the CodePen console. It’s the fourth-digit of our sharing format. It looks like this:

?editors=1011

That’s like:

HTML Open, CSS Closed, JS Open, Console Open

The first three digits are 0 for Closed, 1 for Open. But the fourth digit, for the Console, also supports 2, which means: Console all the way open, meaning totally covering the preview.

It can get pretty squishy too!

It follows your chosen syntax highlighting theme

For example, if you’re on a dark-on-light theme, the console will match:

A console is pretty great for teaching. Works great in Professor Mode.

Sharing code that is particularly about the code sometimes doesn’t need any visual component. Feel free to use that ?editors=0012 URL parameter to totally close the visual preview and highlight code output. I mention that specifically because I know teachers often use the console for demonstrating concepts. I know I have books about JavaScript that teach things by having you log stuff to the console.

The best part about using the console to teach? It syncs in Professor Mode!

The console is available in all the editor modes, like Collab Mode (everybody gets their own, no syncing) and Presentation Mode (for presenting!). No console in the Mobile Editor though, yet.

Thanks to JS Bin for some of the code

There were a lot of interesting problems to overcome when building the console. The biggest one was how to transfer the commands you type in the console into the iframe and getting the results back to display. Also in reverse: how to get output to the console from the iframe back to display. This was all solved using postMessage.

However, it turns out sending complex functions and objects through postMessage can bring up a variety of strange bugs and errors. Ultimately, we needed to “stringify” the data while sending it back and forth, and then parse the string on the other side.

The native JSON.stringify was good for a while, but wouldn’t parse functions (which makes sense, since they’re not really valid JSON).

After a bunch of attempts and debugging and improving our own stringification function, we thought we would take a peak at how JS Bin is doing their console (as they have long had one and it’s open source). They have a stringify function that is pretty awesome, that we’re using nearly wholesale. 👍

It’s going to get better. Let us know what you’d like to see.

This is just our first pass at the console. You know how we liking iterating on things to make them better around here, so there will definitely be some of that. We’ve even released a few upgrades already since silently launching it late last week. For instance, to make sure that we’re having as little impact on the performance of the site as possible, we’ve upgraded the console to not render anything while it’s closed, but still show you stuff once it’s open. We’ve also stopped logging things that are too ginormous. For instance the window object is just too damn big to log, so we show an error instead:

We might be able to crack that one day, we’ll see ;)

You can log objects and functions and stuff though, and as a matter of fact, we render them as mini-CodeMirror instances so they have nice syntax highlighting and can do code folding.

Also important to know: we don’t log errors. You can console.error() or console.warn() but a normal error (like something being undefined) will not log. (Not all console commands are supported. Many of them just map to .log().)

See:

We do catch syntax errors right within the editor itself though, which is nice, especially for learners. And the native console will catch things like undefined errors.

Can you find the easter eggs?

There arrreeee sommmmeeee.

High five

To Tim Holman who headed up this project and David Desandro who helped integrate it into the layout smoooooothly.