My guess is that it's just a bandwidth thing. Keep things as small as you can, to keep the downloads down. Imagine if every piece of Google code was as big as it "should*" be, and then having to download all these little chunks of code throughout the day. It'd definitely tot up pretty fast..

*should = modern day coding methods.. for classic style coding methods, see "10 Liners"..

Its not Obfuscation code, just like css to keep files/code smaller.

If it is in fact, just a bandwidth thing, it'd be cool of them to put out some pages with explanations of what's going on or with the original code int he cases of Javascript. Then people could learn the functionality if they wanted to understand/hack it, but they wouldn't be increasing their page sizes. But I suspect that some secrecy is part of it as well, and that it is intentional.

I've read somewhere else that it is a bandwith thing.

There was a neat report out a few years ago that showed how much bandwith Google would use if they added quotation marks to something on the home page, or added an HTML comment, etc..

It would make my work on Gmail 2.0 Opera compatibility *much* easier.

This code is not even handwritten... it's compiled from Java-Code that probably looks a lot different.

that's incredible but it seems that the a long awaited quite full fledged API is indeed available.

I'm a poor JS programmer but please, you professionals, have a look:

that's a little piece of a not-official gmail gadget: http://hosting.gmodules.com/ig/gadgets/file/111235031415052608966/google_gadget_gmail.xml

...

/// Contacts ///
  
var gmContactsUrl = 'http://' + domainGmail + '/ig/c/data/contacts?out=js&max=250&groups=true&psort=Name';
var gmContactsObj;
var gmContactsNum;
  
function gmLoadContacts() {
   var xmlHttp;
   try {
   xmlHttp = new XMLHttpRequest();
   } catch (e) {
   try {
   xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
   } catch (e) {
   try {
   xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
   } catch (e) {
   _gel('divGmail').innerHTML = "Please turn on javascript.";
   return false;
   }
   }
   }
   xmlHttp.onreadystatechange = function() {
   if(xmlHttp.readyState == 4) {
   if (xmlHttp.status == 200) {
   var response = xmlHttp.responseText;
   response = response.replace('while (true);', '');
   response = response.replace('&&&START&&&', '');
   response = response.replace('&&&END&&&', '');
   gmContactsObj = eval("(" + response + ")");
   gmShowContactsMenu();
   gmShowContacts();
   }
   }
   }
   xmlHttp.open("GET",gmContactsUrl,true);
   xmlHttp.send(null);
}

