eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I always wondered how vendors go about making decisions when they’re working on a product and the core standards defining the technology behind that product are in flux. Typically, if the standard is important enough to the vendor, it is involved in any standards effort governing the evolution of the standard in question. And it has some say in what the standard will look like.
Such is the case with Microsoft, its Internet Explorer browser, and the ECMAScript standard, which is the standard that defines JavaScript. As JavaScript lies at the heart of any browser, Microsoft has been actively involved in the shaping of the ECMAScript specification.
Indeed, Microsoft helped defeat a proposed ECMAScript 4 specification in 2008, instead pushing for the completion of what will be known as ECMAScript 3.1. However, as the ECMAScript standard has not changed since ECMAScript 3 came out in 1999, it’s clear that a change is due. And it is coming soon, while Microsoft is smack-dab in the middle of finishing up work on the latest version of its browser, IE 8.
So, as Travis Leithead, an IE 8 program manager, wrote in a recent blog post:
“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 areas of change is in the Web standards space-therefore we plan extra time in our schedule to re-evaluate current conditions and make changes to the product if necessary.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.“
Leithead goes on to specifically explain how Microsoft worked to respond to changes in Web standards during the development of IE 8. “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,” he said. “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.”
For instance, ECMAScript 3.1 includes many extensions to the JavaScript language that make Web development easier and more powerful, Leithead said. “One of these features is JSON [JavaScript Object Notation] support and we quickly decided that the native JSON API in IE 8 needed to be the same as the JSON API that is included in the ECMAScript 3.1 draft,” Leithead said.
Whats Best for the Web Developer
Leithead said another feature from the ECMAScript 3.1 draft that quickly came to his attention was support for getters and setters. A getter is a method that gets the value of a specific property, while a setter is a method that sets the value of a specific property.
Leithead noted that 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. And when Microsoft began working on DOM (Document Object Model) prototype support, the company chose to implement that de facto getter/setter API.
However, “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,” Leithead said. “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.”
Click here to read more about developing and debugging in IE 8.
Yet, being at that time just weeks away from shipping Beta 2 of IE 8, which shipped in August 2008, Leithead said Microsoft felt it was important to release the existing implementation with the de facto getter/setters rather than cut the feature from the beta release.
And because the company wanted to take a “standards first” approach, “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,” Leithead said.
Meanwhile, back to the issue of dealing with a standard in flux while finishing development of a product based on that evolving standard, Leithead summed up the IE 8 team’s experience thus far:
“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 IE 8 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.“
How do you think Microsoft is doing in developing IE 8 while helping to shape the ECMAScript standard?