AJAX Experience & Tools


Hi there!   My name is Laurel Reitman and I’m a Lead Program Manager on the Internet Explorer team working on our Programming Model.  I had the pleasure of attending the AJAX Experience May 10th-12th down in San Francisco. A big thanks to Ben & Dion from Ajaxian.com for hosting the conference. 

It was a great opportunity to sit down with developers who are building AJAX-style web sites as well as developers who are building tools to make it easier for others to build rich applications.  I feel like I got some good insights into what they think of IE today, and what they’d like to see in future versions.  Particularly a big thanks to Alex Russell from Dojo, Brendan Eich from Mozilla, Stuart Halloway from Relevance, Douglas Crockford & Bill Scott from Yahoo, Glenn Vanderburg, Brent Ashley, Joe Walker, and many others for taking the time to sit down and chat with me to express their thoughts and feedback.  I look forward to the continued dialog! 

One question on the top of everyone’s mind is how to debug and get more information about what’s going on with their AJAX-style applications.  I wanted to point folks to some of the tools that are available today with Internet Explorer, many of which I mentioned at the conference. 

Phil wrote a great blog post, back in October 2004 that mentions some of the how to and tools to use to debug script in Internet Explorer.  Another article to add to the list talks about how to debug Atlas applications in VS2005.  Many of those tips transfer to AJAX-style applications in general.  There is also a great whitepaper on how to debug code using Visual Studio that specifically calls out some troubleshooting scenarios. 

Another tool I mentioned at the conference was Nikhil Kothari’s Web Development Helper that brings script debugging into a browser extension.  Nikhil is an architect on the Web Platform and Tools team at Microsoft (which delivers IIS, ASP.NET and Visual Studio Web development tools) so he has a lot of firsthand experience debugging AJAX-Style applications.

Additionally, as has been mentioned in a few other IE Blog posts, the IE team is working on a free developer toolbar.  The latest version is available here.  The toolbar includes a DOM explorer among many other cool features to make it easier to build and debug your web pages.

Also several folks mentioned using vi and Emacs as their development environment.  I’d encourage you to take a look at the new Visual Web Developer 2005 Express Edition.  It’s a great tool for building and designing rich web applications – and it’s free!

Last, but certainly not least, is Fiddler which allows you to watch HTTP traffic, particularly useful in watching your XML-HTTP Requests.

Happy Coding!
-Laurel

Edit: Corrected the spelling in Brendan Eich’s name

