Abusing console.log to Remove Debug Code
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!
I am also trying my site performance faster. Thanks for sharing. I have learned a lot.
“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.
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 :(
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.
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!
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.logstatements and they’ll be removed viadrop_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.logstatement is the only way Uglify will remove it. Thank you for clarifying.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)