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
    I’m an Impostor

    This is the hardest thing I've ever had to write, much less admit to myself.  I've written resignation letters from jobs I've loved, I've ended relationships, I've failed at a host of tasks, and let myself down in my life.  All of those feelings were very...

  • By
    How I Stopped WordPress Comment Spam

    I love almost every part of being a tech blogger:  learning, preaching, bantering, researching.  The one part about blogging that I absolutely loathe:  dealing with SPAM comments.  For the past two years, my blog has registered 8,000+ SPAM comments per day.  PER DAY.  Bloating my database...

Incredible Demos

  • By
    Duplicate the jQuery Homepage Tooltips Using MooTools

    The jQuery homepage has a pretty suave tooltip-like effect as seen below: Here's how to accomplish this same effect using MooTools. The XHTML The above XHTML was taken directly from the jQuery homepage -- no changes. The CSS The above CSS has been slightly modified to match the CSS rules already...

  • By
    MooTools 1.2 Image Protector: dwProtector

    Image protection is a hot topic on the net these days, and why shouldn't it be? If you spent two hours designing an awesome graphic, would you want it ripped of in matter of seconds? Hell no! That's why I've created an image...

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!