News

Q&A: Top IE Exec Discusses New Browser

• By Jeffrey Schwartz and Kurt Mackie
• 01/26/2009

Hachamovitch unveiled new functionality in IE 8 (now available as a release candidate), including built-in developer tools, and delivered the first developer beta. Now that Microsoft has issued the release candidate and it's approaching its final release, Hachamovitch is again reaching out to developers to focus their attention on IE 8's new standards capabilities. In a recent interview, Hachamovitch discussed his call to action.

When is the release?
We're not sharing a date right now; part of this conversation is signaling the around-the-corner nature of the release candidate.

Beta 2 is considered too buggy by many testers, and some people wanted another release before you went to release candidate. What do you think about those comments?
We took the feedback from beta 2 and we acted on it, and people will see that with the release candidate. There have been public reports around the post-beta 2 build out on the Web. I can't comment on that build, but I will say that the feedback about that build has been somewhat positive in terms of demonstrating how we listened to the beta feedback.

So you're feeling pretty comfortable that the release candidate has addressed these bugs?
Yes, I feel good about how we've demonstrated that we have listened to the beta 2 feedback with what's going into the release candidate. [With] the release candidate, we will be very detailed about what has been fixed and how.

At the same time, the release candidate is a call to action to the technical community. The release candidate is a strong signal that IE 8 is effectively complete and done. I said the beta was listening; release candidate is also listening, but it's a different kind of listening -- it's listening for the truly critical issues. Developers should expect the final IE product to behave like the release candidate.

What impact has Google's entry with Chrome had on any changes that have been made in IE 8 in the beta cycle?
I think that the biggest impact Google Chrome has had, with respect to development of IE 8, has been in helping standards bodies take feedback about how certain things should work. For example, the HTML 5 spec -- with respect to synchronous and asynchronous APIs -- I think that Google Chrome's entry made that group more open to our feedback since there are similarities between IE 8's more modern systems and some Google systems versus other browsers' way of doing that.

Chrome has an ability to update its security rapidly. Is that something that's part of IE 8?
The ability to update IE, which has been available with Windows Update for some time, is obviously important, but also the ability for large corporations to manage that deployment and control it is absolutely crucial. It's that facility for enterprises and IT to be in control of that that's super important.

In terms of JavaScript development -- we mentioned Google Chrome -- we also see accelerated handling of JavaScript through just-in-time compiling and other techniques from the Firefox Mozilla group. What's going on in IE 8?
When it comes to scripting performance, I think that there are drag races. There are these tasks whose sole purpose in life is to exercise the script engine, and I think those are very interesting.

Our focus has been on real-world performance. Real-world performance has got these two aspects: We look at a bunch of common sites -- commerce, mapping, e-mail -- and when we look at the side-by-side performance of opening a message, moving to the next message, composing a new message, the performance more often than not is equivalent.

The other part of real-world performance is the tasks that people do. Again, if you spend all day running JavaScript benchmarks, you're going to know a big difference. If you spend all day saying, 'hey, that's a really interesting address, I want to go get a map,' being able to select and get a map in place from whatever mapping provider you want to use, using Accelerators [shortcuts to online services], is super important. If you spend all day searching, the ability in IE 8 -- especially with some subtle changes we've made in release candidate 1 -- to type into that search box, and easily flip between multiple search providers and get instant feedback -- that's a performance enhancement.

Developers have to add some code to their existing sites in order to test compatibility with IE 8. Are developers addressing that aspect of being prepared for IE 8's release?
That's at the core of what developers go and do now. The thing to understand is how to test. Then when they get the IE 8 release candidate and they look at their site, and if it works fine because of the way they built their site, then they're done. If it doesn't work well, they should try the compatibility-view button. What we've found is there are a lot of sites that rely on legacy IE behaviors, and so those sites, faced with an IE that has excellent standards compliance and interoperability by default, have some issues.

When the developer hits the compatibility-view button, if that makes for a better experience, then it's a very clear call to action -- add this tag so their visitors will by default get that compatible experience.

What feedback are you getting from developers about the compatibility features of IE 8?
We're seeing there are a bunch of folks who use the compatibility-view setting and think in the short term this is the most expedient way to make sure our customers have a good experience. That just comes down to the basic test and 10 minutes of work to add the appropriate tag, and that's fine. The biggest source of that are sites that expect legacy IE behavior. And that's the most expedient way to deal with that.

