Abusing console.log to Remove Debug Code

By  on  

One of the big efforts of this blog is to make it as fast and compact as possible. I shave bytes and do everything I can to make the site as lightning fast as possible. In looking at my site's main JavaScript file, I saw a few blocks which have no value on production, even after minification. After some basic experimentation, I realized that we can abuse console.log statements, which are removed by minifiers, to execute functions on development servers but not on production!

The JavaScript

The traditional call to console.log is one or several strings, but you can pass a self-executing function if you want:

console.log((function() {
  // Do whatever...

  // Example for local dev: convert live links to local

  // Return a string to be logged, if you'd like
  return "Debug: {x} has been executed and is now working";
})());

The console.log method really doesn't do much here, but we get the added benefit of not only function execution but removal during uglify runs.

Using console.x methods is a big help during development, and it's awesome that we can bastardize a minifier to work during both development and productions!

Recent Features

  • By
    Responsive Images: The Ultimate Guide

    Chances are that any Web designers using our Ghostlab browser testing app, which allows seamless testing across all devices simultaneously, will have worked with responsive design in some shape or form. And as today's websites and devices become ever more varied, a plethora of responsive images...

  • By
    Chris Coyier’s Favorite CodePen Demos

    David asked me if I'd be up for a guest post picking out some of my favorite Pens from CodePen. A daunting task! There are so many! I managed to pick a few though that have blown me away over the past few months. If you...

Incredible Demos

  • By
    Drag. Drop. Lock.

    I've received dozens of emails about my Six Degrees of Kevin Bacon Using MooTools article. The MooTools in my article contained a lot of conditional code to require correct dropping per the game and many people requested that I simplify the process and just...

  • By
    Pure CSS Slide Up and Slide Down

    If I can avoid using JavaScript for element animations, I'm incredibly happy and driven to do so.  They're more efficient, don't require a JavaScript framework to manage steps, and they're more elegant.  One effect that is difficult to nail down with pure CSS is sliding up...

Discussion

  1. I am also trying my site performance faster. Thanks for sharing. I have learned a lot.

  2. Asmor

    “I even remove ” /” from IMG, LINK, and META tags to save those few bytes, just to be as slim as can be”

    Uhh… The trailing slash is a relic from the bad old days when people thought XHTML was going to save the world.

    You shouldn’t have had to remove the trailing slash because it shouldn’t have been there in the first place. :/

    • I automate it though, because I can’t go back and redo everything.

    • Erik

      Wait what?

      You know there’s a thought about using / in links.

      It’s way easier to type / than to type http://www.domain.com/. Plus that you’ll save even more bytes!

      Can’t really see what’s wrong about using / actually!

    • Breaks links in RSS feeds :(

  3. Asmor

    You can make the link protocol-less, e.g. >a href=”//www.example.com”<

    Of course, that’s a bad idea if you aren’t set up to serve HTTPS, since you don’t know what protocol the visitor’s going to be requesting.

    It’s also helpful in general if you’re e.g. getting some resource from a CDN, where in dev you’re accessing via http and on live you’re accessing via https.

  4. Steve

    Not clearing out the temporary debug statements in your code before pushing to your source control / production is a bad move and a sign of serious code smell. Once you’ve finished debugging, remove it! None of your coworkers want to have to scan over your legacy debugging to maintain the code!

  5. I’m confused. I agree with Steve that leaving debug statements scattered around your development code is usually a code-smell. I have never come across a time where I needed to leave them in. However, why are you worried about this when there is a config option in uglify.js to remove console statments: drop_console = true?

    • That’s the point of this post — you can add debug-only functions in console.log statements and they’ll be removed via drop_console!

    • Ah! I didn’t quite get that from reading the article. I might be having a case of the Wednesdays. But anyway, with that explanation, this is very neat stuff. I thought you meant that a function wrapped in a console.log statement is the only way Uglify will remove it. Thank you for clarifying.

  6. Steve

    When run locally (in dev), there is a perf penalty for excessive logging (most noticeable in big loops) but more importantly when you do want to debug that one thing that isn’t working you only want to debug that one thing! If I had to debug in someone else’s spaghetti of logs I’d lose my mind!

    If this technique works for you, great… but I’d much rather strip it out of the code completely or use the magic “//” prefix to ensure it is never run (dev or prod) *unless* a developer turns it on. (PS comments are of course stripped out of all code when run)

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!