…well maybe not for webcontrol users.

One of the most spoken-of features of Visual Studio 2008/Orcas is the new JavaScript Intellisense that helps the client-side developer. I’m very excited about this new feature, and put a lot of effort in documenting my JavaScript with code summaries so that I will get the full benefit when VS2008 ships.

I have been struggling to get this to work with some custom controls that emit JavaScript into the page. The JavaScript is fully documented and each file header references other assembly-embedded JavaScript files, just like the documentation tells me to do it. The problem was that I was getting no Intellisense at all for these scripts, unless I manually inserted them into the page. I also made sure that these commented JavaScript files (I also have compressed/stripped scripts embedded) of these scripts was actually registered during DesignMode.

I was reading a blog-post the other day stating that Intellisense is provided for scripts that are included in the page either as a ScriptReference with the ScriptManager, or as a normal HTML script tag in the page. My controls did just that during the PreRender events.  I emailed one of the bloggers about this, and guess what… this is not supported. If you drag a webcontrol onto the page that emits JavaScripts to the page, you are NOT getting Intellisense for those JavaScripts. So much for building a fully documented JavaScript API.

The reason is performance and security. For once they don’t want to execute user code on the client by rendering the control. But hey wait… isn’t that what is already happening in design time? The controls are rendered with specific design time layout, thus executing user code. OK VS is not doing it in the code editor but in the designer, but what's the difference from a security standpoint? Or could we at least get to allow certain assemblies we trust to do this? With regards to performance, I would think that either you want Jscript Intellisense or not, and if you want performance, you would just go and disable the Jscript Intellisense. They also seem to have nailed this one pretty well with JScript Intellisense being generated in the background while you're coding.

So the proposed workaround is to manually add a ScriptReference to each script using a ScriptManager. There are just two problems to that:

• You rarely know the full name of the embedded script, and using Reflector to find is often a violation to the EULA’s, and furthermore the name or scripts might change with each release/service pack. -not to mention that it's not very user friendly.
• Secondly, who says I even have a ScriptManager or want one on the page? Partial Postbacks have longer page life cycles and transmit a lot more data than callbacks, so I might just want to stick with the good old lightweight callback model, or I might not even need any AJAX functionality at all.

The funny thing is that the reply I got from Microsoft started out with saying that they get this question a lot, so there obviously is a demand for it.

I would have to wait 3+ more years for the next Visual Studio release, to harvest the benefit of all my code summaries... '-(

I actually found this other bug trying to get this thing above to work, and at least that is getting some attention. So before you start playing with JString Intellisense in beta2, don't put your classes inside namespaces.

Below is a list of some of my most used features in various web developer tools. The tools can do so much more than I described here. Many of the features are somewhat hidden, so perhaps there’s a few things you might find useful too.

Feel free to share any of your favorite features in a JS and AJAX tool in the comment section below.

Microsoft’s Visual Studio.NET

The tool I use by far the most is Microsoft’s Visual Studio.NET 2005. Its script debugging features far surpasses anything I’ve seen in any other tool. The downside is that this only works for Internet Explorer. What I wouldn’t give for this to work with FireFox too.

The debugging experience is as good as the debugging in a .NET application. You get breakpoints, watches, object inspection and manipulation, step-into/over and so on.

This feature is somewhat hidden, because you need to go through a few hidden steps to enable it (this will change with VS2008).

First you need to enable script debugging in Internet Explorer. Go to internet options, and uncheck “Disable script debugging (Internet Explorer)”.

Then go to “View – Script Debugger – Open” and select a running instance of Visual Studio .NET.

In Visual Studio, go to “Debug – Windows – Script Explorer”. This will bring up the window with the loaded page and scripts. Double-click any of the files in the script explorer to open it and set breakpoints, create watches, inspect objects etc. Open the “Immediate window” to execute any JavaScript you enter. Note that these features only are available while you are at a breakpoint.

A little quirk compared to debugging a .NET application is that you can only hover the mouse on the root object, and not on its sub properties. The workaround is to select the object to get its value, as shown above. The good thing is that this even works on methods, so if you select an object, its method and the ending enclosing parentheses, the tooltip will show you the returned value from that method.

If you are developing a web application in VS.NET and run it in debug more, VS.NET will automatically attach to the browser process if you have enabled script debugging.

FireBug

My favorite tool for debugging JavaScript in FireFox is FireBug. It’s the Swiss army knife of web development in FF. One of the cool features that a colleague of mine brought to my attention was a neat little feature for tracking all events that happen on a selected DOM element. This is great for analyzing which events are available for listen for, see the order that events are fired etc.

To use this feature, choose the HTML tab and browser to the element you want to track. Right-click it and select “Log events”.