There are a whole other bunch of sites that have simply [stopped saying], 'oh, let's treat IE special and different,' and getting very good results. And that really is at the heart of what we're trying to do with IE 8. We want people to have a great, compatible experience, and we want them to create standards and interoperability. I think about it as all the pages in the Web today, and then the next billion Web pages. The standards default is going to be great for that next billion pages.

What we're talking about right now is in the short term, there's a partnership between developers and Microsoft to make sure customers have a great experience; it really is a mix. The thing that's great about the developers who are moving forward to take advantage of IE functionality is that they're in a position to provide richer AJAX experiences because of the HTML 5 support that's in IE 8, a back button that really works, or the send button that knows how to turn to a save button when network connectivity goes away, or the ability to have Accelerators or Visual Search. And the folks who are exploiting IE are in a much better position, especially facing a down economy, to keep in touch with their customers.

Think about it: No matter where you are on the Web, that Visual Search that you guys use from other sites, that's there, that's handy, you don't have to go to that other site. And that ability to really stay in touch with customers to reach beyond the page is crucial for developers.

How do you see IE 8 changing the way developers build their applications, the content that's going to run on sites and the sites themselves?
I think IE 8 is going to make it a lot easier because the dev tooling in IE 8 is so strong. The ability to do rapid iteration is huge. It's not just a source view of the code on your site, but it gives the developer visibility into IE's internal representation of the site. It makes it a lot easier for developers to identify and address issues. And when you step back from those details, what you realize is those dev tools -- for example, the script profiler, the thing that helps developers identify and fix performance related issues -- are huge. Those developer tools are built into every copy of IE.

So I think IE will make it a lot easier for developers because of the amazing dev tools, because of the better standards interoperability support and because of some of the leading-edge stuff that we're doing around the HTML 5 support. I can hardly wait to see what sites come to start taking advantage of this. You know what, that's really the next part of that developer call to action. Right now, let's make sure the sites work, then part two is, really, what has the developer done with this? Because there are some impressive sites -- really impressive sites -- waiting to be written that take advantage of these facilities.

What sorts of responses are you getting from developers regarding specific features in IE 8? How is Microsoft informing developers about the new capabilities like interacting with portions of other sites and shortcuts to other sites?
I'm finding more Web Slices and Accelerators as I browse the Web, so I feel upbeat about how the community is working with those [features]. We have an IE add-on gallery, where as a consumer you can try new ones out and as a developer you can volunteer yours. There's a regular rotation, and people can rate them and recommend them. The intellectual property behind those extensions, we contributed that out into the open. We have blog posts that describe the IT situation. At this point it's open opportunity: Open search, which we innovated with IE7, now has some visual aspects, and it's the same for Web Slices and Accelerators. It's a very low-risk investment. IE 8 will support it, but you'll see lots of other software support it in the future.

Is it likely individuals will subscribe to more than six or seven Web Slices?
I think six or seven is a pretty healthy number when I look at our instrumented data around how people are subscribing right now, in terms of the small number of sites that people really care about. As more sites offer that information, the number of subscriptions will go up dramatically.

What kinds of things are you trying to call developers' attention to?
I look at the CSS [Cascading Style Sheets] test suite, for example, and I think it really raises expectations. I think that developers have much higher expectations from the standards process and the developers involved.

Cross-site scripting [XSS] is probably one of the most innovative pieces in terms of really protecting people from a problem out on the Web. People didn't want to get ripped off before, but now in a down economy they don't want to get ripped off even more. The XSS filter is a real protection that's meaningful that I think deserves attention.

So there's a strong emphasis on CSS?
CSS 2.1 is a great example of a standard that's still under construction. You'd think we'd be done with it but the committee hasn't said, 'no, we're done.' The committee is still editing. The interesting thing about CSS 2.1 is it's really at the top of everyone's list in terms of what they use. To date, Microsoft contributed over 2,500 tests to the W3C [World Wide Web Consortium]. It's not that we just contributed to these tests; we took a lot of feedback and the community looked at these tests. We modified some of the tests and updated them and gave them back to W3C, and with release candidate 1 there will be over 1,000 more. This is part of the whole promise to developers: What platform do you want to write to?

Do you think we'll see fewer of these browser-security flaws moving forward?
I think security is an industry problem, and when we looked at the graph of security issues over time, it historically has oscillated, so I'm not sure if I want to make any predictions about the future.