"Byte-saving" made me think more of memory management than source file size.<p>Since version 1.5, JavaScript accepts Unicode characters as identifiers. Shouldn't this be "character-saving"?
This is aimed at people writing tweet-sized JavaScript for <a href="http://140byt.es/" rel="nofollow">http://140byt.es/</a> . This is a great resource for learning JavaScript and has some very impressive code behind it. Generally for production sites, though, I'd much rather go with jQuery due to its extensive test suite and bowser support. Between tweet-sized and jQuery-sized JavaScript, there's a whole lot of micro JS scripts / frameworks on <a href="http://microjs.com/" rel="nofollow">http://microjs.com/</a><p>I'm currently writing a mobile web app that needs to work over GPRS connections with 30kb/s bandwidth and up to 1s latency. In these cases, shaving off a few bytes to get a page in 1 fewer TCP/IP packets really does make a difference.
I love doing stuff like this for fun. Sometimes I try to get nice algorithms into tweets. Here is one of my favorites so far, returns the powerset for array 'a':<p><pre><code> function P(a){for(p=[],i=Math.pow(2,l=a.length);i;)for(b=i.toString(2),j=k=b.length,p[--i]=[];j;)if(b[--j]==1)p[i].push(a[j+l-k]);return p}
</code></pre>
I know that there are some big gotchas here, such as b and p being declared globally due to lack of var...but I gave up trying to gain an extra 4 bytes for function(a,b,p). Also the subset arrays are in reverse order.
<p><pre><code> rand10=Math.floor(Math.random())*10 // before
rand10=0|Math.random()*10 // after
</code></pre>
The first is not random, it will always return zero (this error is <i>very</i> common). The second happens to be ok because * binds tighter than |. However, this is order-dependent.
Hah. Wish I'd thought of some of these for last year's <a href="http://10k.aneventapart.com" rel="nofollow">http://10k.aneventapart.com</a> .<p>I tried to write most of my JS for 10k 'pre-minified', using tricks akin to (but not as awesome as) these. Echoing other commenters, it was largely as an intellectual exercise (to see if I could meet the 10k limit by hand) but it did make me think of a few things in a different light, and some of the 'optimizations' are things that minifiers wouldn't have done for me.<p>It's also a good way to get under the skin of a language, get a feel for the nuances of how the runtime behaves, and give you hints for other (more generally useful) optimisations.
They should also add:<p><pre><code> Math.floor(someNumber) // 2.6 becomes 2
someNumber | 0 // 2.6 becomes 2
</code></pre>
Not only because it saves characters, but because it might actually be used in the real world (Whereas most of the ones in the article should really be left to a minifier)