Sophistication in Web Applications? 197
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?"
not simply obfuscation (Score:5, Insightful)
Gmail not that impressive (Score:2, Insightful)
(*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:If they are smart, and they are, (Score:4, Insightful)
Re:Huh? (Score:3, Insightful)
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? (Score:1, Insightful)
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? (Score:3, Insightful)
Well, that js file would be cached by the browser, hopefully, not reloaded with every single page load.
Re:Gmail not that impressive (Score:3, Insightful)
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:Yah, good for Javascript! (Score:1, Insightful)
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.