Sophistication in Web Applications?

whit537 asks: "Anyone who uses Gmail for 5 minutes can see that it's a pretty dern sophisticated web application. But just how sophisticated? Well, first of all, the UI is composed of no less than nine iframes (try turning off the page styles in Firefox with View > Page Style). But then consider that these iframes are generated and controlled by a 1149 line javascript. This script includes no less than 1001 functions, and 998 of these functions have one- or two-letter names! They're obviously not maintaining this script by hand in that form. So do they write human-readable javascripts and then run them all together, or have they developed some sort of web app UI toolkit in Python? Does Gmail need to be this complex or is the obfuscation a deliberate attempt to prevent reverse-engineering? And are there any other web apps that are this sophisticated?"

Comments

not simply obfuscation

[Glog]

I don't believe that the naming of the functions and variables is simply an effort to obfuscate the code. There is that, of course, but the main reason is probably to save money on bandwidth. When you have millions of people hitting your servers you can scrape quite a few bucks by removing white space and reducing the size of your files the way they have.

Gmail not that impressive

[Anonymous Coward]

1200 lines of Javascript might seem like an enormous amount to a dreamweaver monkey, but it's hardly any code for anyone who does real programming*. Check out the scripts for Outlook Web Access for example. Or any other intranet/portal type application.

(*Well, many 'real programmers' are loath to do rich client stuff in JS, perferring their server side frameworks instead. But once you get the hang of it, it's pretty nice.)

Re:Gmail not that impressive

[PurpleFloyd]

I don't think it's accurate to say that any arbitrary amount of code defines the line between code grinders and real programmers. After all, there's a world of difference between 1200 verbose, well-commented lines and 1200 highly optimized lines full of obscure tricks to squeeze every bit of performance possible out of the hardware. The first could be cranked out in a few hours by almost anyone with some programming knowledge, and the second might take weeks or even months to get right.

Looking at the Google code, we can see that while it appears to be machine generated, it definately tends towards the latter; Google has obviously tuned the code to save bytes and run as quickly as possible. Bandwidth and processor power aren't so important in a corporate environment where everyone has a LAN connection to the server and decent machines to work on, but when you have to deal with customers on dialup links and using old machines, every bit and every instruction counts. In that scenario, 1200 lines can be an enormous amount of code.

Re:If they are smart, and they are,

[T-Ranger]

"pretty clever little language" is the understatement of the year. The entire UI of the browser that I am using now is done in javascript.

Re:Huh?

[sethadam1]

Actually, if you browse around Google and Gmail, you'll find tons of links like this one - the file has a .py extension.

Google writes A LOT in Javascript. It would not surprise me, although I have no evidence of this, if they wrote the code in their choice editor and then ran a python app that condensed the code to remove space, renamed the functions, and replaced all function references. At 1000+ functions, if the function names had just 5 letters each (not much if you're not being terse), that would be an extra 3000 characters (3k) PER PAGE LOAD. Multiply that times thousands (tens of thousands after general release?), and you'll see A LOT of extra bandwidth.

Re:Huh?

[Anonymous Coward]

At 1000+ functions, if the function names had just 5 letters each (not much if you're not being terse), that would be an extra 3000 characters (3k) PER PAGE LOAD. Multiply that times thousands (tens of thousands after general release?), and you'll see A LOT of extra bandwidth.

You're forgetting the effects of caches. I agree that they probably developed the Javascript the way that they did to minimise bandwidth use, but the impact isn't anywhere near as much as you imply.

Re:Huh?

[Anonymous Custard]

that would be an extra 3000 characters (3k) PER PAGE LOAD

Well, that js file would be cached by the browser, hopefully, not reloaded with every single page load.

Re:Yah, good for Javascript!

[Anonymous Coward]

God forbid, you may have heard of these guys [slashdot.org].

It is a well-known fact that the slashdot codebase is so poorly written that it would be a monumental task to make it product valid html. So, I wouldnt go holding slashdot up as an example of how to write maintainable code with perl.