When Visual Studio 2008 was just around the corner, I had the opportunity to attend a few sessions on the cool new features of this suite. One that everyone was keen to demonstrate was the ability of Visual Studio to debug JavaScript. Start up an application with Debugging Symbols, and it will fire up in your default browser. Hit a breakpoint within some JavaScript (or an error rises from the JavaScript) and the Visual Studio Debugger will fire and take over, allowing you to view the values of variables and step through the JavaScript code. Plus, I’ve been able to use this from Firefox, so it’s not an IE-only feature.

Not all is sunshine and roses, however. The way that the technology apparently works is actually incredibly restrictive, and it locks you into a particular development pattern that I don’t really endorse. Namely, it only works if the JavaScript is all stored in the same output file as the HTML source for the page as well. Want to debug your JavaScript? Better put the JavaScript in-line with the page. This ends up creating output which is larger than necessary, and doesn’t allow you to cache your scripts separate from the page source. Sure, you can do that refactoring when you go to publish, but in that case you now have to perform the refactoring, re-test everything and then publish it.

In general, I think that this was done this way because it fits very neatly with the Development model that ASP.NET seems to promote. My biggest problem with ASP.NET is that it actually seems a lot harder than writing pure HTML, because it abstracts the form away in a sense that doesn’t make a lot of sense to me. In addition, because of the way the User Controls are structured, it seems unnecessarily difficult to build sites that don’t depend on JavaScript being enabled on the browser.

This is an interesting dilemma, that I’ve discussed before. But I very greatly believe that, in most circumstances, a web application can and should operate without JavaScript and CSS. It won’t look as pretty. It won’t be as snappy or cool. But it will work, and sometimes that’s enough. But the only way to do that, is to design with proper abstraction between the Web Application and the JavaScript that can power it. This is, of course, the heart of what Yahoo!’s Graded Browser Support is all about. Your pages should work not-only with A-Grade browsers, but also with older, less capable C-Grade browsers. This can be a hard thing to test, but luckily, testing for C-Grade compatibility is significantly easier than testing A-Grade.

I’ve been trying to follow these guidelines for several years, though I’ve found that most developers simply don’t. And it’s not impossible to do this with ASP.NET, just that ASP.NET makes it harder, since it’s easy to put a dependency on scripting in a page without realizing it. Frankly, even the development I’m doing using the ASP.NET MVC Framework, I’m doing the HTML either myself or with the HTML Helper object that ASP.NET MVC supplies. I haven’t needed, nor really wanted, to use Web Forms.

So, I think it is the assumption that JavaScript belongs inline on a page that causes you to be unable to debug external scripts. This is an unfortunate result, which I hope will be resolved fairly soon. In the meantime, I guess I’ll just continue to use Firebug.