It covers some basic stuff for web performance, scalability and availability, such as:

1. Common architecture pattern for horizontal scalability;
2. How to do load balancing;
3. Cost effective load balancing options;
4. Cloud computing does not solve scalability issue;
5. how to optimize web performance;

A list of free tools available are also mentioned, such as YSlow, RockStar Web Profiler and RockStar Optimizer.

Cloud Infrasturcture Providers

1. US: Amazon EC2, RackSpace, GoGrid, SoftLayer, NewServers, ATT, Verizon, Sun Cloud;
2. EU: FlexiScale, ElasticHosts, Amazon EC2, ATT, Verizon;
3. Asia: ATT, Verizon(?), RackSpace(?), 21ViaNet’ CloudEx(?);

Further:

1. RackSpace has data centers in US, Europe (London) and Asia(Hongkong), but does not tell you which data center(s) offer cloud computing capability. I suspect it is only within 1-2 US data centers now(update: RackSpace supports cloud computing at its Dallas and San Antonio data centers at this moment, according to RackSpace twitter response);
2. Savvis claims support for cloud computing, but one can not find anything meaningful from their website (the site is almost designed for anti-communications);
3. Sun Microsystem made a big deal announcing Sun Cloud, in particular, saying that they will provide a storage service(similar to S3) and a compute service (similar to EC2). Is this real? Is it still real after Oracle acquisition?;
4. Terremark also claims support for cloud computing. Again, their site is fairly non-communicative. I couldn’t even figure out whether they are offering an infrastructure service or a software product;
5. Integrated Cloud platform providers such as Google AppEngine etc are excluded from the list

.

Where are these “cloud” data centers located? Here is what I collected:

1. Amazon EC2: two locations currently (Virginia and London, both are my rough guesses. Let me know if you know!). Questions:
   • 3 availability zones in US - are these availability zones in the same data center, or in different cities?
   • Amazon also has data centers in other cities and countries (such as Hongkong). Will EC2 expand to these places?
2. RackSpace:
   RackSpace has data centers in a few locationis: San Antonio (TX), Dallas(TX), Herndon (VA), London, Slough (UK), and Hongkong. However, I couldn’t find any information indicating which data center(s) supports cloud computing. Or do they all support cloud server? Does anyone know?
3. GoGrid: San Francisco
4. NewServers: Miami
5. SoftLayer: SoftLayer has data centers in three locations: Seattle, Dallas, and Washington DC.
   Though I couldn’t find any explicit information indicating where cloud computing is supported, I suspect all three support it. BTW, I wish some other providers can learn from SoftLayer in using their websites to communicate necessary information.
