Ramblings from a compromised mind.

VS 2008 JavaScript support still not quite ready for writing rich web apps

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:

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.

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.

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.

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.

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.

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.

5 thoughts on “VS 2008 JavaScript support still not quite ready for writing rich web apps”

Let’s not forget about the fact that JS intellisense is either totally broken or has huge limitations for virtually all the major non-ASP.NET AJAX Javascript libraries (though I realize they’re trying to improve that somewhat through hotfixes). And the lack of JSDoc support is lame.I’ve been hugely disappointed with JS support in VS2008. Ultimately, I think they took the wrong approach – Aptana’s approach seems to be much more effective. Of course, I assume that they were only trying to solve for their own JS framework.

On #7, Visual Studio tries to validate your JScript on F5. So I am curious when this breaks down. Do you run into this with?1. Syntax errors in static JScript which intelisense isn’t finding-or-2. Syntax errors in dynamicially generated JScript (ex: Response.Write)-or-3. Syntax errors when you aren’t using a Visual Studio project.

Gregg,Valid point. I have two scenarios where this is a problem. The first is the case where you’re just given a URL that someone is reporting an error on and you go to it in IE and the syntax error occurs which causes the confirm dialog for JIT-Debug to pop up. You just want to get into the debugger and find the problem, you didn’t even have the project open or maybe it’s not even a site of your own.The second scenario is one where you’re generating release scripts. As part of generating release scripts, you usually compress the scripts down by removing all unecessary white-space. This ends up putting all the JavaScript on a single line. Now, as I’m sure you know, JavaScript has a more relaxed grammar (for lazy people :P) and will allow you to not put a semi-colon at the end of every statement. So, if someone forgets to put the semi-colon into the debug version of the file, but has a new line there, the JavaScript parser in Visual Studio follows the rules and sees that as valid syntax. Now you go and run your site in release mode and the compressed script is served up and you can’t (easily) find out where the syntax error is.Cheers,Drew