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.

Crazy but true: a single line of JavaScript can completely crash any browser out there. Or at least the current tab if it’s a multi-threaded browser. That’s right, the dreaded infinite loop. A for loop that doesn’t ever meet its end condition, a while loop whose condition never becomes falsey, they spell the end for some of today’s most sophisticated computer software.

Perhaps browsers have good reason for not trying to interfere. But it’s become a bit of an issue here on CodePen where we encourage you to write and execute JavaScript freely. Save a Pen with an infinite loop and that Pen will always freeze the browser. Worse, it will freeze any page that loads that Pen in the Grid.

The grid being those little iframes we show all over the place on CodePen. The homepage, profiles, search results, collections, tags, everywhere. As I page through Recent Pens each day, not a day goes by I’m not locked up by an infinite loop.

We have a URL parameter you can put on any page that will prevent that JS from running. That’s pretty useful so you (or we) can get in there and fix it. But it’s still not a great system.

JS Bin / Remy Sharp have an open source project called loop protect that they use to prevent this. It’s pretty cool and suites their realtime needs well. Our own Alex Vazquez undertook this project for CodePen and ended up going the route of the Abstract Syntax Tree (AST) by way of Esprima.

I won’t go into too much detail here, but essentially we can rewrite your JavaScript and inject possible breakpoints into all the loops. Then time the loops and if they take too long, break them. Alex goes into a bit more detail in his blog post.

What isn’t quite done yet …

… is doing this within the editor itself. Alex has some ideas though. It’s a bit more tricky because we need to be more careful that we don’t interfere too much with your code.

For instance, a requestAnimationFrame animation is kinda like an infinite loop, and our setup now kinda breaks those. We’re working on making it smarter (possibly something testing framerates) so we can get the protection going in the editor itself.

For now, if you get yourself in a bind, remember the URL param so you can get in there and fix the issue.