6. ATT: ATT Synaptic Hosting has 5 locations: Piscataway, New Jersey; San Diego, California; Annapolis, Maryland; Amsterdam in the Netherlands; Singapore. It seems that all these five support elastic cloud hosting on a pay-as-you-go model. A huge drawback seems to be the lack of API support. Or at least I couldn’t find any information from their website. On the other side, ATT has a total of 38 data centers around the world (including Shanghai, Beijing, Guangzhou). Would ATT provide cloud computing support in some of the other data centers?
7. Verizon: Verizon announced CaaS(http://www.verizonbusiness.com/us/products/itsolutions/caas/) in early 2009. It looks good on parper, but there are very few little details available from their website. Here are some of the questions: Is there API available? Where are the CaaS data centers? What is the pricing structure?
8. Savvis: Savvis has data centers in a good list of locations in US (SFO, Chicago, Boston, …), UK (3), Tokyo, and Singapore. But I have no idea of which cloud computing support is and where they are support from Savvis web site. Any cloud API support?

Then in Europe, here are the options:

1. Amazon: UK
2. RackSpace: UK (2)
3. FlexiScale: UK (API is available at https://api.flexiscale.com/current/doc/)
4. ATT(?), Savvis (?) - not quite sure etc.

In Asia, options are much more limited. Here they are:

1. ATT: Hongkong, Singapore, Tokyo
2. Amazon: Hongkong(?) - Amazon does not offer EC2 at HongKong now. Will Amazon do so in the future? Similarly, will ATT offer cloud computing support in Shanghai data center? Will RackSpace offer such in their Hongkong data center?
3. Finally, 21ViaNet: this is Chinese hosting company. It announced something called “CloudEx” a few months ago and sounds similar to EC2.

Part of the inspiration of Web Profiler is due to my years of work related to Ajax and web 2.0. Starting from many years ago when I wrote an Ajax-based world processor to my Rich Internet Application tenure, I always loved what Ajax can do for my web apps, but I was also always intrigued by its performance implications.

Further, every time when I look at web performance, I got puzzled and mad. The tools, technology and offering people use today to gauge web performance are essentially what they were 10 years ago, despite that the web has changed so much. From big vendors to small shops, most web performance tools and techniques only give you a one-dimensional look. For example, most tools only tell you the network performance (request time, response time, etc). A few tools will tell you server processing time.

The reality is that web performance is 3-dimensional. Client side performance, server side performance and network performance are three inter-related dimensions that you must look at them together in order to understand web performance.

To make myself less made, I wrote Web Profiler - it measures server side, network and client side performance of any web application and present them together in a correlated way. For example, if your page loading is slow, Web Profiler can tell you the percent of time spent on client side processing, and network processing. You can look at the chart and see, “oh, yeah, it is this javascript function that is causing a long network delay that is causing the page slowness”.

Web Profiler was out in alpha and beta at RazorSpeed for a few months. It received really good feedback and strong interest from a variety of users. The alpha and beta code were downloaded over 10,000 times over a couple of months. A few hundred users actively used it to do something real(according to the log). A couple of dozens of users asked me about the pricing model and how they can pay something. A few users offered to pay something outright and I politely declined their offers.

Just when I was trying to figure out what to do with the momentum, I was approached by a couple of interested parties that see the potential of a new generation of service for web 2.0 applications. After quite a few conversations, some alcohol and a bunch of paperwork, I am happy to announce that Web Profiler has been acquired by RockStar.

RockStar is a premium brand in web performance. I met the folks there a few times and I have been truly impressed by their vision, capability to execute and market traction. It is a match made in heaven, and I strongly believe Web Profiler will achieve its full potential as part of the RockStar offerings going forward.

Unfortunately lawyers advised me not to disclose the acquisition price. Though I can say that I am very happy with the transaction. The deal is done so that I can finally say what I thought when they first told me the number they were thinking about: it is an insane amount of money (I know RockStar folks knew my thought on the number, but they believe it is worthwhile).

What’s next? I want to assure Web Profiler users that I will continue to help the product out. You can still email me bugs and complains. The folks at RockStar are going to be super helpful too.

Beyond that, given that I’ve already taken a few days off and had a few celebration drinks already, I’d better just go right back to work. So the next stop for me is yottaa. We’ll see where it leads us…Until then, happy finger workout!

To me, the root trigger of “falling” into this pattern is that I started Nexaweb right after the dot com burst and raised Series A in 2003, the year of the lowest venture capital investment over the last 15 years. After a few more years of growing Nexaweb and finally getting ready to start something new, the economy also went through its own cycle. So here I am, trying to start a company during a down economy again. What’s next? It is highly likely that the time when I start yet another company in the future will coincide with a similar moment in yet another economic cycle and so on.

Gee. I should have read this blog piece when I was young, and launched Nexaweb either a few years earlier or a few years later.

The reality is that entrepreneurs don’t have too much control on such things. Entrepreneurship is about seeing an opportunity, believing in the opportunity and taking actions on the opportunity. Opportunities come and go independent of the economy or anything else. If you see it and believe it, the entrepreneurial spirit inside doesn’t give one too much choice but to do something about it. In some sense, starting a company is like having a baby: you can rationalize, plan and time it all you want beforehand. However, once the triggered is pulled, the baby comes at the time designated by the almighty regardless of the state of the economy, one’s wishes/desires or anything else.

The other side of the reality is that it is not that bad to start a company in a bad economy. Some say it is tough to start something new when everyone else is hiding under their desks. Certainly true. Some other people would say it is actually good to start something now given the abundance of talents and etc. I can argue either way. Frankly, I don’t think it matters that much either way. Regardless of the timings, it is about being “relentless resourceful” (citing Paul Graham) in a way that is fairly similar to long distance running to me.

For comrades who are in the middle of starting up something now, here is a good diagram to look at (citing from Brad Feld). It shows some empirical data between the timing of economic cycles and good companies founded:

On Februrary 21 2009, Thomas Friedman of the New York Times wrote “Startup the Risk Takers” where he said:

“Reading the news that General Motors and Chrysler are now lining up for another $20 billion or so in government aid — on top of the billions they’ve already received or requested — leaves me with the sick feeling that we are subsidizing the losers and for only one reason: because they claim that their funerals would cost more than keeping them on life support. Sorry, friends, but this is not the American way. Bailing out the losers is not how we got rich as a country, and it is not how we’ll get out of this crisis.”

Further, Friedman points out that how such bailout money should be spent on: “imited financing, for a limited time, targeted on an industry bristling with new technology start-ups that, with a little push from Uncle Sam, won’t just survive this crisis but help us thrive when it is over. We need, and the world needs, an America that is thriving not just surviving“.

While I sort of understand the government using tax payer’s money to bail out financial institutions because we can not afford the collapse of the financial service industry, I do not see the strategic importance of the auto industry in this day and age. Why not fuel the $20B to new promising areas that would create lots of new jobs and lead to future prosperity?

Interesting, in response to Friedman’s post,  Fred Wilson of Union Square Ventures says “No Thanks”. Fred writes “The venture capital business, thankfully, does not need any more capital. It’s got too much money in it, not too little. Just ask the limited partners who have been overfunding the venture capital business for the past 15-20 years what they think. You don’t even need to ask them. They are taking money out of the sector because the returns have been weak.”

I appreciate Fred’s point of view from a VC’s perspective and would agree that giving $1B to the top 20 venture capital firms is not a good idea either (as suggested by Friedman’s original article), I think Friedman’s main point is valid: send money to those who create our future, not to bail out “giant wealth-destruction machine in history”.

As an entrepreneur, I certainly see Fred’s point that there are too much VC captial. But on the other side, I aslo see lots of startup companies that, with a little bit more money, can survive and thrive. I have seen various startups being caught in this economic situation, not because these companies are weak, but because of the ripple effect: limited partners in VC firms are getting burned; VCs are re-adjusting to a new reality of “longer fund cycle” and “portofolio companies need more than expected cash to reach exits”. As a result, VCs are finding their fund is not enough to cover the needs of portfolio companies. VCs are conserving their own fire power on “only the few highly promising portfolio companies”.  Some of the VCs even asked money back from their investments so that they can pour some more cash into selected companies.

(Jeff Bussgang has a good post “Why “Flat Is The New Up” and VC Funds Are Under-Reserved” that helps one understand why VCs have to conserve cash, and may not be able to continue to fund some existing portfolio companies).

The net result is that a variety of companies, close to profitability or well on the way to profitability, are being caught in the middle. A lot of these companies are good companies - they may not be the next google, but they can certainly create jobs and reach profitability, if they don’t lose the needed “little push” prematurely. In other words, they may not be “wealth creation tools” that Fred is talking about in his response, but they are perfect small businesses that the country needs.

Programs like techstars (http://www.techstars.og) and MIT VMS (http://vms.mit.edu) create tomorrow’s companies with zero or little financial resources. How about dropping a tiny drop of the stimulus fund into similar programs, or other ways to help build, grow and sustain small businesses?
Though there are a lot of VC capital in general, VC capital only flows into these who are likely to become the next Google. That is not to say that these companies who are not going to become Google are not valuable. To the opposite, they are extremely valuable to the society. They can create millions of jobs, help our economic recovery, and most importantly, help secure our future. They may not be the kind of companies that fit the VC model, but our country and our society should certainly welcome them, love to have them, and when they need a little bit push,  please don’t just walk away from them.

So please, Economic Stimulus Plan,  you can create or boost 10,000 startups with $1B. A lot of them will fail and a lot of them will survive. But none of them is going to be “giant wealth destruction machine” and each of them is going to  help build our future.

Unfortunately, I have not found any Java server that supports this yet. Tomcat chokes up quickly if you tunnel HTTPS messages (tried both Tomcat 5.x and 6.x). Other Java servers don’t even come close. Jetty is the furthest and closest to supporting it. Greg Wilkins even wrote two examples showing Jetty’s proxy support (ProxyServlet and AsyncProxyServlet, though both of them only partially work when I tried to run them on on Jetty 6.x and Jetty 7.x).

The main problem for all these servers is that they do not support HTTP Connect. We all know HTTP GET, and HTTP POST, and all servers support these common HTTP methods beautifully, except for HTTP Connect.

The problem with HTTP connect are two folds:

1. Most servers simply fail at even parsing an HTTP connect request, except for Jetty, let alone anything else.


2. Jetty can parse HTTP connect request (semi) successfully, but it does not seem to enable any further processing of HTTP connect request (such as reading from the request’s inputstream);

Problem No.1 is that HTTP connect request looks very different from other HTTP requests, and most servers do not take HTTP connect requests into consideration. When the browser is initiating an HTTPS connection via a proxy server, the browser will send the following request to a proxy server:


CONNECT some.server.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 Firefox/2.0.0.17
Proxy-Connection: keep-alive
Host: some.server.com


In contrast, a typical HTTP request would look like:


GET /a/b/c.html HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 Firefox/2.0.0.17
Host: some.server.com


Problem No.2 is that HTTP Connect requires a two-step handling. After sending out this request header, the browser will “halt” the request and wait to hear back from the network before sending out any content;

The proxy server should respond to the above request by trying to initiating a connection with the remote server (some.server.com at port 443 in the above example). If a connection is established successfully, the proxy server should respond to the browser by sending back:


HTTP/1.1 200 Connection Established


Then proxy server should wait. On the other side, once the browser receives “200″ status from the server, the browser will now send the actual HTTPS content to the request connection. Once the proxy server receives the content, it should send such content to the remote server. The remote server will then respond and such response needs to be “copied” back to the browser, which would appear as part of the “HTTP/1.1 200 Connection Established” message shown earlier.

I hope I am missing something here - if you know Jetty server or any other server that works well for HTTPS tunneling, please comment below!

Some useful links for more information on this subject:

Tunneling SSL Through a WWW Proxy, http://muffin.doit.org/docs/rfc/tunneling_ssl.html

Implement HTTPS tunneling with JSSE, http://www.javaworld.com/javaworld/javatips/jw-javatip111.html?page=1

Jetty bug tracker “Allow interception of CONNECT method to support proxy impls”, http://jira.codehaus.org/browse/JETTY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Jetty ProxyServlet, http://www.mortbay.org/jetty/jetty-6/apidocs/org/mortbay/servlet/ProxyServlet.html

First of all, the notion of having a CTO for USA is very exciting. It’s a job that I’d really want to have - I’m working on my resume right now!!!

More importantly than who will be the CTO is which industry this person should be coming from. I’d really really recommend the following three industries:

1. Information technology industry
2. Information technology industry
3. Information technology industry

Not because I’m from the IT industry, but rather because IT is the industry that the title of CTO is born from and IT is the industry that is leading the society in terms of not only technical advances, but rather more importantly, culture evolutions. Biotech and energy industries are all hugely important, and may produce far more important technological breakthroughs than the IT industry would be able to, but IT has become part of our culture (as proven in my blog entry The Common Culture Root of Web 2.0 and Barack Obama).

Part of the reason for Obama’s win is due to his campaigns usage of IT in building out grassroots support and reaching out to millions of people. The web and the internet, did wonders in politics!

Who would I nominate? Given that Jeremy does not allow self-promotion, let me just say that the 2nd best candidates are:

1. Mitt Romney (what? Did i actually type this out?)
2. Charles Vest (former MIT President. Disqualified because of lacking IT industry background, but a University president may not be a bad idea. Did I effectively nominated Larry Summers here?)
3. Marc Andreessen
4. VCs like Vinod Khosla are good choices (as a catogery, VCs are good pools to look into)

I am excited to announce the early beta release of Razor Optimizer, a JavaScript optimization tool for reducing code footprint and increasing runtime performnace. As a cross-browser web application itself, Razor Optimizer can be access either online as a service, or to be downloaded to run locally.

Razor Optimizer is based on a new approach for JavaScript optimization called “razor”. While other optimization techniques such as JS minimization and concatenttion are based on static lexical analysis, Razor uses dynamic runtime profile information to achieve breakthrough results of 60% to 90% savings.

Why Razor Optimizer?

It is safe to say that Ajax is the technology foundation for Web 2.0. There are several hundred Ajax toolkits in the marketplace and new ones are still emerging.

While Ajax is getting real popular over the web, what people may not know is that Ajax(JavaScript) code is becoming the top 1 or 2 factors to consider in terms of footprint and performance impact in relation to the overall site (or application). 40% to 70% of the footprint of today’s typical web 2.0 sites is JavaScript. For example, the front page of FaceBook contains 532KB JavaScript, 77% of the page footprint. Ajax toolkits have also become more sophisticated and bigger.

Developers are aware of the “code bloat” issue. Some developers choose to lower footprint by using shorter variable names and more compact code style. There are various optimization techniques available such as compression, JS minimization and file concatenation. All these are helpful, but none of them is helpful enough.

What can we do to bring Ajax to its full potential, and empower developers to use Ajax without worries?

Note that the problem is not new. Similar challenges exist for other programming languages. In early 2007, while studying Dojo performance, I blogged about “borrowing” approaches from other languages to optimize Ajax code(see Dojo Footprint and Ajax Performance Recommendation). At the time, I was hoping someone in the Dojo community would implement this. In late 2007 or early 2008, I remember seeing some research paper from Microsoft Research talking about something they call “Donoto” (unfortunately I couldn’t find any information about Denoto on the web. If you know it, please post it in comments).

Razor Optimizer is based on a new approach coming from such kind of new thinking. Its goal is to free developers from the worries of code bloat, and free users from JavaScript introduced browser freezing.

In one sentence, Razor Optimizer (hopes to) lights up the web!

Razor Optimization Features

As an Ajax application itself, Razor Optimizer offers the following features:

• Runs in any browser


• Works with any Ajax application and Ajax toolkit


• A built-in profiler that records and visualizes application runtime profile data;


• Full automated, no programming required


• Detailed result reporting with comparison to other optimization techniques


• Light up your app with 50% to 90% footprint reduction


• Reduce the number of network round trips

How It Works

Razor Optimizer itself is a web based JavaScript application that runs in any browser. It contains a server component and a client component. Razor Optimizer client is an Ajax application based on Dojo 1.1. Razor Optimizer Server is a Java web application that runs inside any Java Servlet container. The following figure shows the architecture of Razor Optimizer.

Razor Optimizer Architecture

Razor Optimization Case Studies

In general, Razor is able to reduce application footprint by 60% to 80%.
The followings present three different application examples. The three applications are:

1. American Airline’s web site (http://www.aa.com): this site uses PrototypeJS JavaScript library, one of the popular Ajax toolkits;


2. Razor Optimizer itself: Razor Optimizer is a Dojo 1.1 based JavaScript application;


3. jQueryUI demo (http://ui.jquery.com/functional_demos/): this is an application based on the popular jQuery library.

Table 2 shows optimization results for these three applications. Razor achieved 67%, 75% and 62% savings for them respective.

In comparison, Razor delivers significantly better results than other JavaScript optimization techniques. Using ShrinkSafe to optimize these three applications, the results would be 189KB, 568KB, and 86KB respectively (See Table 5). Razor further cuts down these numbers by half.

The Idea Behind Razor Optimizer
Razor is based on the following observations:

1. JavaScript functions are the basic low level building blocks of JavaScript code. Though typical JavaScript applications are made up of JavaScript files, functions are at a lower level than files because each JavaScript file is composed of JavaScript functions. While current JavaScript optimization techniques operates on a “file” level, performing optimization at the function level could yield much better result;


2. At any moment of time, the browser needs only one function because only one JavaScript function is executed at any moment of time.
   


3. Theoretically, the application would work fine if we download only one function at a time, right before the function is going to be called. Other functions are not needed. They can stay on the server side without being downloaded until they are going to be called. There is no need to download all the code up front, and there no need to download them at once;


4. If only one function needs to be downloaded and stay on the client side, we can achieve breakthrough savings in both download size as well as client memory/CPU footprint, resulting in significant performance improvements above any other techniques.
   

The basic idea of Razor is to “trim” the “not needed” functions and only download these functions that are necessary for a specific usage scenario. This “trimming” process is called “raze”. After the initial download, if a “razed” function is needed, Razor will download this function on demand in the background.

Wouldn’t downloading one function at a time be very slow? Indeed. However, if you package a bunch of related functions together and if this one “package” is enough to fulfill one or more use scenarios, the user wouldn’t notice any negative performance impact of incremental downloading.

So the key to this approach is to understand when/which function is called during different runtime scenarios. For example, if we know exactly which functions are called and when they are called during the initial application loading, we can trim all other code from the initial download without breaking the application. This would significantly save the initial download size and improve page loading performance.

The knowledge of “when/which function is executed” can be achieved by profiling the application. By recording the profile data, we can have accurate knowledge of the dynamic runtime behavior of the application beyond static lexical analysis for delivering breakthrough optimization results.

How to Use It

After you downloaded and installed Razor Optimizer (see instructions at GettingStartedWithRazor.html):

1. Start Razor server;


2. Open a browser instance and visit URL http://localhost:9090 to launch Optimizer UI;


3. Click “New Session” to start a new session. You may need to login. If you don’t have an account, register one;


4. Enter the URL of your application, for example, http://ajaxian.com. This URL must be accessible from the Razor Server instance you are using;


5. Razor will attempt to open a new browser window to launch your application. Make sure that you configured your popup blocker to allow it to so do.


6. Your application will be running in its own browser window. Just click around your application (try to stay on the same page though, because multi-page scenarios have not been tested enough for Razor Optimizer).


7. At the meantime, Razor is recording profile data in the background;


8. Click “Close and View Results” to finish profiling.


9. Click “Optimize” to configure optimization. From here, you can configure file concatenation, ordering, function preservation, etc.


10. Finally, click “Optimize it now” to perform optimization. Razor server will process your code and generate a report in the end that shows you optimization results. You can download the results as a ZIP file;


11. Deploy the ZIP file to your application, test it and iterate a few times to achieve optimal outcome;

Razor Optimizer Screen Shot

A sample optimization report would look like this.

Try It out

Razor Optimizer early beta is available for download. Try it out! Please comment below to let us know the problems you run into, complains or suggestions, etc.

Though the usage of JavaScript code can lead to significant better overall user experience, it can also bring problems if not used properly. Some of the common performance related problems are:

1. Sluggish network and runtime performance. It is common to see web pages that load several hundred kilobytes of JavaScript. The size of JavaScript libraries ranges from kilobytes to several hundred kilobytes, or even megabytes. Big footprint introduces not only longer download/parsing time, but also bigger client side memory/CPU footprint. For some browsers, parsing/processing large script can take an excessive amount of time (Firefox bug #313967);
2. The browser freezes from time to time. There are many cases that JavaScript code can slow down the entire browser instance. For example, too many JavaScript files that need to be loaded may cause excessive number of network round trips; the execution of a long running JavaScript function can block the browser from responding to user events until the function finishes, etc.

There are a variety of techniques people use today to optimize JavaScript performance. Some of popular ones are:

1. On-demand loading (lazy loading)

   Instead of loading all JavaScript files up front, loading them only when necessary can reduce the upfront network impact. A lot of JavaScript libraries provide such functionality, such as YUI loader and Dojo’s package system.

2. Concatenation

   Concatenation is an effective way to reduce the number of round trips. Instead of loading different JavaScript files using separate HTTP requests, concatenating these files into one file would enable all of them to be loaded using one HTTP request. Dojo ShrinkSafe and YUI Compressor are two popular tools that supports file concatenation.

3. Minimization (and Obfuscation)

   JavaScript programs are delivered to the client side as plain text where it is compiled on the fly and executed. However, there are two downsides of this approach. The first is code size. The source can contain materials (such as whitespace and comments) that are not necessary for code execution but rather for the purpose of aiding human readability of the code. Such materials have negative performance impact. The second side effect is lack of code privacy. Given that the code is delivered as plain text, someone could read it, learn our techniques, and may even gather hints from the source code on how to compromise our security.

   JavaScript minimization and obfuscation are techniques to deal with both issues. Minimization removes the comments and unnecessary whitespace from JavaScript source code. Obfuscation changes the names of variables, functions, and members to strings that are harder to understand (and typically shorter).

   JavaScript tools typically implement support for both obfuscation and minimization. Some of the popular tools are (see References):

   • Dojo ShrinkSafe
   • YUI Compressor
   • Dean Edward’s JS Packer
   • JSMin

Applying the above techniques, it is possible to achieve a footprint reduction of 20% to 50%.

1. Make Fewer HTTP Requests
2. Use a Content Delivery Network
3. Add an Expires Header
4. Gzip Components
5. Put Stylesheets at the Top
6. Put Scripts at the Bottom
7. Avoid CSS Expressions
8. Make JavaScript and CSS External
9. Reduce DNS Lookups
10. Minify JavaScript
11. Avoid Redirects
12. Remove Duplicate Scripts
13. Configure ETags
14. Make AJAX Cacheable

Table 1: Content Composition of Selected Web Sites

In both cases, the initial HTML text is only a small percentage of the page footprint (23% and 3% respectively). This is generally true for web pages today. Secondly, the biggest portion of both pages is JavaScript, at 42% and 77% respectively. It is not uncommon to find web sites today that JavaScript comprises 40% to 90% of the footprint.

Further, various researches concluded that the front end is where majority of the page loading time is spent for today’s web pages. For example, Yahoo’s Web Performance team studied some major web sites’ front page loading time as shown in table 2. The result show that, in average, only 5% to 20% of the page loading time is caused by server processing and network transfer of the initial HTML content while up to 90% of page loading time is spent processing the content: (Reference 2: http://yuiblog.com/blog/2006/11/28/performance-research-part-1/):

As a result, Yahoo team concluded a “performance golden rule” in reference 3: optimize front-end performance first, that’s where 80% or more of the end-user response time is spent.

In summary, for today’s web pages:

• The server time for generating HTML content and network transfer time for such content are only small factors in page performance, typically only 5% to 20% of the page loading time.


• Front end processing time can be as high as 95% of page loading time.


• HTML is only a small portion of the footprint while JavaScript can be a significant portion of the footprint, sometimes as high as 80% to 90%;


• JavaScript code performance can be the major performance influencer.

A good metric to gauge web performance is page loading time. Page loading time refers to the time from when browser issues the page URL request to the moment when the page is loaded, rendered and ready for user interaction. Page loading time is determined by three factors:

• Server processing time: the amount of time that the server takes to process a page request and deliver the response to the client;
• Network transfer time: The amount of time that it takes to transfer the content from one end point to the other end point;
• Front end processing time: the amount of time that the client (browser) takes to process the content it received, including parsing, loading additional resources when required and rendering.

Given that web applications are distributed across web server, network and web browser, all of the three factors play a role in performance. However, the relative importance of each factor is different, which is largely related to the web architecture.

Historically, the web architecture was server-centric. All (or almost all) intelligence stayed on the server side and there was very little intelligence on the client side. The browser requires very little “intelligence” besides acting as a “dumb display terminal”. Further, web content were mostly plain HTML pages that consume very little network resources to transfer. In this model, the performance bottleneck was typically on the server side and server processing time was the biggest performance factor. As a result, most of the earlier web performance optimization efforts focused optimizing server side processing, such as using more powerful servers, database tuning, optimizing server side logic, etc.

As web pages grew richer, the number of external objects, such as graphical images, included in web pages started to grow. Because external objects require network round trips, the impact of network transfer started to become more visible, especially when transferring content internationally. HTTP caching was adopted to alleviate the network impact. Further, content delivery services (CDN), which are mostly based on HTTP caching techniques, grew into an industry dedicated at improving network performance for delivering web content.

Over the last several years, we witnessed the so-called “Web 2.0” evolution. Driven by a need to deliver a richer user experience, the web’s architecture has shifted away from being 100% server-centric into an architecture that leverages both client side and server side processing power. Putting data and intelligence to where the user is at significantly improves user experience by reducing server round trips. As a result, in today’s web 2.0 environment, the client side is taking on more data and computation. According to Reference 1, from 1995 to 2008, the size of an average web page has increased 22 times, and the number of external objects per page has grown 21.7 times. From 2003 to 2008, the average web page grew from 93.7K to over 312K (233%) and the number of external objects in the average web page nearly doubled from 25.7 to 49.9 external objects per page. Because JavaScript is the only supported way to implement client side intelligence, today’s web applications tend to employ a significant amount of JavaScript code.

Consequentially, this Web 2.0 evolution significantly changed the comparative importance of web performance factors. For the first time, front end processing time is becoming the biggest factor in web performance while server side processing time and network transfer time are both becoming secondary.

Figure 1: The Changing Relative Importance of Performance Factors with the Evolution of the Web

More specifically, among front end processing, client side JavaScript code is becoming one of the top influencers on the overall performance due to the increasingly dependency of web applications on JavaScript.

“the hardest physical thing I have ever done. Even the worst days in the tours, nothing was as hard as that and nothing left me feeling the way I feel now in terms of sheer fatigue and soreness. I think I bit off more than I could chew, I thought the marathon would be easier…”.

It didn’t resonate with me at the time. In fact, I didn’t feel anything besides saying “wah, cool”. What I didn’t know (I’m sure Kaushal didn’t know either) is that he planted some seeds in me at the time that would only grow two years later.

In Boston where I live(Kaushal lives in LA), my friend Ying actually has been running marathon many times. I always admired her for such achievements. Every time when she encouraged people to run, I always thought “nanh, not me”.

I know myself - I was never a good runner. My body type is not built for running with a BMI of 27. I hated running long distance when I was in middle school. Over the last few years, I did do some running here and there along the river, only because i wanted to take some time to think of things. Further, I’ve never been able to run for more than 2-3 miles without stopping. 26 miles? It is just way out of my league.

In June 2008, Cliff (of LiteracyBridge, very cool non-profit startup) and I somehow got into talking about marathon. His background is similar to mine (never enjoyed running, never run more than 3 miles, …) but he did it. What I learned from him is “a non-runner’s guide to marathon”. Yes, that’s me - a non-runner.

So I dipped my toe into training. Two friends(Ying and Jana) were training for the September 2008 Toronto race. I joined them in the end of June. Normal marathon training takes about 16 weeks. So my time was a little bit short, but I figured that I am not trying to win the first place and I can drop out if it turns out to be too much, so I went for it.

The Training
The training was actually quite enjoyable, because marathon training schedules are all designed to take someone from 3 mile run to 26 miles in a gradual, incremental fashion. Every few weeks, the running mileage increases, but still within the limits of a normal human body. Such increases give a real sense of accomplishment that keeps one going.

I did have challenges almost all the time though. In the first month or so, my calves were very sore that I have to stop running from time to time. I thought my calves were injured. It turned out that it was probably just weak. After a month, the calves problem went away. The I ran into breathing problem, having pains below my right ankle, thigh problems…. one problem after another one. But nothing was serious to stop the training.

August 31 2008
On August 31 2008(four weeks before the race), I successfully completed a 21 mile run under four hours. I was very tired after the run, but my body felt good. There was no injury or pain. I felt for the first time that I can run marathon. That’s the time that I actually registered for the race.

September 7 2008

McDavid Ligament Black 425

Three weeks before the race: we were trying to run another 20+ mile run in the morning. I had too much wine the night before and went to bed fairly late (2am?). I didn’t feel good running. I kept telling my running partners that I “am very sleepy” during the run. Bad things happened then. After the 13th mile, I suddenly felt a sharp pain on the outside of my left knee. The pain was so severe that I couldn’t run anymore. I walked for 5 miles to finish the route. But I wasn’t too worried, thinking of it as a glitch that will go away if I’m better rested next time. My running partners told me to take Ibuprofen, and have plenty of rest.

September 17 2008
Typical training schedule ends after a couple of 20+ mile long runs, which would be sufficient to run the marathon. On Sept 17, I decided to do a 14-mile run to see whether my knee has fully recovered. I also put on knee braces for extra support. After ten miles, I felt early signs of knee problem again. I knew it would develop into sharp pains in a couple of miles. With only 10 days to go before the race, I started to worry whether I can run the marathon.

The problem I have is called “ITBS” (Iliotibial Band Syndrome), a very common problem for runners. After consulting various sources, I stopped running. Instead, I started taking Ibuprofen, doing ITBS exercises, and swimming every day, hoping to put the problem under control.

September 25 2008

With only three days to go, we went for the last run, a 2.5 mile short run. Both Jana and I didn’t feel good about our knees after this run. Fortunately we found some good strong knee braces, McDavid’s Ligament Black 425. This knee brace is so good that we both gained confidence again.

Racing Day - September 28 2008
Marathon races typically start at 7:30AM, and requires participants to line up one hour before that. Having to get up at 5AM killed me. But being together with so many runners, it was exciting. We crossed the starting line around 7:40AM. The route started at Toronto’s City Hall, then went down along the waterfront to the east. I felt fine besides being a little bit sleepy. while praying my knee is going to be OK.

After about 2-3 kilometers, my left leg started to feel numb, probably because the knee brace was too tight. Having problems this early is obviously bad. I slowed down, completely loosened the belts on the brace. Loosening the belts means taking a big risk in giving up a lot of of knee support. But I had no choice. After another kilometer or so, the worst happened. My knee started hurting. It may soon develop into sharp pains that would stop me from running.

This was not even 5 kilometers yet! I have to face the possibility of dropping out of the race. But not even completing 5 kilometers would be a real shame! While I resisted the idea of dropping out, I knew it would be unlikely that I’d be able to finish the race today. It was a bitter realization, and all what I could hope for was to run a decent distance worthy of my training.

So I tried to figure out ways that could help me last as far as I could. First of all, I tightened my knee brace belts to delay the knee pain from further development. Secondly, I tried to minimize the usage of my left leg. In fact, my left foot didn’t touch the ground except for a few toes, basically hopping/limping along by putting most of my weight and forces on my right leg.

With the new strategy, I finished 12 kilometers. Fortunately the knee problem didn’t seem to develop further. However, the unnatural running position made my body very tired. With 30 more kilos ahead, I knew the impossibility of finishing the run. Mentally I started to prepare for dropping out of the race at half marathon.

At 18th kilometer, half marathon runners were instructed to stay to the left of the road and marathon runners on the right side. 90% runners went to the left side. The right side was actually relatively empty. For some strange reason, I decided to stay on the right side of the road. Not sure what I was thinking at that moment. My right leg was really tired and I had to walk instead of running a few times to give my right leg a break. For the next several kilometers, every kilometer was a struggle. My body was very weak. I was struggling to fight off the idea of dropping out and getting this over.

After 26th kilo, it was as if my training started to kick in. I started to feel some strength coming back into my body. When I crossed 28 kilo, someone cheered “you’ve finished 2/3″. My mental state suddenly changed. At that moment, I realized that I will not drop out and will finish the race.

The rest of the journey was difficult, but nothing insurmountable. The last 1200 meters were actually quite enjoyable (given that so many friendly people were cheering for me). I crossed the finished line, and saw my running partners holding cameras towards me. Exhausted, but felt invincible.

In the End
I finished the run in 5 hour 35 minutes, a lot longer than I hoped for. However, I was thrilled to have finished the race without dropping out considering that I have to run on one leg most of the time and the mental torture associated with it. Self doubt is the worst enemy and I had it with me until I finished the 28 kilo. Yes, a lot of things in life depend on mental strength, rather on the sheer physical strength.

Physically, to be honest, I was exhausted after the race. However, I could have run another couple miles though, because in the end, running was just something to do. I hit the wall early - from the 15th to the 25th kilometer. That was the time I was most exhausted, had very little faith in myself and couldn’t see the light in the end of the tunnel. It was dark as the deepest night even in the end of the 27th kilo. But the moment I turned into the 28th, I knew I got it.

I can see myself run better when someone was cheering for me. My friends, running partners, family and the friendly Toronto people were doing an incredible job at cheering for me. Big thanks!

In retrospect, I wasn’t totally well prepared. I have yet to develop more strength around my left knee to support running a marathon. Consequences? My left knee still hurts. One of my left toe nails was full of blood. I also discovered my knee brace has cut a half ring into my skin, right behind my knee cap. Nevertheless, it felt really good!

If I can do it, so can you!

For example, when you write an inner function, you know that you can access the local variables defined in the outer function as if they were defined locally. You can also access the global variables. -Why? How does the host environment resolve such variables?

Another example: When you pass arguments to a function, you can access these arguments as if they were locally defined variables. How does this work?

A slightly more involved example that developers must have seem similar code a lot but may not know the “why”:

function outerFunc(outerArg){
   var localVar = 100;

   function innerFunc(innerArg){
      localVar+=100;
       return (outerArg +innerArg + localVar);
    }

   return innerFunc;
}

 var globalVar = outerFunc(200);
 alert(globalVar(300));	//this displays 700
 alert(globalVar(300));	//this displays 800
 globalVar = outerFunc(200)
 alert(globalVar(300));  //this displays 700 again

Why would the 2nd alert box show 800 (means the value of localVar is retained from the first call) while the third alert displays 700 (the value of localVar is not retained from previous calls)? How does it work?

Key Concepts
1. Execution Context:
   An execution context is an abstract concept used by the EcmaScript specification and can be conceived (and even implemented) as a set of objects with properties, though not publicly accessible, that encapsulate the context in which a piece of JavaScript code executes. The JavaScript code would rely on its execution context for things like variable resolution and scoping.

   All JavaScript code executes in an execution context. Global code (code executed inline, normally as a JS file, or HTML page, loads) gets executed in a global execution context (in a browser, the global context is typically the window object), and each invocation of a function (possibly as a constructor) has an associated execution context. Code executed with the eval and setTimeout functions also gets a distinct execution context.

   When a JavaScript function is called, it enters an execution context. If another function is called (or the same function recursively), a new execution context is created and execution enters that context for the duration of the function call. When that called function returns, control returns to the original execution context and the just finished execution context is available for garbage collection except for cases like closure. Thus running JavaScript code forms a stack of execution contexts.

2. Activation Object and Variable Object :
   
   
   
   1. Activation Object:
      When an execution context is created, an Activation Object is created. The Activation Object can be considered as a normal JavaScript object with accessible named properties, except that it has no prototype and it cannot be directly referenced by javaScript code.This Activation Object is used for storing context related information such as call arguments and variables, etc. so that they are accessible to the new execution context (see more info on this later in this post).
      
   
   
   2. Variable Object and Variable Instantiation:
      ECMA Specification refers to a “Variable Object” for variable instantiation. “Variable Instantiation” is a process that takes place when the JavaScript host environment processes a piece of script so that it can be executed but before executing the script. In this process, the JavaScript engine prepares(”instantiates”) the local variables, local functions declarations, and arguments to the function call etc. so that these variables are accessible during execution.

      The way that variable instantiation works is to instantiate each of the function’s formal parameters, local variables and inner function declarations as named properties of the Variable Object. In the process, named properties of the Variable object are created for each of the function’s formal parameters. If arguments to the function call correspond with those parameters, the values of those arguments are assigned to the properties (otherwise the assigned value is undefined). If there is an inner function declaration, a function object is created. This function object is assigned a property of the Variable object with name corresponding to the function name used in the function declaration. The last stage of variable instantiation is to create named properties of the Variable object that correspond with all the local variables declared within the function.

      The properties created on the Variable object that correspond with declared local variables are initially assigned undefined values during variable instantiation, the actual initialization of local variables does not happen until the evaluation of the corresponding assignment expressions during the execution of the function body code.

      However, it is very important to point out that the Activation object is used as the Variable object. Though conceptually they are called out as different objects, they are the same object in reality. This is important as you can see quickly in “scope and scope chain” and “variable resolution” later on.

      It is the fact that the Activation object, with its arguments property, and the Variable object, with named properties corresponding with function local variables, are the same object, that allows the identifier arguments to be treated as if it were a function local variable.



3. Scope, Scope Chain and Variable Resolution:
   Each execution context has an assigned scope when created. A scope can be thought of as an “object” that is associated with a particular execution context (this scope object is actually the Activation Object we mentioned above). A scope chain consists of a list (or chain) of such objects. The scope chain of an execution context is a chain of objects with the current “scope” object on the top, the “scope” object of the calling execution context as the 2nd object on the top, and so on, with the last “scope” object of the chain being that of the global execution context.

   What do scope and scope chain do? They are used for variable resolution. When some JavaScript refers to a variable "foo", the host environment will try to resolve this variable. This resolution process is against the scope chain of the current execution context. First, it will search to see if there is a variable with the same name in the current scope. This is done by checking to see if the current “scope” object has such a named property. Remember that we mentioned Activation Object and Variable Object are the same object, and local variables (including inner function declarations, and function arguments) are instantiated as named properties of the Variable object during variable instantiation. So if the “foo” variable is defined in the local execution context, there must be a property of the Variable object named “foo”. If such a named property is not found, it means this “foo” variable is not defined here. The resolution process will now go down the scope chain and check against the 2nd “scope” object and so on until such such a named property is found or otherwise an “undefined” error happens

   (BTW: Prototype chain is always part of property resolution process and no difference here either. The normal prototype chain lookup process applies when looking for a property with a specific name from a “scope” object: If no such property is found on the object itself, the prototype object will be searched. Still not found, the prototype of the prototype object will be searched. Until either the property is found or the end of the prototype chain is reached).

   Important to point out: each function object has an internal property called [[scope]] (see more info on this later in this post) that consists of a list (or chain) of objects. This [[scope]] property can not be directly referenced by JavaScript code. When the function object is created, its internal [[scope]] property is assigned to the execution context in which this function object is created. This execution context has its own scope object and so on. In the end, the [[scope]] property is associated with a scope chain with the execution context in which the function object is created being on the top.

   The scope chain of the execution context of a function call consists of the list referred to by the [[scope]] property of the corresponding function object and the Activation object created for this function call. The activation object is at the front of the chain (or the top of the list).
   

4. Automatic Garbage Collection:
   Yes, automatic garbage collection is not a Java specialty. EcmaScript uses automatic garbage collection too. If an object becomes un-referable (by having no remaining references to it left accessible to executing code), it becomes available for garbage collection and will at some future time be destroyed and any resources it consumes freed and returned to the system for re-use.

   This would normally be the case upon exiting an execution context. Any objects created within the exited execution context, including function objects, would no longer be accessible and so would become available for garbage collection. However, Closure is the exception.

5. Closure:

A closure is an expression (typically a function) that can have free variables together with an environment that binds those variables (that “closes” the expression). A closure is formed by returning a function object that was created within an execution context of a function call and assigning an accessible reference to that inner function. The accessible reference can be established by directly assigning the returned function object to a global variable, a property of a globally accessible object or an object passed by reference as an argument to the outer function call, etc.

In the code example above, line “var globalVar = outerFunc(200);” calls the outer function "outerFunc". This call returns an inner function object and this returned inner function object is assigned to a global variable called globalVar. As a result, a closure is formed here.

6. Summary and the Global Execution Context

   The key concepts of execution context can be summarized using the following illustrations (assuming the function is named "foo"):

      The Execution Context of a call to function "foo":
              . Activation object
              . Variable object
              . Scope chain
   

   The [[scope]] property of function object “foo” is:

       foo.scope:
             = the scope chain of the execution context where "foo" is created
   

   Further, the relationship between the above objects are:

   
      The Execution Context of a call to function "foo":
            .Activation object: = Variable object
                    .arguments
                    .local variables
                    .local function declarations
            .Scope chain:
                        = Activation object + foo.scope
   

   The global execution context gets some slightly different handling:
   1. As it does not have arguments so it does not need a defined Activation object to refer to them;
   2. The global execution context does need a scope and its scope chain consists of exactly one object, the global object itself (window object).
   3. The global execution context does go through variable instantiation just like any other context;
   4. The global object itself is used as the Variable object, which is why global functions and variables become properties of the global object.

How Does A JavaScript Function Get Executed?

The JavaScript engine goes through several steps in calling a JavaScript function (say the function is named "foo" for reference purposes):

1. First of all, it creates a new Execution Context for this function call. The creation of an Execution Context follows the following steps:
   1. Create an Activation Object;
   2. Create an arguments object with length and callee properties specified. This argument object is an array-like object with integer indexed members corresponding to the arguments passed to the function call, in the order of their appearance. It also has length and callee properties instantiated. Next, a property named "arguments" is created for the Activation Object and a reference to this arguments object is assigned to this property;
   3. Variable Instantiation: assign local variables, inner function declarations and declared function parameters as such named properties of this Activation Object, with value being “undefined” for local variables and non-instantiated function call parameters (more on the values later, and also more on how functions are instantiated and assigned [[scope]] property later).
   4. Assign the “this” keyword (more on "this" keyword later);
   5. Assign “scope” and “scope chain” to this execution context:
      
      
      
      • “scope” = the Activation Object:
      • “scope chain” = the Activation Object + the chain referred to by the [[scope]] property of this function object “foo”.

   Now the execution context of this function call is created and we are ready to call the function.

2. Call function “foo” and executes its code line by line:
   
   
   
   • For each variable that the execution process runs into, resolve it according to the variable resolution rule by looking at the local Activation object first, then the calling execution context’s Activation object, and so on, until the end of the scope chain which should be the “Activation Object” of the global execution context (a side note: for performance reasons, you can see why referencing a global variable using window["variableName"] would be better than using "variableName" directly);
     
   
   
   • For each local variable (remember we said earlier that their values are “undefined” during variable instantiation), evaluate the variable’s assignment expression (if there is one) and assigns the result to it (actually, assigns the result to such a named property of the Activation Object);
     
   
   
   • If the execution process runs into a function call (let’s call it function “foo2″), a new execution context (let’s call this “context foo2″) is created for this function call. In “context foo2″:
     
     
     
     1. a new Activation Object (”Activation object foo2″) is created;
     
     
     2. Variable Instantiation is performed(using the Activation object(”Activation object foo2″) as Variable object);
     
     
     3. The scope chain of “context foo2″ is (”Activation object foo2″+ the scope chain of “foo”);

     4. During the variable instantiation for this function call, if a function declaration (let’s call this function “foo3″) is found, a new function object (”foo3″) is created. a property named as the declared function’s name with value being this newly created function object will be added to the Activation object.

        More importantly to point out, the [[scope]] property of this newly created function object "foo3" is the scope chain of the execution context where the instantiation happens - which is “context foo2″ in this case. So "foo3.scope" is (”Activation object foo2″+ the scope chain of “foo”);
        

     
     
     5. Eventually the function is called. Upon returning from this call, execution continues to the next line of function "foo";
     
     
     
     
   
   
   • Finally, this call to function "foo" completes and we return to the callee. At this moment, unless a closure is formed, this execution context is available for garbage collection.
     
   
   
   
   

Function Instantiation

In JavaScript, “functions” are objects. Depending on how a function is defined, there are three ways to instantiate a function object:

1. from function declaration during variable instantiation:
   If a function declaration is found during the process of variable instantiation, a function object will be created. The Activation Object will have a property whose name is the name of the function and whose value is the created function object. Further, This created function object will have its [[scope]] property assigned to be the scope chain of the execution context in which this function object is created.
   For example, in the following code snippet:

          function outerFunc() {
             var var1=10;
             function MyFunc1(){
                    return  var1=var1+1;
              };
   
             return MyFunc1();
           }
   
          alert(outerFunc()); //displays "11".
   

   When the host environment is going to execute line alert(outerFunc());, in particular, when it is going to call outerFunc(), it will create a new Execution Context for this call (let’s name this new execution context outerFuncContext1 for reference purpose). During the creation of outerFuncContext1, it will instantiate variables. Both "var1" and "MyFunc1" are instantiated during this variable instantiation. Upon variable instantiation, the Activation Object associated with outerFuncContext1 will have a property named "var1" whose value is “undefined”, and a property named "MyFunc1" whose value is a function object created here. Further, the [[scope]] property of this function object is assigned to be the scope chain of outerFuncContext1.
   



2. from the evaluation of a function expression during code execution.
   Consider the following snippet:

          function outerFunc() {
             var var1=10;
             var var2=function(){
                    return var1=var1+1;
              };
   
             return var2();
           }
   
          alert(outerFunc()); //displays "11".
   

   When the host environment is going to call outerFunc(), it will create a new Execution Context for this call (again, let’s name this execution context outerFuncContext1 for reference purpose). During the creation of outerFuncContext1, it will instantiate variables. Both "var1" and "var2" are created during this variable instantiation. Upon variable instantiation, the Activation Object associated with outerFuncContext1 will have a property named "var1" whose value is “undefined”, and a property named "var2" whose value is also “undefined”.

   Then the host environment goes on to execute the call to outerFunc(). During execution, first it will assign 10 to var1. Then it will evaluate the function expression related to var2. During this evaluation, a function object is created and assigned to variable var2. Further, the [[scope]] property of this function object is assigned to be the scope chain of the execution context in which this function object is created, outerFuncContext1.
   



3. from invoking the Function constructor:
   In this case, the function’s [[scope]] property always refers to the scope chain of the global execution context, which contains only one object, the global object. An example is:

             var y=100;
             var multiply = new Function("x", "return x * y;");
             alert(10); //displays 1000.
   

   In the above example, variable y is being searched in the global context. If there is no global variable named "y", an error will be thrown.
   

4. Summary of function [[scope]]:
   In summary, every function object has an internal [[scope]] property that refers to a scope chain. This property is very important for figuring out the scope of execution context and thus variable resolution, etc:
   
   
   
   • If the function object is created from a Function constructor, the [[scope]] property always refers to one object only, the global object. On browsers, it is the "window" object.
   
   
   • If the function object is created from either function declaration or function expression evaluation, its [[scope]] property always refers to the scope chain of the execution context in which the function object is created.
   
   

The "this" Keyword

One of the most powerful JavaScript keywords is "this" and I am sure that every developer has used it many times. However, it is not straightforward to figure out what it points to.

"this" is typically assigned an object that it points to during the process of creating a new execution context. If the value assigned refers to an object, then property accessors prefixed with the "this" keyword points to the properties of that object. However, if no object can be assigned to it, then the "this" keyword will point to the global object by default.

The next question is how do we know when/whether an Object will be assigned to "this" and who that Object is. For example, consider the following code:

      function redColor() {
                      this.color= 'red';
              }
     alert(redColor.color); //shows "undefined"
     var aa=redColor;
      alert("color="+aa.color); //shows color= undefined

What does not “color” become a property of "aa"? Further, functions are objects in JavaScript - why wouldn’t "this" refer to the function object “redColor” itself?

The rule to remember is that "this" always refers to the “owner” of the function we’re executing. In other words, keyword "this" always refers to the object that the containing function is a method of.

In the above example, the function "redColor" is not a method of object "redColor", so "redColor.color" returns “undefined”. Further, function "redColor" is not a method of some object called "aa" either. So "aa.color" also returns “undefined”.

However, according to our understanding of how variable instantiation works, "redColor" is instantiated as a property of the global object. The global object has a property called "redColor" and the value of the property is the "redColor" function object. In the end, "function redColor" is actually a method of the global object. According to the rule above, "this" should be referring to the global object.

In other words, if we execute function "redColor", we are actually assigning a “color” property to the global object with the value of “red”. If you run the following code:

	function redColor() {
              this.color = 'red';
      }

         redColor();
	 alert("window.color="+window.color);//shows window.color=red

The alert box shows “window.color=red”!

If you attach function "redColor" as a method of an object using obj.method=redColor or obj.prototype.methodName=redColor, the keyword "this" will correctly point to our "obj". However, there is one case that people tend to make mistake, like the following:

          <div id="mydiv" onclick="redColor();">This is my div</div>

           var div=document.getElementById("mydiv");
           div.onclick=redColor;

The "eval" and "setTimeout" Functions
Function "eval" and "setTimeout" have their own distinct execution context, as mentioned briefly ealier. "setTimeout" always assumes the global execution context. For "eval", here is the quote from ECMASpecification:

“When control enters an execution context for eval code, the previous active execution context, referred to as the calling context, is used to determine the scope chain, the variable object, and the this value. If there is no calling context, then initializing the scope chain, variable instantiation, and determination of the this value are performed just as for global code.

The scope chain is initialized to contain the same objects, in the same order, as the calling context’s
scope chain. This includes objects added to the calling context’s scope chain by with statements and
catch clauses.

Variable instantiation is performed using the calling context’s variable object and using empty
property attributes.

The this value is the same as the this value of the calling context.”

In short, you can think of “eval” assuming the exact same execution context as the calling code.

Further Readings and References

1. “Microsoft AJAX Library - JavaScript Execution Context”, http://www.exforsys.com/tutorials/microsoft-ajax/javascript-execution-context/1.html; (quick note: this doesn’t really have anything to do with Microsoft Ajax library. Further, “AJAX” should be spelled as “Ajax”. The “AJAX” spelling is so 2005!);
   


2. “Javascript Eval Scope Namespace Execution Context”, http://adrenalin.wordpress.com/2006/06/12/javascript-eval-scope-namespace-execution-context/;


3. “The Magic Eval”, http://nerd.metrocat.org/2005/09/the-magic-eval;


4. “The this keyword”, http://www.quirksmode.org/js/this.html;

“Javascript Closures”, http://www.jibbering.com/faq/faq_notes/closures.html(note: this is a master piece!);

First of all, I was glad to find out that I haven’t found Chrome breaking any web application yet, especially Ajax applications. I was a little concerned about this, given that the Chrome cartoons say “Javascript runs in its own thread”, which is different from the threading model today. 

For example, Razor Profiler is a fairly Javascript-heavy web application that I wrote to perform JavaScript profiling and Ajax performance analysis. It includes tens of thousands of lines of JavaScript code on the client side, and employs a lot of “tricks” to make a web application deliver similar performance characteristics to native applications. -Razor Profiler works well on Chrome. 

I also tried a few applications on Dojo, ExtJS and jQuery. All worked well without a glitch. 

After the initial concern eliminated, now I was able to see the noticeable performance improvement comparing to any other browsers. I am a constant user and tester of Safari, FireFox and IE. Chrome beats any of them hands down. 

a. It is clearly faster and smoother to open browser window, close browser window, navigate to new sites, etc on Chrome than any other browser. Chrome delivers a very smooth browsing experience. 

b. For Ajax applications, yes, Ajax code runs much faster on Chrome. For example, Razor Profiler needs to serialize collected profile data on the client side. There are a lot of data to serialize, typically creating a few hundred kilo-bytes of JSON stream to the server. This serialization process can easily take 5 to 10 seconds on any other browser. On Chrome, the amount of time is probably half of that. 

So overall, Chrome is impressive! It certainly raised the bar.