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
    Designing for Simplicity

    Before we get started, it's worth me spending a brief moment introducing myself to you. My name is Mark (or @integralist if Twitter happens to be your communication tool of choice) and I currently work for BBC News in London England as a principal engineer/tech...

  • By
    Introducing MooTools Templated

    One major problem with creating UI components with the MooTools JavaScript framework is that there isn't a great way of allowing customization of template and ease of node creation. As of today, there are two ways of creating: new Element Madness The first way to create UI-driven...

Incredible Demos

  • By
    Disable Autocomplete, Autocapitalize, and Autocorrect

    Mobile and desktop browser vendors do their best to help us not look like idiots by providing us autocomplete, autocorrect, and autocapitalize features.  Unfortunately these features can sometimes get in the way;  we don't always want or need the help they provide.  Luckily most browsers allow...

  • By
    jQuery UI DatePicker:  Disable Specified Days

    One project I'm currently working on requires jQuery. The project also features a datepicker for requesting a visit to their location. jQuery UI's DatePicker plugin was the natural choice and it does a really nice job. One challenge I encountered was the...

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!