Performance Considerations

During testing, I noticed a boost in application performance. Considering that I'm using a beta product to write this article, I'm definitely impressed.

The performance boost is most noticeable when working with database applications, pages that rely on client-side scripting, and pages that use client callback. The improvement won't fix sloppy coding practices, but it may turn a well-written application with a few performance problems into something that users enjoy using.

However, if you're relying on the old level of performance to reduce timing issues, you'll want to revisit them with IE7. You'll probably find that relying on a certain level of client behavior isn't a good idea, especially now that IE7 is faster.

ActiveX Concerns

ActiveX controls were a bad idea when Microsoft conceived them, everyone said how bad the idea was, and Microsoft still decided to introduce and use the technology. After having seen many examples of just how bad malignant ActiveX controls can get, Microsoft finally decided to add some protection for users in IE7.

Unfortunately, this halfway measure doesn't really help anyone. Users will be annoyed by having to OK every ActiveX control, every time one appears on a Web page; developers will find that their well-tuned applications work only half the time, because users are bound to click the wrong button at least that often; and Microsoft is going to continue taking it on the chin for a bad idea.

Since most other browsers (including Firefox) ignore ActiveX controls, you might want to phase out use of ActiveX in your applications. They were always a bad idea. Unfortunately, this one change is going to break many applications; everything from shopping carts to data collaboration.

Although applications that use ActiveX objects usually break when used in the Internet zone, I found that some worked when used in the Intranet zone, and they always worked in the Trusted Site zone. The determining factor seems to be whether the required controls already exist on the local computer. For example, I could use a SmartTag successfully in all three zones, but the required objects appear on my local computer as part of an Office installation and I've used them on other occasions.

The ActiveX control problem becomes worse when the user has Vista installed. Vista has a new feature called protected mode. All browser events must interact with a broker that severely limits access to system resources. If your application relies on files stored on the user's computer to perform certain tasks, it may work on Windows XP, but it definitely won't work on Vista. In fact, you'd better count on your application having access to cookies and information the user types into a form. The broker prevents scripts and other automation from downloading files or affecting the system in other ways. COM components will only have a self-realization; they won't be able to make changes to the registry, for example.