There’s a lot of buzz lately about browsers finally getting JIT’d JavaScript. First it was SquirrelFish in WebKit, then FireFox let the cat out of the bag about their implementation called TraceMonkey  and then Google came out with V8 when they unleashed Chrome on the world. Kudos to all of those teams for pushing performance forward since DHTML/AJAX apps these days are really starting to show the signs of weakness in current JavaScript engine implementations. Now’s when I turn this into a rant on how Microsoft dropped the ball again…

Let’s be honest, Microsoft held the crown for quite some time with their ActiveScripting engine. It was a pretty damn good implementation considering it was created in 1996 and only recently did they actually start to care about its performance again. Microsoft has had a .NET based JavaScript engine since .NET 1.0 (announced in 2000, released in Feb. 2002) which runs on the CLR and, as a result, has spanked the crap out of the ActiveScripting engine since day one. Now, granted, IE6 was released in 2001, so there’s pretty much no way it could have been in there, but… why the heck didn’t they switch to it in IE7? They could have been ahead of the curve and probably still hold a performance crown against these other implementations (or at least come close). Better yet, why didn’t they at least switch to that  in IE8?!? In fact, let’s take it one step further! More recently, as work for the Silverlight 2.1 platform, Microsoft has moved ahead with the Dynamic Language Runtime (DLR) initiative and they’ve provided an entirely new, cross platform implementation of the CLR and a DLR flavor of JavaScript which is probably even more efficient. So, even better, why didn’t IE8 build on that? Why didn’t IE8 just take the dependency on Silverlight 2.0 which is a freakin’ ~2meg add-on which at least 1/3 of which is probably made up for by removing ActiveScript. Not only that, but it would help increase the surface area of Silverlight. Can you say “win, win”? I knew you could.

I’ve worked with Microsoft technology my entire career and I’ve seen the various departments blow integration opportunities so many times I’m really starting to get sick of it.  At least the newer projects within Microsoft seem to be doing a better job, so perhaps they’ve finally got some architects in there that are actually taking in the bigger picture and doing a lot more cross pollination, but man to see IE8 blow it again just makes me shake my head. Between keeping the antique ActiveScripting engine and writing yet another version of a rendering engine that is pretty much redoing everything WPF does with no where near the extensibility or features, I just gotta wonder what that team is thinking. They must have a serious case of “not invented here” syndrome and like writing/maintaining a bunch of plumbing code rather than being able to focus on higher level HTML/CSS specific stuff or spending more time building better browser features. *sigh*

Ok, I’ve just started working with Microsoft’s Distributed Caching API (aka “Velocity”) and while I’m very happy with the features thus far (can’t wait for notifications!), I really think the API needs a TryGetValue method. Right now you have the Get, GetAndLock and GetIfNewer methods and all of those return type Object. My suggestion is two-fold:

1. Add the TryGetValue method with similar overloads to Get. Return a bool which, if true, indicates the item was found.
2. Take it a step further and make the method generic. This will help when working with simple value types like DateTime, Int32, Guid, etc.

Imagine you’re caching a DateTime and want to look it up… here’s an example of how you need to do that with the API today:

object cacheValue = cache.Get(“MyCachedDateTime”);
DateTime myDateTime; if(cacheValue != null)
{
   myDateTime = (DateTime)cacheValue;
}
else
{
   myDateTime = CalculateSomeComplicatedDateTime();

   cache.Add(“MyCachedDateTime”, myDateTime);
}

// … use myDateTime here …

Notice the annoying need to have a temporary object variable (“cacheValue” in the sample). You need that because you can’t cast straight to a value type like DateTime. Now let’s look at what it might look like with the TryGetValue implementation I’m suggestion:

DateTime myDateTime;

if(!cache.TryGetValue<DateTime>(“MyCachedDateTime”, out myDateTime))
{
   myDateTime = CalculateSomeComplicatedDateTime();

   cache.Add(“MyCachedDateTime”, myDateTime);
}

// … use myDateTime here …

There’s no denying the second version results in less code and, IMHO, this pattern is far more legible.