“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. 

1. JVM Byte Code Size Limit Problem

On rare occasions, you will see exceptions like the followings from Rhino when processing JavaScript files:

Exception in thread “main” java.lang.IllegalArgumentException: out of range index

at org.mozilla.classfile.ClassFileWriter?.add(ClassFileWriter?.java:541) at org.mozilla.classfile.ClassFileWriter?.addLoadConstant(ClassFileWriter?.java:601) at org.mozilla.classfile.ClassFileWriter?.addPush(ClassFileWriter?.java:837) at org.mozilla.javascript.optimizer.BodyCodegen?.visitSpecialCall(Codegen.java:2571) at org.mozilla.javascript.optimizer.BodyCodegen?.generateExpression(Codegen.java:1763) at org.mozilla.javascript.optimizer.BodyCodegen?.visitSetProp(Codegen.java:3743) at org.mozilla.javascript.optimizer.BodyCodegen?.generateExpression(Codegen.java:2118) at org.mozilla.javascript.optimizer.BodyCodegen?.generateStatement(Codegen.java:1660) at org.mozilla.javascript.optimizer.BodyCodegen?.generateStatement(Codegen.java:1510) at org.mozilla.javascript.optimizer.BodyCodegen?.generateBodyCode(Codegen.java:1181) at org.mozilla.javascript.optimizer.Codegen.generateCode(Codegen.java:285) at org.mozilla.javascript.optimizer.Codegen.compileToClassFile(Codegen.java:157) at org.mozilla.javascript.optimizer.Codegen.compile(Codegen.java:67) at org.mozilla.javascript.Context.compileImpl(Context.java:2327) at org.mozilla.javascript.Context.compileString(Context.java:1323) at org.mozilla.javascript.Context.compileString(Context.java:1312) at org.mozilla.javascript.tools.shell.Main.loadScriptFromSource(Main.java:500) at org.mozilla.javascript.tools.shell.Main.processFileSecure(Main.java:439) at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:406) at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:397) at org.mozilla.javascript.tools.shell.Main.processFiles(Main.java:181) at org.mozilla.javascript.tools.shell.Main$IProxy.run(Main.java:102) at org.mozilla.javascript.Context.call(Context.java:540) at org.mozilla.javascript.ContextFactory?.call(ContextFactory?.java:447) at org.mozilla.javascript.tools.shell.Main.exec(Main.java:164) at org.mozilla.javascript.tools.shell.Main.main(Main.java:142)

Here are a few posts you can find when you do a web search that are related to this issue (though don’t seem to offer a solution):

• http://markmail.org/message/ieuv5bnlddhufmdm#query:java.lang.IllegalArgumentException%3A%20out%20of%20range%20index+page:1+mid:ortmi3uehrzdrhcq+state:results
• http://trac.dojotoolkit.org/ticket/2896

This can be extremely frustrating. For example, if you are a Dojo ShrinkSafe user, you know ShrinkSafe works because you have used it millions of times on many projects successfully. But on a certain situations, you will run into the above problem. When you search specifically for this ShrinkSafe problem, here is the best that I can find:

“While it’s not recommended that you develop 2MB JS files, it seems that it *does* happen, and it’s about the time that your files get this large that a project (naturally!) turns to the Dojo compressor. Unfortunantly, the default set of arguments doesn’t hold up to a file this big, and strange exceptions result. Here is a modified recipe for use with the kinds of files that really, *really* need the Dojo compressor:
java -Xmn100M -Xms500M -Xmx500M -jar custom_rhino.jar -opt -1 -c HUGE.js > smaller.js
”

This is not very helpful in my own experience. First of all, there are tons of reasons that Rhino needs to process big JavaScript files (for example, you want to use Rhino to analyze a bunch of JavaScript files concatenated together). Secondly, very little explanation is given about this command line “magic”. Thirdly, this command line “magic” seems to be misleading because the problem is not related to JVM memory limit (no need to do -Xms500M -Xmx500M in my experience).

The source of the problem is not your code, not Rhino, but rather a Java language limit. See http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html, section 4.10:

“The amount of code per non-native, non-abstract method is limited to 65536 bytes by the sizes…”