function gmShowContacts() {
   var group = _gel("gmContactsGroup").options[_gel("gmContactsGroup").
selectedIndex].value;
   var search = _gel('gmContactsSearch').value.toLowerCase();
   var contactcount = 0;
   var html = '';
  
   gmailPrefs.set("gmContactGroup", group);
  
   if(gmContactsObj.Body.Contacts!= null) {
   var contacts = gmContactsObj.Body.Contacts; //array
  
   html += '<div class="gmContactResults"> <table class="gmContactTbl">';
  
   for(var i=0;i<contacts.length;i++) {
   var show = (group == '^All') ? true : false;
   var affinity = contacts[i].Affinity;
   var emails = contacts[i].Emails; //array
   var fullname = contacts[i].FullName; //array
   var groups = contacts[i].Groups;
   var name = (contacts[i].Name!= null) ? contacts[i].Name : emails[0].Address;
   var picture = 'http://mail.google.com/mail/photos/' + emails[0].Address.replace('','%40');
  
   //Group
   if(groups!= null) {
   for(var j=0;j<groups.length;j++) {
   if(groups[j].id == group) show = true;
   }
   }

...

[Added a line breaks at one place. -Philipp]

I agree with Hank. I've never used GWT but from what I understand the js that makes it to our browsers is generated from Java code. So what we get is probably all there is – there's no version with comments and self-documenting variables names and etc.

Add my voice to the chorus: it is a bandwidth thing. It has always been a bandwidth thing. I doubt Google is deliberately trying to hide anything that makes it to a public release. Discouraging adventurous developers from playing with their code is, at best, an optional side benefit.

Assume your fancypants Web 2.0 Social AJAX site gets 1 million active users per day. Cutting down the total first download from 200 kB to 180 kB saves up to 20 MB per day in bandwidth. Adding up to almost 600 MB per month. This, of course, doesn't count caching, but every time code changes, it (should) invalidate any cached versions anyway. This easily saves you and your ISP REAL MONEYS. It saves Google tons.

Storage is trivial, bandwidth is not.

Instead of asking Google to ALWAYS use clearer Javascript resulting in larger files, how about asking them to offer the tools and data they use to obfuscate and "de-obfuscate" their JS for the web? This way, anyone can get to the clear, usable code Google uses internally, and Google gets to keep their bandwidth savings.

I added a first update to the post, thanks.

... I wonder how many Google JavaScript files are just output from the Google Web Toolkit?

Lol, I'm not sure I even understand what that quote from me says about our code obfuscation. One of the reasons is definitely bandwidth. I'll see if there's more info we can share.

> Lol, I'm not sure I even understand what
> that quote from me says about our code
> obfuscation.

Pamela, yours was an argument of relevance in the "Google appreciates reverse-engineering and even goes to great lengths to deliver APIs to follow-up on such reverse-engineering" line of thought (a line of thought which goes against obfuscation, as that makes it harder to reverse-engineer) :)

Another side of the bandwidth issue is user experience. Smaller pages mean faster loads...when I worked there, we obsessed about that.

I also assumed it was created by GWT.

Yes it's mostly about latency. Bandwidth is important but it's cheaper than it used to be. On the other hand peoples attention is more expensive :) Maps starts pretty fast for such a complex app but it can always be faster.

The code isn't "obfuscated" so much as compressed and optimized. It's not an uncommon technique. Look at the Live Maps JS:

http://sc1.maps.live.com/js/bin/1.3.20071113130328.94/en-us/ve.js?v=4

It's sort of similar, but not compressed as well as ours is :)

99.9% of users don't want to download the comments in the code, it's just a waste of time, and we don't want you looking at them either as they're full of references to internal systems and codenames that aren't meaningful outside the company. Yes it makes it harder to mess around with, but we provide lots of documented ways to build on maps. Like the Maps API and Mapplets, for instance.

you used to have a good blog. stop writing fluff pieces

It's compressed Javascript, from hand-written Javascript. Google has proprietary technology to compress JS, but it's not all that different from various open source projects.

Few projects at Google use GWT. Furthermore GWT code is very easy to spot; look at sites which do use GWT.

Thanks Some Googler and Xoogler, I added another update.

James Joyce, I do appreciate more specific criticism if you have any (and it would be nice if you could use your real name).

Huh? So I hope they kept their "unobfuscated" codes around.

it's both, to save bandwidth AND to obfuscate

it's normal almost everyone is doing it, nothing really special

for bandwidth
google has always been about proviving webapp/API/etc.
that scales big

do the math , what scale better a 1KB compacted JS
or a 10KB uncompacted JS ?

for obfuscation
you don't want people to mess around with compacted JS code,
be it google, open source library etc.. you want to make it hard not easy

it's not really security by obscurity
it's more about 1st the bandwidth,
you can not simply compact JS code and
let it readable so long var name have to go,
all lines CR/LF have to go, etc.

and 2nd the versioning,
you don't want people to provide patches or hacks or whatever
on compacted JS, it's much stable and practicable if they provide changes on the clean source code (cf open source JS lib)
or use an API (imho what google do)

the JS that google use on their webapp is just the small tip of the iceberg,
even if they would output friendlier client-side JS code with comments and all it will not help that much, the real gem is the backend (the big hidden part of the iceberg) that make something as google maps scales for use by millions of people

and for what ?
so a handfull of people could read the code in the clear ?

I mean com'on it would be handcrafted JS code used in a such a context
that very few people could really learn from it or make any sens from it

Oh please, that code is not obfuscated, I've seen supposedly <i>commented</i> code way worse than that.