in Uncategorized

Will IE8 use JScript.NET?

So what do you think? Will IE8 use the CLR implementation of the JScript engine or keep on using the legacy ActiveScript engine architecture that is plagued with COM circular reference issues resulting in memory leakage and a plethora of other performance problems? Seeing as how FireFox 3 is running about 10x as fast now and is only still in beta, IE has a lot of catching up to do.

Performance aside, JScript.NET was designed as closely as possible to ECMA standards at the time which means it already contains several of the features that ECMAScript 4 (spec here, examples of features here) is planning on bringing to the table. These features include:

  • Strongly typed programming
  • Data types like decimal, byte, int, double, etc.
  • Classes as first class citizens (including inheritance)
  • Properties as first class citizens (i.e. set/get accessors)
  • Static properties/methods
  • Constants
  • Iterators

Now the problem is, this was a version of ECMAScript that was being developed back in 2000. Now that the rest of the world has woken up and realized the potential for such features, the spec has changed a little bit, so Microsoft will need to update JScript.NET to support these standards1. The good news is that, since JScript.NET is built on the CLR, it’s really just mapping of concepts to features the CLR already offers. What features are missing? Here’s a few:

  • Namespaces – straightforward mapping to CLR namespaces
  • Generics – straightforward mapping to CLR generics
  • Nullability – maps straight to Nullable<T>
  • Generators – same concept as “yield” in C#
  • Maps/Vectors – easily mapped to Hashtable<T>/List<T>
  • Type meta-objects – basically maps to reflection
  • Union types/Any type – this one’s interesting, it’s basically like saying “I expect this thing to be any one of these types”. Strange concept if you ask me, tough one to map to the CLR without some trickery under the covers.
  • Record/Structual data type support – basically like anonymous types, but also enforces some strong typing over duck typed objects
  • Meta-level hooks – interesting concept that enables you to intercept calls to get/set/invoke generically… basically let’s you play “tricks” with the runtime
  • Static generic helper methods – maps to extension methods introduced in .NET 3.5
  • is and cast – obvious map straight through to CLR concepts
  • like and wrap – for working with the Record/Structural data types and basically allow you to dynamically determine if an instance is of a compatible duck type
  • let – a “better” way to declare variables that gives block scope

So whattya think? Will IE8 use JScript.NET? Even if it’s in an ECMAScript 3 compliance level only today we’d gain all the performance benefits. Then, for Microsoft, implementing these features would sure be easy on top of the CLR. Let’s just hope they don’t try and actually build all this crap into the legacy Active Script engine.

1 Reminds me of the whole DOM fiasco they’re still suffering from. They were the first to implement all of the neat features that make up the DOM today, but when the world caught on and came up with an official spec, Microsoft fell behind. Now they get no credit for their innovation in IE4 and catch (well-deserved) flak for not still not being up to spec.

Leave a comment


  1. I don’t care what engine they implement, or what level of compliance they’re at. I just want their engine to be _fast_. It’s amazing to me that no one has come up with a high-performance javascript engine. Well, Adobe has supposedly, and it will be in FireFox 4 (???) but nothing that radical is out today.

  2. I don’t expect them to change from the ActiveScript version. I wouldn’t think they’d take a dependency on the CLR at that level, and if they did, then I think they’d go with the DLR based dynamic javascript rather than Jscript.NET.

  3. VERY interesting. After hearing claims that Javascript JITed via Silverlight 2.0 is 1000x+ faster than most browsers, I think injecting SL CLR/DLR would put IE8 at the top of the AJAX/DHTML game.I doubt this will happen, but wouldn’t it be exciting?

  4. @Nicholas:yeah, i mean, that’s exactly why they need to get onto a CLR based implementation.@Matt: That’s a great point about the DLR implementation. I didn’t even consider that engine, but you’re right it’s probably the better way to go.@Jeremiah: couldn’t agree more.

  5. Probably they would have announced something major as this until now.And as fast as the JavaScript might become, the real performance killers are DOM traversal and manipulation.I am very satisfied with the JavaScript performance in Firefox 3. IE is also fast, so I guess it is not their top priority.