{"id":552,"date":"2010-01-18T23:29:07","date_gmt":"2010-01-18T23:29:07","guid":{"rendered":"http:\/\/blog.codedread.com\/?p=552"},"modified":"2010-01-18T23:29:07","modified_gmt":"2010-01-18T23:29:07","slug":"tight-javascript","status":"publish","type":"post","link":"https:\/\/www.codedread.com\/blog\/archives\/2010\/01\/18\/tight-javascript\/","title":{"rendered":"Tight JavaScript"},"content":{"rendered":"

[clipart]<\/object>When I was fiddling with my JavaScript (sounds obscene) for the MIX 10k Challenge<\/a>, I was obviously interested in shrinking the code as small as possible. I was also interested in learning some best practices that would produce tighter minified code but would not<\/em> reduce the readability and integrity of the unminified source.<\/p>\n

I came up with two simple practices that I intend to follow going forward to produce readable JavaScript that minifies better:<\/p>\n

1. Reduce Early Returns<\/h3>\n

When I'm writing code, sometimes I think of error situations after I've written the main body of a function. This often results in me inserting a quick early return at the top of a function:
\n
\n  function foo() {
\n    if (garbage > 0) return;<\/b>
\n    \/\/ rest of function here
\n  }
\n<\/code><\/p>\n

This gets the error condition \"out of the way\" and I don't have to think about it anymore. However, it is usually better practice to write this as:
\n
\n  function foo() {
\n    if (garbage == 0) {<\/b>
\n      \/\/ rest of function here
\n    }<\/b>
\n  }
\n<\/code><\/p>\n

Early returns are sometimes debatable, but in general they make your code harder to read (particular if your return is embedded deeper in the function than at the top in my simple example). They also have the side effect of making your code larger: that extra 'return;' is 7 more characters compared to the two required for the braces.<\/p>\n

In my experiments YUI Compressor<\/a> does not rewrite my code to the second example, eliminating the early return. On the other hand, the Closure Compiler<\/a> does.<\/p>\n

2. Collapsing Variable Declarations<\/h3>\n

This one is pretty straightforward. Instead of writing this:
\n
\n  var x = 5;
\n  var y = 2;
\n  var z = \"foo\";
\n<\/code><\/p>\n

write this:
\n
\n  var x = 5,
\n      y = 2,
\n      z = \"foo\";
\n<\/code><\/p>\n

It looks just as readable and reduces the extra 'var' characters.<\/p>\n

Again, as with the first case, YUI did not reduce my code while Closure Compiler did.<\/p>\n

What Else?<\/h3>\n

By the way, I don't mean to imply that the Closure Compiler is an overall better minifier than YUI Compressor. <\/p>\n

These are just two simple examples, but I'm interested in learning some more best practices that will keep my un-minified code readable but produce tighter JS when minified.<\/p>\n

It may sound silly to worry about 3 characters here and 5 characters there, but I think about it this way: it doesn't hurt my code at all to follow the practices above and it has the potential to reduce size when minified (by even a very small amount), so why not follow it? This is similar to when I retrained myself to consistently use the pre-increment operator in C++ for-loops in case the loop variable is an iterator: doesn't reduce the readability of my code and has the potential to improve the efficiency (read more<\/a>).<\/p>\n

So what else?<\/p>\n","protected":false},"excerpt":{"rendered":"

[clipart]When I was fiddling with my JavaScript (sounds obscene) for the MIX 10k Challenge, I was obviously interested in shrinking the code as small as possible. I was also interested in learning some best practices that would produce tighter minified code but would not reduce the readability and integrity of the unminified source.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[192],"class_list":["post-552","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-javascript"],"_links":{"self":[{"href":"https:\/\/www.codedread.com\/blog\/wp-json\/wp\/v2\/posts\/552","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.codedread.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.codedread.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.codedread.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.codedread.com\/blog\/wp-json\/wp\/v2\/comments?post=552"}],"version-history":[{"count":10,"href":"https:\/\/www.codedread.com\/blog\/wp-json\/wp\/v2\/posts\/552\/revisions"}],"predecessor-version":[{"id":587,"href":"https:\/\/www.codedread.com\/blog\/wp-json\/wp\/v2\/posts\/552\/revisions\/587"}],"wp:attachment":[{"href":"https:\/\/www.codedread.com\/blog\/wp-json\/wp\/v2\/media?parent=552"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.codedread.com\/blog\/wp-json\/wp\/v2\/categories?post=552"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.codedread.com\/blog\/wp-json\/wp\/v2\/tags?post=552"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}