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
  Packages
• 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 standards¹. 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.

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

ScottGu has unleashed a set of posts (main post here) that shows off some of the new features of Silverlight 2. Looking at the samples, it's safe to say Microsoft heard us loud and clear when we said that Silverlight really needs to reach a better feature parity with WPF if it hopes to embed itself as a viable rich client platform for the web. Silverlight now offers the same layout model, data binding model, and styling and templating model.

With these features in place, I finally think the code-name of WPF/Everywhere is now a valid representation of the product. Kudos to the team for all their hard work. Can't wait to get the bits... the only question now is: how big has the download become? :)

Update on download size:
Oops, I missed that Scott mentions the size of the download right in the post...

The Beta1 release of Silverlight 2 is 4.3MB in size, and takes 4-10 seconds to install on a machine that doesn't already have it.

Ok, I have to vent a little here. I was really expecting Microsoft to step up the game for their JavaScript support in VS 2008 and unfortunately there are still some serious issues that prevent it from even getting close. These problems even exist after installing the hotfix rollup that came out last week.

Let's start with the intellisense experience. The basic intellisense features such as color coding, variable type inference and formatting seems to be working great... albeit slow at times. However once you start to write your own libraries of ASP.NET AJAX classes, the intellisense starts to fall flat on its face. For starters, you get no intra-file intellisense. Meaning that, if you have a file that consists of six different classes and those classes reference one another, you'll have no help from intellisense using those types. Next up, if I have an ASPX file open that has a ScriptManager in it that references about eight scripts (some from AjaxToolkit, some from the July Futures and some from my own app) when I first open that file one of my cores shoots up to 100% CPU usage as typelibbuilder.exe runs out and tries to "Update JavaScript intellisense". Worse yet, since I'm referencing my own web's assembly for scripts, if I rebuild the solution and still have that ASPX file open, the update is kicked off again. The biggest problem is that this whole process takes ~25 seconds. So after a build of a decent amount of .NET code for the app takes place in ~5 seconds, I have to wait around for ~25 more while Visual Studio updates intellisense? WTF mate?

Now on to the debugging experience where I have numerous complaints, so I'll just use a list format:

1. Why in the heck did they decide to move the Script Documents treeview node into the Solution Explorer window?It used to be a separate tool window called "Script Explorer", now it plagues my Solution Explorer whenever I start debugging. This is a huge pain in the rear when you have large solutions and then begin debugging a web page that has a large number of scripts in it. Oh look, I found an explanation here:
   
       "In earlier versions of Visual Studio, client-side script files generated from server-side script appeared in the Script Explorer window. The Script Explorer window was often hidden, so that the availability of client-side script was not always obvious."
   
   Are you kidding me? Do you know how many windows are hidden inside of Visual Studio until the developer actually decides he/she needs it and makes it part of their default set of windows? That's kinda the whole point to having a customizable IDE. "Show me the stuff I need, let me hide what I don't." This should be put back into a separate Script Explorer window just like everything else... just like it was in previous versions.
   
