tags:

views:

257

answers:

5

If a packed Javascript saves 20kb off the download size, but takes a perfomance hit to unpack, then are there any benefits, besides obfuscating the code?

I've made this a community wiki because it may be open to some discussion.

+1  A: 

Short answer yes, because the client machine's unpacking time is faster than transmission, also the internet is overloaded as is, so any contribution to making things better is appreciated by anonymous, also remember that most clients will be caching this stuff, and the larger the file the more chances it will get itself or other stuff evicted from the clients cache, especially in mobile devices

Robert Gould
Do browsers and HTTP servers still not support gzip, compress and deflate content-encoding? If it's worth zipping javascript, then surely it's worth zipping everything, and that's an HTTP-level issue rather than a script-level issue.
Steve Jessop
Agreed, zipping is better, but zipping a minified source is twice as good .Well not really 200%, but you get the gist.
Robert Gould
Oh yes, I agree that minifying might be worthwhile. It's just the questioner talks about a "temporary browser stall" to unpack the script, suggesting to me that something other than HTTP-level compression is going on. That shouldn't stall the browser.
Steve Jessop
Yeah, there should be no noticeable stall to the user, that should all be hidden well down deep, but not sure what browser he is using :)
Robert Gould
Maybe I should edit the question! And to clarify I'm using Firefox 3 on OS X
alex
+3  A: 

Packed javascript code generally does not take longer to execute vs regular code. Most code packers will shorten variables, function names and use a host of tricks to make the source smaller. The resulting source is fully executable! You can verify this by taking a look at it during runtime with firebug. You'll see the compressed code executing in its minimized form.

Byron Whitlock
packed js *does* add a few ms of execution (minified doesn't), this can be measured with Firebug
Mauricio Scheffer
How do you use Firebug to determine Javascript execution time? I guess that's a new question in itself!
alex
See console.profile() or console.time() (http://getfirebug.com/console.html)
Mauricio Scheffer
A: 

The question is, why does the packing save 20kB? You should investigate making your 'normal' javascript smaller. Is the readability of your code significantly improved by putting spaces around operators, or by using very long variable and function names? The most egregious waste of bandwidth I have seen on any web content, script or page or css, is indenting with spaces. If you must indent, use tabs, or single spaces. Nothing is more wasteful than a hundred lines in a row with 20+ spaces at the beginning.

Sparr
Optimize your code for human consumption. One day someone will be tasked with maintaining it, and you don't want a vendetta on your hands. Packers allow the best of both worlds. Agreed on spaces vs tabs.
Bryan Watts
Long sequences of spaces are handled very efficiently by server-size gzip compression. And if you're not gzipping your JS code, you're paying a much bigger price than you'd save by changing your indentation style.
benjismith
Thats why you have 3 files: 1) The source file that you edit, 2) a minified version at the server, 3) a compressed minified version at the server. And you configure you server to send the compressed version if the client can handle it or else the minified version. (cont..)
some
That way you get good compression at the cost of only a check if the file exists but no extra CPU cycles to compress the file. And since it is precompressed you can have the best compression.
some
A: 

The guys at Yahoo's YSlow recommend using both a minifier and gzip compression.

The minifier will strip out whitespace, shorten variable names etc. That way you can code with proper indentation and variable names so that other developers can understand your code.

The gzip compression is probably even more valuable.

cbp
+1  A: 

Presumably, packed JavaScript is (slightly) more efficient for the server to send, while the unpacking expense is absorbed by the client.

If the user experience is equivalent in both cases, I'd go for the packed JS.

Anytime you can push some work to the client without incurring a negative user experience, go for it, and reap the benefits of distributed computing.

benjismith