Comments (38)

  1. Anonymous says:

    Do you know any good tool to profile JavaScript, or the client-side portion of an AJAX application ?

  2. Anonymous says:

    As mentioned 100 times or more… The biggest omition in IE as far as JavaScript debugging goes, is the lack of a JS Console.

    As a Web Developer, I have _NEVER_ built a VB based app, done very few ASP based applications, thus never needed or wanted Visual Studio or similar products installed in my environment.

    If I develop in PHP, JSP, XML/XSL, CGI, Velocity, JSF, plain old HTML, or any other Web Framework (which most of us do), MS Tools built into Visual Studio are of little or no use to us.

    The current JS error dialog, is just shy of useless (sorry, but it is).  A simple console, with a log of messages and nothing else, would be 100 times better than what you have now.

    *******************************************

    Note the above… this is a 5min code change, for a __MASSIVE__ improvement!

    *******************************************

    Otherwise, improving the Developer toolbar, to include better logging and JS support, would go very far to helping debug AJAX content.

    PS Most of us have built our own JS logging mechanisims to aid with AJAX apps. Better DOM event support, would aid us in keeping these simple, and effective.

  3. Anonymous says:

    I wonder what are the chances of Fiddler ever being released under an OSS license?

  4. Anonymous says:

    I assure you, people are not using emacs & vi because they didn’t know about "Visual Web Developer 2005 Express Edition".

    +1 for the JavaScript console.

  5. Anonymous says:

    "+1 for the JavaScript console."

    …and +2 from me.

    At the very least, add a list to the Previous/Next dialog thingy so we can access errors in a more direct (at least, less sequential) way.

  6. Anonymous says:

    +1 for a JavaScript/CSS/HTML error console or a toolbar/plugin that can do the same thing

    At least to be at parity with Opera and Firefox…

  7. Anonymous says:

    "I assure you, people are not using emacs & vi because they didn’t know about "Visual Web Developer 2005 Express Edition"."

    Thank goodness there are ‘semi-elite’ devs out there to tell the rest of us what we’re thinking.

    Of course if you’re gonna be a true snobby elite you wouldn’t consider anything less pure than notepad and a command line…

  8. Anonymous says:

    I am having SO MANY PROBLEMS with this new beta version. Despite the sleekness and the VERY desirable tabbing feature, for day to day use I would much rather use internet explorer or just stick with mozilla.

  9. Anonymous says:

    @Hmmmm: Some day, Fiddler might be available under one of the Microsoft Community Development programs.  Are their features that you think I should add?

  10. Anonymous says:

    Nick: I don’t know of any specific tools though I believe you can use the debugging tools in Visual Studios as well as the public symbols for Internet Explorer to do some profiling.  This is definitely an area we’ve heard feedback on!  

    Steve:  Have you taken a look at Nikhil’s tool? It’s not built in but I think it gives you some of what you’re looking for.  Definitely hear the feedback and it’s something we’re taking a look at!

    Sogol:  Love to hear more about what problems you’re having.  Definitely make sure to report them to us!  Check out <a href="http://blogs.msdn.com/ie/archive/2006/04/24/582542.aspx">Al‘s post on how to give feedback.</a>

  11. Anonymous says:

    None of IE’s tools can hold a torch to FireBug, the best debugging tool for any browser.

    http://getfirebug.com

  12. Anonymous says:

    I’d love to see native support for the XSLTProcessor object (similar to the native support added for xmlhttprequest).  This would make it much easier to stick to transferring xml (small) and building html (large) on the client using style sheets…all without ActiveX.

    Frankly, as complicated as a lot of my AJAX applications have been, I’ve never found a better tool than Fiddler.  Client-Server JavaScript debugging, yes, that would be nice, but am I going to launch a sledgehammer (X) when all I need is a needle (Y)?  No, I rather doubt it.

    A javascript console with an ACCURATE and COMPLETE call stack would, however, be great!

  13. PatriotB says:

    This is off subject, but at least somewhat related to the topic of HTTP traffic:

    Is there be a way to use the user agent string to differentiate between the Windows Vista client and the Windows Server "Longhorn" OSes?  With XP and 2003 we can use the 5.1/5.2 difference, but so far both Vista and Longhorn Server are 6.0.

    So far it hasn’t been announced if LHServer will be 6.0 or if it’ll be upped to 6.1 (like 2003 was upped).  Either way I’d rather not depend on version number but would love to see a token, such as "WindowsServer" added to the Server UA strings. (Because you never know what will happen in the future–XP x64 is 5.2 so there’s no way to differentiate between client and server there either.)

  14. Anonymous says:

    @PatriotB: I’ll look into the LHServer UA string issue.  It stands to reason that it should be distinctive.

  15. Anonymous says:

    It’s very sad that IE team has to write developer toolbar themselves.

    Firefox, on the other hand, has already have a dozen of developer-specific extensions written by web developers for FREE!!!

    IE becomes too protective because it is so deeply embeded into OS. It simply won’t allow any program, other than from Microsoft, to run seamlessly with it.

  16. Anonymous says:

    Debugging: It all starts with the console. I’ve only *needed* a js debugger a handful of times in my life. The console is nearly all I need.

    I was *really* bothered about the error reporting incorrect line numbers (IE gets confused as to the line number when js is embedded html). Never mind that it didn’t have a history.

    I switched to firefox due to the console and never looked back. It’s nice to click on an error in the console and firefox will take you to the line of code.

    Seriously though, I think the effort going in is great. The improvement put into making IE *the* web dev platform again will pay off. For me, I’m firmly entrenched in firefox and their solutions … and I "top up" with IE, Opera, and Safari afterwards.

  17. Anonymous says:

    Another whole-hearted vote for the console.

    I would love to see something like Firebug for IE – it would help immensely when developing for run-of-the-mill Windows users! However, it all starts with the console. Without that, you effectively code blind when it comes to reacting to errors.

  18. Anonymous says:

    Howdy, folks!  

    First of all – I’m excited to see the improvements in IE and more importantly the response to community feedback.  It’s good to show that our company actually cares about what the rest of the world thinks about it and its products.  

    With that being said I would love to see some improved js debugging.  The debugging integration between VS2005 and IE leaves much to be desired.  It used to automatically allow "debugger;" statements to force a prompt for the dev to choose which tool to debug with @ that point.  This stopped working some time back and I was forced to use the prescribed "attach to process" method.  That fails to work as well, now.  I don’t know if it was due to the many install/uninstalls I’ve done of the various IE7 Betas but something is definately configured incorrectly, now (I’ve checked/unchecked the appropriate boxes in IE’s Tools–>Advanced tab).  I’m usually presented with the "there is no source code available" message after I choose a tool to debug my javascript code (either the script editor or VS2005).  I just had the pleasure of using the Venkman tool for Firefox the other day and besides its main attraction (it works as advertised and a dev can actually debug clientside code) it provides a decent alternative to the VS2005/IE debugging "story".  I hear that "Orcas" will provide a desirable js editing/debugging experience.  All I ask is that the debugging experience for this aspect of web-development be made rock-solid and intuitive.

    Thanks for all the improvements ya’ll have added to the IE browser.  

  19. Anonymous says:

    @Microsoft_Fan: IE has a very rich extensibility model and lots of third-parties write plugins for it.  You can write your own script debuggers, toolbars, etc.

    We definitely do need to do more to make this experience simpler and more seemless.  There’s a ton of power here already, but too much complexity.

    We’ve blogged about script debugging before:

    http://blogs.msdn.com/ie/archive/2004/10/26/247912.aspx and there are other options, like the neat DHTML/JS one here: http://blog.monstuff.com/archives/000287.html

  20. Anonymous says:

    Any advice on how to get Fiddler to work over HTTPS would be greatly appreciated.

  21. Anonymous says:

    @Trails: Fiddler can view HTTPS headers from IE and other WinINET based applications when you install the RPASpy plugin (available from http://www.fiddlertool.com/Fiddler/version.asp).

    A future version of Fiddler will offer full viewing / tampering functionality for HTTPS traffic from all applications.

  22. Anonymous says:

    Please, everybody, stop spreading this ridiculous notion that IE has never had decent debugging tools.  

    There has been a free downloadable Script debugger since NT4/Win98, and it’s been uncluded with the operating system since Windows 2000 (control panel..add/remove programs..add remove windows components..script debugger then uncheck debugging disable boxes in advanced internet options).  It has always had and it still has just-in-time debugging, breakpoints, watches, immediate window, and call stack trace SINCE THE LAST CENTURY.

    Visual Studio has had full GUI debugging that has had more features than Venkman and I’ve been using it since 1998 or so.  Any dev shop that is seriously building any significant DHTML applications for the public-facing web (that is to say mostly an IE audience by the numbers) would be well-advised to buy Visual Studio for this feature alone.

    Visual WebDeveloper 2005 Express edition has almost the full debugger built in and wouldn’t you know it, it’s FREE.

    There’s no excuse not to know this.  You certainly wouldn’t get past the first interview with me if you didn’t.

    http://www.ashleyit.com/blogs/brentashley/2006/05/26/free-tools-for-debugging-javascript-and-ajax-apps-with-internet-explorer/

  23. Anonymous says:

    If you didn’t see it my colleague Laurel put up a great post on the IE team blog about her visit to the…

  24. Anonymous says:

    Brent Ashley: I, too, was suprised that nobody had mentioned the IE script debugger here yet! It has been much more help to me in the past than having none would have been, to be sure.

    Still, I’d like to point out that it is painfully buggy, and nasty to use, IMHO.

    At times, I have hit walls with which prompted me to close it in resignation, and start peppering my code with alert() statements because this pathetic method of code debugging was actually preferable. I tend to think that a decent debugger would never make a person favor such barbarism.

    My point is that the bugs, at times, outweigh the benefits.

    I’ve been debating keeping a log of all the ways in which MS script debugger causes me pointless pain as opposed to FireFox’s superb-yet-neglected Venkman. However, your post has inspired me. Starting now, I will compile such a list, and when it feels relatively complete, I’ll post it here.

  25. Anonymous says:

    Laurel,

    Thanks for all the great links to Ajax resources! I thought I knew about pretty much everything out there, but was completely unaware of Web Development Helper.

  26. Anonymous says:

    I have had _one_ machine (in the past couple years, on 5-6 different machines) on which the aforementioned script debugger works. I currently have to rdesktop to my Exchange server to use that thing. On _every_ other machine I’ve tried to use it on, it fails … won’t open.

    The free Visual WD Express doesn’t work either, but that could be due to the same issue. I’ve wasted more time trying to get those things working to pay for a good many "alert()" debugging sessions … ergh.

  27. Anonymous says:

    One of the trends I am seeing in various manufacturing applications is the move towards browser based…

  28. Anonymous says:

    Hi there! My name is Laurel Reitman and I’m a Lead Program Manager on the Internet Explorer team working on our Programming Model. I had the pleasure of attending the AJAX Experience May 10th-12th down in San Francisco. A big thanks to Ben &amp;amp; Dio