Rhino implemented correctly by sticking to the Java language specification. In fact, you can see the following comments from <code>org.mozilla.classfile.ClassFileWriter<code>:

if (attrLength > 65536) {
// See http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html,
// section 4.10, “The amount of code per non-native, non-abstract
// method is limited to 65536 bytes…
throw new ClassFileFormatException(
“generated bytecode for method exceeds 64K limit.”);
}

The Dojo ShrinkSafe issue is fundamentally caused by this problem. Any other software that relies on Rhino will have this problem too.

2. So What Is the Solution?

The short answer is, well, there is no solution, if you rely on Rhino to compile JavaScript into Java code. Well, Java code has to subject to the 64KB Java language limit.

If you are in desperate need for a solution, you might try to “pre-process” your JavaScript code by breaking apart large JavaScript methods into a bunch of smaller methods, which may yield smaller than 64KB Java byte code for each compiled method. -Thought this approach looks really painful.

However, if you are not using Rhino to compile JavaScript to Java, there are easier ways to get around the problem. Rhino does not have to “compile JavaScript to Java code”. You can configure Rhino to run at an “Interpretive mode”. Given that there is Java byte code involved at all, this limit naturally does not apply. This is simple to do. It takes one line of code:

context.setOptimizationLevel(-1);

The above set the Rhino Context object to “interpreative” mode. See Rhino Optimization Level for detailed information.

3. Is it time for us to treat the 64KB JVM limit as a bug, rather that a Java language spec item?

In the world of JavaScript, well, it is not usual to have methods that far exceeds the 64KB limit. For example, it is very common these days for JavaScript libraries to wrap a lot of functions inside one parent function for the sake of encapsulation and scoping. For example, jQuery wraps all code inside one function block (function(){…})(). Other JavaScript libraries like Dojo use similar techniques too. In such situations, it is fairly easy to exceed the 64KB limit when compiled into Java byte code.

For dynamic languages, especially languages that developers tend to nest functions inside functions (”inner function”), the 64KB limit seems to be awfully low.

Of course, this problem is not unique to JavaScript developers. For example, JSP developers can easily run into this problem too. See http://forums.sun.com/thread.jspa?threadID=472929&messageID=2296445 for an example.

Interesting enough, bug 4262078 at bugs.sun.com, “Maximum method size is too small (64Kb)“, is exactly on this issue. See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4262078. The bug was submitted in 1999. Nine years later, in 2008, we are still not sure whether this will be fixed.

What Is it?

Razor Profiler(beta) is a web-based Ajax profiling tool to help web developers understand and analyze the runtime behavior of their JavaScript code in a cross-browser environment. Razor Profiler
can be access either online as a service; or be downloaded to run locally. Some Razor Profiler screen shots are shown below:

Files Tab

Top Call Stacks

Call Stack Visualization

Why Razor Profiler?

The amount of JavaScript code on the client side is increasing significantly with the growing popularity of Ajax and Web 2.0.
Web developers rely on JavaScript heavily these days in order to deliver a richer user experience.
Including a either home-grown or third party JavaScript library and application specific code, today’s web applications can easily have several thousand lines of JavaScript code, or even tens of thousands of lines.
The footprint of client side JavaScript
can range from tens of kilobytes to hundreds of kilobytes. This amount of JavaScript can do magic to application functionality and user experience, but they also introduce many questions.

As an application developer:

• 
  How do you measure the runtime behavior of your code on the vast array of client platform and browser combinations?
  


• 
  Do you know why the same code works well on one browser but performs very poorly on a different browser?
  


• 
  Do you know whose code is causing problems, yours, or a third party library?
  


• 
  Do you know exactly where is the performance bottleneck?
  

However, there is no easy way to obtain the answers to the above questions. It is difficult to study the runtime behavior of Javascript applications in a cross-browser environment:

• Different browsers (Internet Explorer, FireFox, Safari, etc) have different runtime behaviors. The same code can behave very differently on different browsers;
• Lack of tooling that supports JavaScript debugging and profiling. JavaScript has evolved from being perceived as a “toy language” to be a heavily used mainstream programming language for writing web applications, but JavaScript tooling has not caught up yet;

