I agree with the point driving this rant, but not the conclusion. The openness of the web did and does make it possible for me to learn everything I want to know for what I do, and that shouldn’t change.

From a performance perspective, condensing JavaScript files has become almost a necessity for some web applications. My (rather small) toolkit goes from 16362 bytes to 6010 when I’ve finished with it, and I don’t do any of the newline or method renaming trickery that other toolkits have. When the size of the scripts go up, the amount the application loading time benefits goes up even more.

Now, that said, I agree with the openness, and that openness should go further, but live where the openness doesn’t hold back performance and scalability. More sites and web applications should follow in the footsteps of Livejournal and (much more recently) reddit by opening the ENTIRE application up, and actively encouraging others to use it, learn from it, criticize it, and improve upon it.

I’m kinda with Shawn. I like the idea of whitespace and comment stripping. That it is much smaller, comparatively, than images is a red herring IMO - most of the images out there should ALSO have some compression/optimization work done, which is why they’re so freaking huge.

However, I certainly agree with Jason, in that obfuscation sucks and should be killed with fire. If I were to condense everything (Note: I wouldn’t obfuscate - I think the performance hit the box suffers decrypting that crap nullifies the performance gain you get from a smaller, stripped file) - I would offer the entire uncompressed source code for my site as a .tar.gz. Just to stress the point that it isn’t about hiding something, its about squeezing performance from every angle I can manage.

Jason: for an example where I completely agree with you, anything Google writes. They obfuscate the crap out of their scripts, not only to the point where it practically looks like they’ve accidentally pulled in byte-code, but they pull 99% of it in via XHR requests (one of the parallel loading tricks), which incidentally keeps them from showing up as JavaScript files when profiling the loading.

HOWEVER…if they released the uncompressed source files, I wouldn’t care. If they didn’t compress the hell out of their scripts, I have no doubt it would inflate GMail from the 700k± load to at least a couple of megs. Now multiply that difference by the number of users, and you get insane amounts of unnecessary work for the servers (and GMail loads/runs even slower, if you can imagine that). The same goes for Yahoo, with just one of their scripts weighing in at 300k even after shrinking AND gzip-ing.

Back to someone wanting to learn how they did something, both of those companies have opened their main JavaScript libraries for use. Google made their Google AJAX[sic] APIs publicly available and documented them (though you still have to get a developer key and legal crap applies and I’ll bet they do that because otherwise everyone’ll know they can’t code for shit). In contrast, Yahoo released theirs under the BSD license, and tell you so right on the main YUI page. Not only can you see how they did things in the otherwise obfuscated Yahoo mail app, but you can fix their code to run better in your own projects.

And, just for the record, our own main library (the largest resource we load) would shrink by over 50k, and it could use it. Our load time would vastly improve (of course, not as much as if Firefox and IE caught up to others and parallel loaded JavaScript files along with everything else).

I agree with your point that nobody should obfuscate their code for the purpose of hiding it from others, but you start off your post seeming to hate those who even remove whitespace and comments, let alone renaming internal function variables. That has nothing to do with hiding your scripts and everything to do with cramming as much functionality as you can into the smallest and fastest download.