One thing that caught my attention in the IE 8 notes and that eventually made me download and install it is that it will feature the Developer Toolbar which has been an add-in for previous IE versions as a built in tool. Not only that but IE 8 includes a very FireBug-like debugger that can be easily hooked up to page content.

This is a very worthwhile improvement IMHO because the debugging experience in IE has always been one of pain having to go through dialog pop ups and really to get anything useful having to run the Visual Studio script debugger. While the experience for debugging IE has dramatically improved in Visual Studio 2008 IF you are running an ASP.NET  project for debugging, the standalone debugger story still hasn't changed much.

IE 8 introduces a debugger as part of the developer toolbar:

The developer tools window above can be activated from the Tool menu (or a hotkey) and once active you can easily select a source or script file from the script dropdown button (not easy to see above - the button with the link on it - the rest is obscured). You can set a breakpoint anywhere in the code and the debugger will stop on the appropriate code.

You basically click on the Start Debugging button to enable the debugger and while in there any Debugger commands in your script or script errors jump into the above debugger rather than popping up the nasty IE debugger dialog. If you're in development mode and you're working with multiple pages you simply leave the button set in debugging mode and all errors, break points and debugger keywords trigger in the debugger. Finally an easy and light weight way to do deterministic debugging in IE.

You get the familiar IE script debugger options including the detailed locals and watch windows that let you drill down nicely into any object hierarchies, the callstack window and the always useful immediate window to let you eval expressions interactively. The behaviors here are really nothing new from what you see inside of Visual Studio or even the regular IE script debugger. I think what's nice with this scenario is that it's much more easily accessible which is a big win IMHO! You've heard me bitch about the crappy script error handling and debugging experience for IE and this goes a long way towards addressing the problems.

I would like to see one additional step taken though and that is to get rid of the modal dialog if script debugging is enabled and rather have a more FireBug like model where you can see that an error occurred with a way to click the error icon and then be transported into the this developer toolbar debugger window - preferrably to the appropriate line of code as FireBug does. This is easily one of the nicest and most productive features in FireBug:

But that's probably asking for a bit much <g>...

Running IE 8

So I've been running with IE 8 for the better part of the morning today and overall I don't see much in the way of breaking content. There are a few problems with alignment and spacing defaults as always seems to be the case in almost every beta version of IE. It seems every time a beta rolls the default paragraph spacing gets hosed and I end up with small oddities where line leading run a little tight or where margins between <div> tags introduce unexpected white space. Nothing major though.

Performance of the browser is noticeably faster than IE 7 on my machine. IE 8 supposedly includes support out of the box for opening up to 6 simultaneous connections to the server to retrieve content, compared to the 2 connections default in previous versions and I think that alone is accounting for the apparently more snappy behavior as less content is queuing up.

I do see a bunch of problems however in various AJAX applications that deal with event hookups. For example the Table Editable component I posted a while back doesn't want to recognize clicks unless you click for many times in succession - somehow the click handlers are not kicking in consistently.

But that sort of thing is to be expected - it's a first beta after all and to make the transition easier IE 8 does include a button to let you run in IE 7 mode and - no surprise - running these same problem pages in IE7 mode provides the expected results:

And running in this mode seems to cause no problems whatsoever - it's a good way to run a stable environment until you need to check out behavior specifically with IE 8.

One more thing: It looks that IE 8 was happy loading all of my existing add-ins and running them fine. Specifically I run RoboForm without which I can't really live any longer and if it wouldn't have worked it would have been right back to uninstalling IE 8.

[Update]

Jeff King also reports that IE 8 can provide on demand debugging for Visual Studio. If you've ever enabled script debugging just so you can use the IE debugger in your ASP.NET development cycle then this new option is for you. Simply disable script debugging in the IE advanced options. Now when you start debugging with Visual Studio 2008, VS automatically triggers IE into script debugging mode so the debugger automatically pops up on breakpoints/errors as you would expect with script debugging on. When you're done debugging the script debugging is turned back off so you're left with a 'clean' environment.

The combination of this feature plus the new developer toolbar debugger should make it possible to run with script debugging and the dreaded modal dialog off for good!