Razor Profiler aims to help solve this problem. Razor Profiler is JavaScript profiling tool
that aims to make it really easy for web developers to profile their Ajax code in a cross browser
environment.

Razor Profiler Features

Razor Profiler
automates JavaScript profiling:

• Automation: no application code change required. Razor Profiler automatically collects all the necessary data and presents them to web developers for analysis.
• Runs on any browser: web developers can profile any JavaScript application on any browser. There is nothing to install on the client side.
• Rich lexical analysis: Razor Profiler presents rich lexcial information about the application, such as file information (number, response status, size, mimetype, percentage, etc),
  tokens (size, file, percent, count), and functions (size, file, name…), etc;
• Profile scenario recording: Razor Profile enables web developers to selectively record the scenarios that they are interested in. Only recorded scenarios will be used in analysis.
• Call stack analysis: for each recorded scenario, Razor Profiler presents all the call stacks in the order of their occurence. For each call stacks, web developers can drill into it to find out
  the duration of the stack, all the function calls of this stack and the duration of each call.
• Function analysis: For each JavaScript function in the application, Razor Profile presents the number of times it has been invoked, the duration of each invocation, and the call stacks that invoked this function.
• Data visualization with graphing and charting: Razor Profiler presents top call stacks, top function calls of each stack, top recorded scenarios, etc. using visual charts and graphs to help web developers
  better understand the runtime behavior of their application. For example, each call stack is visualized as an intuitive Gantt chart.

some Razor Profiler screen shots are available here.

How Does Razor Profiler Work?

Razor Profiler
composes of a server component that runs inside a standard Java EE Servlet engine, and a JavaScript-based client component that runs inside any browser. Once you have Razor server started, you can profile your JavaScript application by entering the start URL of your application into Razor Profiler and run through your test scenarios.
Razor Profiler will automatically record data and visualize them for your analysis. There is no client side installation, browser configuration change or application code change required.
In order to achieve this, Razor Profiler goes through five different phases:

• 
  Application retrieval: Once a web developer enters the application start URL into Razor Profiler, Razor Profiler client component (”the client”) will send this URL to Razor Profiler server component (”the server”).
  The server performs the actually retrieval of this URL. After additional server processing (such as lexical analysis and code injection, see below), the retrieved content is sent to the client side to be displayed in a new browser window. For the developer point of view, the application is launched and running
  in this new browser window.
  
  In this process, Razor Profiler Server is acting like a “proxy server”. But it is not really a “proxy server” and there is no need for developers to re-configure their browser proxy settings.
  


• 
  Lexical analysis:
  Once the server retrieves the application URL, it performs lexical analysis of the returned content by identifying and analyzing JavaScript files, functions, and tokens,etc. The result is sent to the client
  for display.
  


• 
  Code injection: Upon lexical analysis of JavaScript code, the server injects “probe” code into the application’s JavaScript sources before returning them to the client. These injected “probes” enable
  automatic collection of application runtime data, and saves developers from doing so manually.
  


• 
  Runtime data capture: Once the application’s JavaScript code is running on the client side and as developers run through desired profile scenarios, the injected “probes” automcally
  collect all the necessary data to Razor Profiler Client.
  


• 
  Data analysis: When the developer finishes recording scenarios and starts data analysis, Razor Profiler client performs analysis of all the collected data and presents the results.
  

How To Get Razor Profiler?

Just go to http://www.razorspeed.com
and download it. Follow the installation instructions to install Razor Profiler server. Or, you can try it online as an online service.
Feel free to post comments at Razor Profiler online forum