2. Sticking with the Script Documents, whoever wrote the code to populate/clear that treeview needs to learn a lesson in batch updating of UI elements. Every single node added causes the entire treeview to refresh. When you navigate from one page to the next and it has to remove the nodes it's the same problem. How about BeginUpdate -> Add/Remove Nodes -> EndUpdate?? If the reason ends up being that the Visual Studio treeview control doesn't support that (I haven't done any VS integration projects in a while), then punt the bug to whoever owns that thing and shame them until they add support for it.
   
3. Still sticking with the Script Documents, JavaScript files that are being served by the ScriptResource.axd handler have wacky URLs. There's a good reason for this and that's not my complaint. My complaint is that the JavaScript debugger in Visual Studio should have knowledge of this native ASP.NET feature and, instead of showing me a treeview node with the completely useless text of "/ScriptResource.axd?d=G6bInrjVzw1gMRIiNhia4kF8AHn-gr5aic5moRTSfnmOpl2Joz1JMqVlKER-JY7nRN0O9p-LrVC8B9hBYQu7j_pjunOJf8t9QKWLySIlmGo1&t=633358634532166680", VS could recognize that it's a ScriptResource.axd URL and then reach into the file contents where the handler implementation has thoughtfully included the real script name and assembly information in the first few lines of the file in the form shown below and use that as the treeview node's text instead.
   
       // Name:        MicrosoftAjax.debug.js
       // Assembly:    System.Web.Extensions
       // Version:     3.5.0.0
       // FileVersion: 3.5.21022.8
   
4. Stilllllllllllll sticking with Script Documents and saving the best for last... wtf is with the horrible support for "anonymous code"? Seriously this makes attaching the debugger to certain pages that use controls that declare a lot of anonymous functions (*cough* ComponentArt) absolutely abysmal because it generates a new node in the tree view for every single function. Sometimes attaching the debugger to a page with enough controls on it can take 30+ seconds. The real problem goes back to #2 where the damn treeview repaints itself every time one of these nodes is added. Right now all "anonymous code" entries get added as treeview nodes to the page's node. My suggestion would be to aggregate all the anonymous nodes under  a single node called "Anonymous Code" and that node should remain collapsed by default.
   
5. How in the hell does the bug where you can't put a breakpoint on the first line of a function still exist?
   
6. Sometimes when you set a breakpoint, Visual Studio decides to add <insert random number here> other breakpoints to locations across all the scripts being debugged at random. This problem also existed in 2005.
   
7. If one of the scripts has a syntax error, the debugger will not jump to the area of the syntax error, but rather it will continue processing and then just blow up on next piece of code that needs runtime access to the types/functions of the file that had the syntax error.

I'm sure there's more stuff I'm forgetting, but it's late so I gotta get to bed. If I remember anything else I'll be sure to come back and update. If you've got more scenarios you'd like to join in and rant about, feel free to leave comments. Likewise leave a comment if you have solutions to any of these problems, because I'd love to hear them.

The recent mention of an improved effects API in the next enhancement release of WPF has gotten me thinking about this again.  I've written before about how other platforms are stepping up their game when it comes to leveraging the GPU in their graphics stacks and how WPF really needs an answer of its own to this problem. As a refresher, WPF has the BitmapEffects API, but it's completely CPU based and pretty much trashes the performance of your WPF apps if you decide to use them because it forces the elements the effects are applied to to also be rendered in software.

With the birth of LINQ we've seen how Microsoft has enabled us to program using the constructs of our favorite languages, but then end up with an Expression Tree which a LINQ provider can interpret at runtime and translate into another format as well as ship the execution of that expression wherever it wants. The obvious examples for LINQ is DLINQ (or ADO.NET entities) where the expression tree is converted into SQL and remoted to the SQL server for execution. Also on the horizon are the Parallel Extensions which allow you to define your work in terms of tasks that can be executed in parallel and then those tasks are handed over to a scheduler which executes them using all kinds of super cool threading algorithms, leveraging all kinds of hardware heuristics to ensure the tasks are executed as quickly as possible on the hardware that is available.

Well, that got me to thinking... why not do the same thing for GPU programming? We should be able to leverage the same technology to be able to write natural language shader programs. Instead of taking the expression tree and turning into SQL, we would take it and compile it into a shader! The type of code you'd be able write in a "GLINQ" function would limited to the standard constructs of a shader (math using the standard .NET integral data types, loops, variables, etc.) and any shader specific capabilities can be exposed through a custom .NET class, which would really just be an empty stub, and the calls to the methods of that class can then be detected by the compiler and translated to the proper shader features. Best of all, because it's interpreted, the compiler can include security features that are able to do some kind of static analysis of the program to ensure that it's not malicious. Also there could be a level of CAS put in place that allowed users to decide exactly which features of the GPU programs are allowed to use.

I really hope this is the kind of implementation we eventually end up because, IMHO, it's the only "natural" way to implement it looking at the .NET technology stack.

Finally, some food for thought: The GPU is becoming so powerful that companies like nVidia are pitching them as GPGPUs and selling HPC (high performance computing) products that provide massive amounts of power (128 processors, massively parallel) in a little box. So, imagine that we took this same concept a step further and implemented an entire library outside of WPF that allowed you to leverage those kinds of platforms for general programming. Just like DLINQ where the expression is translated to SQL and remove over to your DB server for processing, we could translate and remote over to one of these boxes and execute it in a nanosecon

Scott Guthrie blogged today about the WPF roadmap and what kind of enhancements we can expect to see coming in the next few releases. Check out the post for full details, but here's a quick list of things to expect:

• Improved setup for WPF apps (i.e. ClickOnce enhancements)
• Improved working set and startup times
• Performance improvements including
• DropShadow and Blur effects becoming hardware accelerated (w00t!)
• Improvements to text features in certain scenarios
• Media and video performance boost
• New WriteableBitmap API to finally appease the people looking for realtime bitmap manipulation (like GDI)
• "Support for new effects API that enables you to build richer graphics scenarios" (hmm, that's not very specific, but could this finally be the release of a hardware accelerated BitmapEffects stack???)
• Data scalability improvements including container recycling and better/simpler virtualization support
• New intrinsic controls (certain to please all)
• DataGrid
• Ribbon
• Calendar/DatePicker
• Improvements to the VS 2008 WPF Designer

The best part about all of these? You do not need to recompile your apps to gain benefits from existing features that are being upgraded. If someone has the latest bits installed, your app gets all the performance gains for free. Good stuff!!!