Switch to the Console tab and try moving the mouse over the element and you will see a continuous output of all events occurring on the element:

You can also inspect the properties of each event by clicking them:

Nikhil’s Web Development Helper

Nikhil Kotari has created a great little plug-in for Internet Explorer to assist primarily AJAX development. The most used features it the request logger, that logs all HTTP requests and provides you with some serializers for interpreting the responses. Deserializers included by default are Text, Hex, Image, Microsoft AJAX Partial Postbacks and JSON. The JSON and Partial postback deserializers gives you a nice little tree-view for inspecting the AJAX responses.

The newest release also features a neat JavaScript object class browser. It interprets JavaScript objects in memory and shows them in a familiar Visual Studio/C# like object browser.

IE developer toolbar

IE developer toolbar is a useful tool for DOM inspection and manipulation. My favorite feature here is that it enables me to select any element and modify the DOM and CSS properties on the fly. This gives you a quick trial-and-error approach to getting your CSS to do what you want without the need for modifying HTML and refreshing the page.

It also gives you quick access to clearing the cache, generating image reports, save out the loaded and the generated HTML, a measure tool, and a bunch of other useful tools for inspecting the page.

Fiddler Tool

Fiddler tool inspects all http request and responses from all running applications. I use this for optimizing responses by checking that gzip encoding is used and pages that should be cached is cached (inspect cache header and result code):

This tool is VERY powerful and also includes scripting, altering request/responses etc, but that is a whole other story.

Fiddler Tool works with any browser that respects Windows’ proxy settings (for instance Safari 3b doesn’t, but IE and FireFox do).

I finally had a chance to play with Silverlight today. The managed code capabilities is very interesting, so I set out to create a simple performance tester.

I created two basic managed methods in Silverlight. One that multiplies a number and returns a result, and another that does the same thing a specified number of times:

[Scriptable]
public double Multiply(double a, double b)
{
   return a * b;
}
[Scriptable]
public double MultiplyLoop(double a, double b, int count)
{
   double result = 0;
   for (int i = 0; i < count; i++)
      result = a * b;
   return result;
}

This gives me 3 test-cases to compare:

• Multiply two numbers n times in pure javascript.
• Multiply two numbers n times, by calling Multiply(a,b) from JavaScript into managed code n times
• Multiply two numbers n times, by calling MultiplyLoop(a,b,n) from Javascript into managed code one time.

What I found was:

• JavaScript is fairly slow to do this (345 ms for 10 millions calculations).
• Calling a managed method millions of times is VERY slow (IE asked me several times whether I wanted to abort it before it finished)
• Calling a managed method once and do the looping in managed code is VERY fast (0-2 ms).

The conclusion here would be that you shouldn't have methods in managed code that you call a lot from javascript unless they are process-intensive. There seems to be a big overhead in calling into managed code, but as soon as you are in the managed process, its blazing fast.

You can download my test sample here: SilverlightProject1.zip (18.35 KB)  (requires Orcas beta 1 and Silverlight add-on)

Now on to move all my existing .NET libraries into a Silverlight app... :-)

Earlier today (some would say way too early after a long night at Pure) I attended the session "How to make AJAX Applications scream on the client". This turned out to be more about general patterns in Javascript and not so much about AJAX.

Anyway here are my notes from that session:

Avoid Eval(). Instead use parameterized code.

'Switch' is costly for large sets and grows linearly. Instead use a hashtable and wrap in try/catch.

Getters/setters are inefficient. Use direct access to the variables in an instance.

DOM Instantiating and traversing is slow because it has to go from the JS layer to the DOM layer through COM. Use it as little as possible. Example:

   Bad: for(var i=0;i<100;i++) { document.getElementById('myDiv').innerHTML = i; }
   Better: var div = document.getElementById('myDiv'); for(var i=0;i<100;i++) { div.innerHTML = i; }

Use speculative download. Try and anticipate what the user needs to download next. For instance, on the login page start loading icons that the users will need after logging in. The browser might as well spend the time he is spending on entering his password on downloading stuff. When he then logs in the browser will retrieve the images from the cache instead of having to download them from the server, making the page load much quicker. Try going to the login page of an Outlook Webaccess website and see what happens behind the scenes through the Fiddler tool.

Enable GZIP encoding on the webserver. Most browsers supports it and will result in smaller downloads. Again Fiddler is great for experimenting with this.

You can see the full session online here.

Today Microsoft demoed their AjaxView application in one of the Mix07 sessions. It acts as a proxy and monitors requests, as well as execution time for each javascript function that gets executed. This is really neat for tracking what methods are putting the most load on the client browser. Now all we need is some built-in tracking of memory leaks ;-)

A tech preview will be available within the next 1-2 months.

Update: You can now see the full session where this was demoed online here.