Responding to Change: Updated Getter/Setter Syntax in IE8 RC 1

Original: Responding to Change: Updated Getter/Setter Syntax in IE8 RC 1

As a Program Manager, I love to write feature specifications (that's a job description requirement)! In each spec, PMs carefully weigh the pros and cons of certain design tradeoffs, consider the customer requests, available feedback and telemetry data, etc. Based on all of that information, we make certain informed assumptions about what we would like to build and how. Despite our best planning efforts, we know that some of the assumptions made in early specs may change at any time through development. One of these common ar

Responding to changes in web standards during the middle of the product cycle can be challenging for a variety of reasons. Speaking strictly from a development standpoint, feature changes always come at a cost—usually a trail of product bugs which take time to find and fix. Other changes are risky because the standard that they are based on could change. Each time we consider a change, we must carefully weigh the consequences.

In this post, I'd like to describe a significant recent event in the evolution of one web standard and how we chose to respond to it in Internet Explorer 8. I think this post offers a unique view into the complexity involved in responding to changes in web standards during development, as well as a great forum to announce the change in the upcoming release candidate.

ECMAScript 3.1

ECMAScript, the standard that defines JavaScript, was last updated almost 10 years ago. Earlier this year however, a revision that has come to be known as "ECMAScript 3.1" began to make rapid progress toward standardization. Back when we started work on Internet Explorer 8, we expected that any new ECMAScript developments would occur soon enough to give us ample time to integrate them into our planning; we were motivated to revisit that expectation with the recent rapid progress of ECMAScript 3.1. In particular, we wanted to be careful not to introduce features into Internet Explorer 8 in a way that would be incompatible with what we could see coming in the ECMAScript 3.1 draft.

ECMAScript 3.1 includes many extensions to the JavaScript language that make web development easier and more powerful. One of these features is JSON support and we quickly decided that the native JSON API in IE8 needed to be the same as the JSON API that is included in the ECMAScript 3.1 draft. Another feature from the draft that quickly came to my attention was support for getters and setters.

DOM prototypes

For many months we've been working on a feature that helps make the DOM more compatible with the JavaScript language by introducing the concept of JavaScript prototypes to the DOM. Using DOM prototypes, savvy web developers can easily extend HTML elements and other DOM objects with new functionality, develop more powerful libraries and abstraction layers, and even replace any built-in properties and methods with their own. This was one of our top-requested programming features by influential JavaScript experts. One very important part of the feature was getter/setter properties in the DOM.

Prior to 3.1, ECMAScript did not include the concept of getter/setter properties, but some JavaScript implementations did support them using an API that is mutually supported by several other major browsers and programming environments. When we started working on DOM prototype support, we chose to implement that de facto getter/setter API.

ECMAScript 3.1 made an early decision to include getter/setter properties but by using a more flexible API rather than the de facto API. This decision was made with the concurrence of all the major browser vendors including those who currently support the de facto getter/setter API. With ECMAScript 3.1 in full swing and other browser vendors bought-in, we now had an important decision to make: do we respond to this unexpected change and pursue implementing the ECMAScript 3.1 getter/setter API for the DOM, or do we ship what we have and tackle the ECMAScript 3.1 API in a future release?

The answer really came down to what was best for the web developer; they need interoperability and by ensuring that we support getters/setters as outlined in ECMAScript 3.1, we help deliver that interoperability in the long-term. Given that we were mere weeks away from shipping Beta 2 and did not want to put the quality of that release in jeopardy, we felt it was important to release the existing implementation (de facto getter/setters) to give web developers a chance to test and find any significant bugs rather than cut the feature from Beta 2 (saving it for RC 1). We appreciate the feedback we've received thus far, and have been able to take the requisite time to respond to compatibility issues that we might not otherwise have had the time to do.

Standards first

I'm now pleased to announce that with the upcoming Release Candidate of Internet Explorer 8, we not only have a high-quality DOM prototypes implementation, but we've been able to change the getter/setter implementation to follow the draft ECMAScript 3.1 standard. While our JavaScript engine and DOM won't have support for all of the ECMAScript 3.1 enhancements in this release, it does mean that web developer code written to add getters and setters to the DOM in Internet Explorer 8 will continue to work now and into the future, since that code will be based on web-standards.

I'm very excited about this new capability in IE8! To help you get started, I've written a few articles that provide an introduction to DOM prototypes and getter/setters (and the new syntax that will be publicly available in the upcoming release candidate build):

• Document Object Model Prototypes, Part 1: Introduction
• Document Object Model Prototypes, Part 2: Accessor (getter/setter) Support

Also, some of you may have noticed that MSDN has also been updated to include the prototypes available in Internet Explorer 8!

DOM prototypes and getters/setters allow for some pretty cool programming possibilities. In an upcoming blog post, I'll get into more details on some of the scenarios that IE8 makes possible. Please leave a comment and tell us what cool scenarios you've already implemented using this feature!

Returning to the topic of responding to change, what may initially appear as the best design for the web may change over the course of a product's development. The experience I had with DOM getters/setters in Internet Explorer 8 has personally confirmed this. As we finish IE8 and on into the future, we'll continue to gather the right data, listen to customer feedback, and make product changes where appropriate. I know our team cares a lot about web standards and supporting them as a way to achieve interoperability—which ultimately helps web developers to be more productive; embracing ECMAScript 3.1 is one more step to help get there sooner.

-Travis Leithead
Program Manager