In late 2007, OpenAjax Alliance formed Runtime Task Force (http://www.openajax.org/member/wiki/Runtime) to address this community concern. The goal is to collect, articulate, and prioritize key issues from the Ajax community, and communicate them to browser vendors. This will help educate the community in large, help browser vendors better plan for their product roadmap, and help developers better use Ajax.

There are other great rich Web UI technology initiatives such as W3C’s HTML5, CSS3 and SVG. The OpenAjax browser wish list is not intended to compete with these initiatives, but instead complements them by capturing and communicating the views of the web development community (the folks who are “users” of Ajax techniques).

The Process

OpenAjax Runtime initiative used a two phased process. A special wiki site <a href=”http://www.openajax.org/runtime/wiki/Main_Page http://www.openajax.org/runtime/wiki/Main_Page] was set up to facilitate communication and collaboration.

In Phase I, OpenAjax Alliance collected an initial list of feature requests. This is largely done by researching blogs, meetings with OpenAjax members and Ajax experts, and interviewing leading Ajax toolkits.

The initial wish list was announced in April 2008 for community review and feedback. A group of industry experts were being actively approached for feedback (see <a href=”http://www.openajax.org/runtime/wiki/Phase_I_Voting” title=”Phase I Voting Phase I Voting wiki page]).

Phase II started in May. The Alliance re-organized the feature lists based on Phase I results. Phase II wish list was put into voting in June. Voting was open to the general community. For each feature request, a voter can vote from 0 to 10 to indicate how strongly the voter feels the need for this request (10 being the most important).

The voting ended on July 13th 2008.

Feature List Summary

A total of 55 features were written up by various people in community. These writeups typically cover areas such as what the feature is, background, why the feature is important, possible solutions/recommended approaches for this feature, references, etc.

As a result of community feedback, some features are classified into “InActive”. For Phase II voting, there is a list of 37 active features. The current feature request list is:

Security features

• Better Security for Cross-site Scripts
• Stronger Cross-site Request Forgery Protection
• Better IFrames Better Sandboxing
• Native JSON Parsing

Client-server communications features

• “The Two HTTP Connection Limit” Issue
• “Persistent Connections” Issue
• XHR Connection Length Advice
• Synchronous XHR Enhancements

HTML5/W3C features

• 2D Drawing/Vector Graphics
• Video and Audio
• Offline Support
• Mutation Events
• XPath Support
• Component Model XBL HTC

CSS features

• Gradient Fill
• Blur Effect

Rendering/interaction/event handling features

• Better Support for Rich Text Editing
• Better APIs about positioning and styling
• Better UI Layout Support
• IE 6 and IE 7: “overflow: auto” problem
• Event Transparency API
• Event notification for “content overflow”
• Drag Drop Copy Paste
• Override Back Button Event
• Browser “Unresponsive Mode” Enhancements
• Enhanced support for dialogs

Performance features

• “Array” Operation Performance In All Browsers
• HTML DOM Operation Performance In General
• Matching Element Against CSS Selector

JavaScript features

• IE: Array’s Can’t Be Usefully Sub-classed
• JavaScript Coroutine Support (was Pause Release)
• Threading Support
• Hashes for DOM elements and associated API
• Ajax toolkit caching
• Animation of web page content
• Better testing support
• CSS Object Model

Community Voting Results

By July 13, when the voting closed, this initiative has turned out to be a bigger success than expected. Given the amount of effort required to read and understand the vast web technology landscape, and the relatively limited time and resources available to the OpenAjax Alliance Runtime participants, we were hoping for 50 or so people to vote, which would be meaningful to establish a rough idea of what’s most important to the community.

Voting results are available at:

• http://www.openajax.org/runtime/wiki/Feature_Requests_Summary_Page
• http://www.openajax.org/runtime/wiki/Phase_II_Voting_Summary
• http://www.openajax.org/runtime/wiki/Phase_II_Voting_Details

Here are some quick statistics:

• 222 people participants;
• 143 people voted;
• 55 feature request being written up;
• Various industry leaders contributed;
• A discussion thread spawns on Slashdot with 628 comments (http://tech.slashdot.org/article.pl? sid=08/06/30/1845201).

The Top Requested Features

Among all the feature requests, 2D Drawing/Vector Graphics is clearly the most desired feature by the community. It received most votes (110 people voted for it), and highest total score (842, over 10% higher than the second feature request). The second top feature request is enhanced security for cross-site scripts. The third and fourth were better APIs for scripting and styling and HTML DOM performance.

The following table shows the top 10 features:

Here are some general themes that emerge from the runtime initiative:
Graphics
The top vote getter was 2D Drawing/Vector Graphics. Ajax developers today are achieving astoundingly rich graphics effects through clever techniques leveraging JavaScript, CSS, images, and whatever vector graphics features they can find (usually, SVG, VML and Canvas), but browser differences are a major pain point among Ajax developers. Mozilla, WebKit and Opera support both Canvas and SVG with good interoperability (although Mozilla does not yet support SVG animations). IE is the holdout. The call-to-action is for all browsers, particularly IE, to support both of the industry standards for 2D vector graphics, SVG (the DOM-based standard) and Canvas (the procedural-based standard).
Security
Web security is an important topic for leading Ajax developers. The second top vote getter was Better Security for Cross-Site Scripts (XSS), but other security requests also receiving high votes, such as Strong Cross-Site Request Forgery Protection (which it turns out was the 11th top voter-getter). The perception of the moderators is that it’s not just XSS, but that the community cares about all aspects of ensuring that the Web is secure, and in fact more secure than it is today. Recently, Mozilla has authored a proposal that might help make the Web more secure: http://people.mozilla.com/~bsterne/site-security-policy/. Note that Native JSON Parsing can be considered a security feature because without it Web developers are more inclined to use JavaScript eval() to process JSON data, which might allow for XSS attacks.
Better low-level CSS and DOM support for layout
Two of the top vote-getters were Better APIs for positioning and styling and Better UI Layout Support. These requests come from the widget developers within Ajax toolkit projects who design Ajax-based UI controls by taking advantage of what the browser gives them, such as DOM, CSS, images, and table layout. They often run into walls, and their jobs could be much easier (and performance much faster) if the browser included a small number of additional (relatively small) features, such as stretchable layout (e.g., flexbox in XUL) and the ability to determine the location and size of objects (and containers) within the page.
Performance
The top vote-getter in the performance area was HTML DOM Performance in General. In discussions over the past year with leading Ajax developers, the moderators believe that the Ajax community wants performance improvements in all aspects of the browser runtime, including DOM, JavaScript, and rendering, but DOM performance was singled out by the community because Ajax toolkit developers have found that DOM access is the top performance barrier today. The key high-level message is keep making the browsers faster, but even blazingly fast JavaScript isn’t going to help if making DOM calls is too slow.
Rich text editing
Various people in the Ajax community want to move desktop-like document editing into the browser. However, the contributors to this feature request did not outline a detailed strategy for how to accomplish this in future browser. The takeaway is that the Ajax community wants Better Support for Rich Text Editing , and hopefully one of the browser teams will push the envelope in this direction and send standards proposals so that the other browsers can also provide this functionality.

Comet (server push)
Two of the top vote-getters were The Two HTTP Connection Limit Issue and Persistent Connections Issue. The underlying requirement is that many Ajax applications, such as dashboards, require an efficient and robust mechanism for having the server send data to the client on an event-driven basis. Today, server push in Ajax is often accomplished using “Comet” techniques such as long-lived HTTP connections, but the Ajax community would prefer if server push was a native browser feature.

Video and Audio
Video and Audio also receiving strong support, coming in as the 10th-most requested feature.

New Features (too late for voting)

Participants identified the following 6 new features, which were added to the wiki too late for the voting process, which means that we were not able to poll the community to determine relative importance versus other features:

• ECMA4 JavaScript2
• Field to input multiple files
• Allow JavaScript access to file upload statistics
• Allow user finer control over rich content than Javascript On/Off
• Memory Footprint
• Enforce Semantic Tagging of Data transmittedfrom browser

Next Steps

The next step is to communicate with browser vendors. We have had calls with some of the browser vendors such as Microsoft IE team during Phase I. OpenAjax Alliance will try to get in touch (or continue) the dialog with browser vendors to convey what the community is looking for.

Conclusion

Ajax is becoming at core for developing web applications. The stake associated with Ajax runtime environments is higher than ever.

The open community process works. Despite various challenges, the community demonstrated strong interest for a better ecosystem for Ajax going forward.

The list of feature requests makes a lot of sense from the web development community point of view. They range from security, performance, Comet, CSS, etc. Some of them do overlap with features that are being specified by other initiatives such as HTML 5 and SVG. They will empower web developers to deliver much better applications over the web, and significantly enhance the power of the web.

Although we have identified the top 10 feature requests, the browser teams should study the entire list because all features might represent critical requirements or are just great ideas for advancing the Web. It is possible that some of the features that received fewer votes are critical to a particular but important niche or that only a subset of participants are close enough to the bleeding edge to see an impending but critical requirement.

It is worthy of pointing out that “vector graphics” is voted as the top request. It is time for all browser vendors to support standard vector graphics. Vector graphics support is highly scattered today. Open standards such as SVG and Canvas are supported by some browsers but not the others. The community is clearly demanding this feature, putting it even above security and performance.

Acknowledgement

The following is a partial list of people whose contributions made significant difference for this initiative:

Alex Russell (Dojo Foundation), Jack Slocum (Ext JS), Joe Walker (DWR), Douglas Crockford (Yahoo), Dylan Schiemann (Dojo and Sitepen), Bertrand Le Roy (Microsoft), Kris Zyp (Sitepen), Andrew Dupont (Prototype), Sam Lie (jQuery), Yehuda Katz (jQuery), Krishna Sankar (Cisco), Brad Neuberg(Google), Greg Wilkins (Webtide).

OpenAjax Runtime Task Force members are: Coach Wei (Chair, Nexaweb), Bertrand Le Roy (Microsoft), Jon Ferraiolo (IBM), Adam Peller (IBM), Haik Sahakian (Fidelity), Ted Goddard (IceSoft), Simone Fabiano (LightStreamer), and Krishna Sankar (Cisco).

Special thanks to Jon Ferraiolo (IBM) for coordinating and implementing the site infrastructure that made this initiative possible.

Various people from the Ajax community have put together a good list of feature requests (a total of over 40), collected at OpenAjax Runtime Task Force . Now it is time for everyone to cast your vote!

Voting is easy. Just sign up at OpenAjax Wiki . Then go to
the voting page , select the priority number from a dropdown box for features that you care. -That’s it. Your results will be calculated and displayed in immediately. Once you select a priority item from the dropdown box, your selection is immediately sent to the server and recorded int the database. A nice use case of the asynchronous feature of Ajax. Of course, you can always come back and make changes. (Thanks Jon for making the voting process really easy).

At the moment of this writing, a few people have casted their votes. The current result is below
(you can see the latest result from this summary page ):

WP 2.5 - WYSIWIG Problem - TinyMCE does not start..
2.5 and TinyMCE not working in visual mode
Visual Editor Not Working on Upgrade
2.5 Visual Editor/TinyMCE problems

These posts suggest you modify [tiny_mce_config.php] to turn compression off as a solution to the problem.

Restart your apache Http server and reload [your site]/wp-includes/js/tinymce/tiny_mce_config.php in your browser, now you should see regular javascript showing up. Then the visual editor should be working from now on.

The “infrastructure as a service” trend is fascinating. In general, I’ve been studying the best ways to host and deploy services in a web environment - Amazon EC2 has come up in my mind many times. And of course, Google App Engine certainly caught my attention.

It also caught the attention of our friends at Techcrunch. They built a fairly simple app, deployed it to Google, and blogged about it. I enjoyed their blog. And then I went to check out the application. Here is what I got:

What? Well, maybe it’s just alpha, but it certainly doesn’t look like high availability at this moment.

Update: just saw a posting that reported Google AppEngine has been hacked, via a relatively simply cross-site scripting.

What Is It: Razorspeed Partners. Razorspeed is a new kind of venture fund that focuses on investing in "small and immature ideas",with locations in US and China only. The limited partner is Microsoft. Going forward, we may open up to allow other corporations to participate.

What Does It Do: Unlike any other venture fund out there, Razorspeed is different:

• Razorspeed focuses on "small ideas" and "immature ideas", though we will accept "immature and big ideas" too.
• Razorspeed focuses on bright teams that have high hopes, but may not have "experiences";
• Razorspeed’s main deal flow comes from a semi-annual worldwide startup idea competition. Anyone is welcome to participate. The competition will be hosted by Razorspeed.com in partnership with Microsoft. We will select 10 teams from each competition and fund these 10 teams;
• If a team is selected to be funded by Razorspeed:
  • The team will be invited to live at one of the two Razorspeed headquarters (Beijing and Boston) for three months, with all expenses covered;
  • The team will be invited to an annual BBQ party at Microsoft Chairman Bill Gates’ house;
  • The team will be given an office space, with all facilities wired and ready to go. In Boston, the initial facility will likely be Tim Rowe’s Cambridge Innovation Center that Razorspeed is still negotiating a contract with; In Beijing, the facility will be in Tsinghua R&D center;
  • The team will be invited to weekly unconferences and bar camps (yes, parties!);
  • The team will also receive a $50K cash infusion from Razorspeed;
• Best of all, the above Razorspeed investment and services are provided with no strings attached . Yes, no strings attached. In the end of three months, you can simply say "goodbye" and walk away. Actually, saying "goodbye" is not required either. You can simply take what you’ve done, and walk away. Razorspeed does not claim any ownership in anything you do in this three months period. Razorspeed does not require you to give up any ownership of your business during this three months.
• "No strings attached…?" So why is Razorspeed doing this? At the team’s choice, Razorspeed can invest further to finance the team. In this phase, Razorspeed will operate more like a typical venture firm, but this is the team’s choice. If the team chooses to leave, Razorspeed holds no hard feelings (but we still hope you say good-bye before you leave);

How Does This Relate to Microsoft?
Microsoft is the limited partner currently, In some sense, Razorspeed is operating as Microsoft’s venture arm, but without any corporate affiliation. The initial fund size is $100M. At its own discretion, Razorspeed may raise more from other corporations.

However, Razorspeed does pay special attention to startup ideas that are related to Silverlight, Windows Live and Software-as-a-service.

Who Are the People at Razorspeed?
Razorspeed is managed by three managing partners, including myself. Given that this is an "un-announcement", I will only announce myself and leave my peers’ fate in their own hands instead.

If you are reading this blog, you probably know who I am. I have been at the technology fore front for the last 10 years, started Ajax/RIA etc many years ago. I am not the top 1% coder, but can code well enough to make a living if needed. I have been CEO, CTO, Engineering and marketing, and have seen a lot of different types of executives. I started and helped started a few companies, each of which has raised over $10M financing and is doing really well. My current personal passion is next generation web performance (CDN is a little too old, don’t you think? We can do better. Akamai is a $5B company, but there are so many things have yet to be explored), social computing and digital life. If you are into any of these three areas, drop me an email coachwei at alum.mit.edu. For exceptional ideas or ideas that are close to my belief of the next wave of the industry, Razorspeed can fund outside of the semi-annual competition.

How Did This Happen?

Over the years, I have interacted with lots of smart people, startups as well as venture firms. The evolution of the industry has put serious question on some of the existing thinkings and investment model.

Despite the web 2.0 hype and growth of firms like Y-Combinator, the corporate venture investment has not evolved at all. Corporations in general are having a hard time adjusting to the web 2.0 age.

When I brought up this idea to Microsoft executives a year ago during a discussion, apparently this is something they have been thinking about for a while. The industry’s shifting landscape, ranging from the rise of Google, Facebook, to the rise of RIA and Software-as-a-service, is causing a lot of changes within Microsoft. However, it is time to make some changes to the investment model as well. The $150M investment into Facebook was a bold move. However, I believe Razorspeed is going to work out better for Microsoft over the long term.

What’s Next?

I’m excited about doing this with Microsoft, and thrilled at the opportunity of going to Bill Gate’s BBQ party this summer! The official announcements will come after we clear up a few regulatory matters. Within a year (by 4/1/2009), I’m sure that you will hear a lot of progress. Until the official announcement, the razor sharp ideas will remain razor sharp.

If you have any questions, you may email me at coachwei at alum.mit.edu.

However, I have concerns. I’m concerned about the significant corporate interests driving towards “unweb”. Not to pick on video, but to use video as an example. Video, the most recent hotspot on the web, largely relies on Adobe’s Flash technology. Not that Flash is not good. On the contrast, it is well designed and implemented as a technology. It enabled the possibility of Internet Video and we should be thankful. However, it is a platform controlled by a single entity (Adobe). We should trust our future in the collective will of the society instead of the goodwill of a benevolent dictator. Another example, the area that I’ve dedicated ten years of my life to, Rich In