Steps Toward Creating Compatible ECMAScript 5 Implementations

As we’ve discussed in the past, Microsoft has been actively involved in the developing the specification for the next revision of the JavaScript standard, ECMAScript Fifth Edition. We expect that after ECMAScript 5’s completion and formal adoption later this year that it will be relatively quickly adopted by browser implementers as part of their ongoing release cycles.

When a new browser standard like this is introduced, it is important that all implementers work hard to make sure that they correctly implement the standard and are compatible with each other. Language specifications are complex technical documents and even well written specification can be misinterpreted by implementers leading to incompatibles and interoperability issues.

One way to avoid this is for implementers to use a common specification compliance test suite.At the ECMA TC39 meeting this May, Microsoft announced that it was working on such test suite and made a preliminary version available to the ECMA members. We have now turned development of this test suite into a community development project hosted on Codeplex. This project is released as using the new BSD open source license and will be coordinated by TC39 members including Microsoft. Currently the test suite includes about 900 tests that mostly focus features that are new to ECMAScript 5.This is a small fraction of the tests that will be needed to provide complete conformance coverage for the entire language.Microsoft plans on continuing to contribute additional tests to the suite and we are working with other ECMA TC39 members to coordinate with any test suite development they may be doing.

Anyone who has the interest and skills for developing individual ECMAScript conformance tests are invited to participate in the project. If you’re interested check out the Codeplex site and get involved.

1.) Work on JScript to get it on par with Gecko 1.9.0 and Presto 2.0, performance isn’t everything, the ability to code something with less code is. In example things like importNode are absolutely critical.

2.) XHTML! I know there are other things that need to be put in place, but we’re not willing to wait for standards to be implemented ten years after they debut.

3.) CSS3 selectors…but more importantly properties. We know border-radius is going to make the cut but multi-column layouts, border-image, and multiple-background-image support are also high demand items. You guys don’t have to go nuts with CSS3 support and proprietary implementations with -ms- property prefix is more then welcomed even by hard-core standards enthusiasts. We know that not all standards are finished and could change…but we would rather adjust this via conditional comments in the future (entirely reliable) then have absolutely no way to support whatsoever.

4.) Customizable GUI…yet it seems you folks have decided static counter-intuitive is the way to go. Time to stop asking developers who simply code and ask designers who know how people in the real world interact with things.

IE8 (in regards to IE) was a solid respectable release. Cover all four of these important points and IE will really become desirable to work with instead of having to "deal with" like IE6. Things like Acid3 are nice and all but they don’t automatically represent what the most dire needs to be fulfilled by browser vendors for web designers (and web developers outsourced to do web design.

Oh and one more point…

5.) Stop calling web designers web developers! If you work on serverside code you’re a web developer, clientside a web designer, Flash/SilverLight a graphic designer…and someone can be a mix of any or all, but the terms themselves are not interchangeable.

Looking forward to the silence on IE9 being broken in the coming months. Good luck to your team with everything.

Stop calling web designers web developers! If you work on serverside code you’re a web developer, clientside a web designer, Flash/SilverLight a graphic designer…and someone can be a mix of any or all, but the terms themselves are not interchangeable.

</snip>

REALLY??? I mean I’ve actually spent a great deal of time working on both the client and server, I have to respectfully disagree. When I’m writing network connectivity "drivers" for the browser, or Object containers, I’m no web designer, I’m crunching data. Web designers IMO make layouts, images, flow couture and probably 1k other things I don’t even know about :-). One is not below the other, but I just perceive one to be more quantitative/science and the other art/science, I can honestly say.. I’m no web designer 🙂

@Richard of Tally Good point and I was unaware of such a position, good to know. Would you then consider yourself a clientside developer or something else?

@Nathan L Smith, I would say with substantial experience with both clientside and serverside that I feel there is still a clear distinction. Individually I’m sure it’s subjective to how each of us would refer to ourselves, the code we each do, and how we refer to the positions we fill…though I would argue for standardizing position names to better differentiate between people with two different capabilities.

@Will Peavy Hopefully ECMAScript hacking won’t be an issue…if the IE team releases IE9 for XP with the suspected greatly updated version of JScript (granted there is subjectivity from numerous positions in numerous debates) it would certainly make the slice of JavaScript 1.5 only browsers (essentially IE 6,7,8) disappear even if people stick with XP for a few years…otherwise if the IE team does not at least release IE9 for XP we could be facing some instrumental headaches in XP/IE support even with the work accomplished in IE8 over the next few years with people who’s computers have not outright failed (e.g. blown PSU) which would force them (if lacking the presence of a technical person) to buy a new system.

Again I’m very excited about hearing more about IE9 and especially the JScript improvements. 🙂

1] Could we expect a fully compilant IE8.5/IE9 (regarding the ES3.1/ES5 spec) ?

2] Does that mean that you’re working on a "new" JScript interpereter/compiler/virtual machine ?

3] Will JScript.NET be updated too ? For DotNet 4 or will this take more time ?

4] Could I (and other benevol developpers) get a preview of the new JScript engine (when it will be available) before the release of IE9 Beta to test it and point out problems or things you (could) make faster ? (Ok, I presume No by default, but who doesn’t try have no change to get what he hopes)

@FremyCompany: We haven’t finalized plans for the next version of our JavaScript engine, but have a strong interest in seeing it support ES5 and on getting some kind of preview into the hands of interested developers. As we know more, we’ll keep folks updated through this blog. As for Jscript.NET, we’re still talking about what we want to do with it.

Even if many work have been done with JScript for IE8, many work is still to be done (IE8 is the less ES5-compilant browser regarding to your set of ES5-tests about new major changes from ES3; IE8 is the slowest browser on JScript performance tests (SunSpeeder & others), …)

You’ve got a great challenge and a lot of things to explore : hard but funny work [;)]

The test suite is only useful to test the browser’s compliance or can the end user’s application javascripts could also be tested through these tests? It will be great to have a TestSuite or tool, that can parse through all the javascript code used by end user applications and be able to find some potential issues (if any) when we migrate towards ECMAScript5.

Theorically, it should not change anything to normal JScript use. They have added new features and clarified some border-edge cases, but you don’t need to modify your scripts to make them ES5-compilant.

Even if many work have been done with JScript for IE8, many work is still to be done (IE8 is the less ES5-compilant browser regarding to your set of ES5-tests about new major changes from ES3; IE8 is the slowest browser on JScript performance tests (SunSpeeder & others), …)

You’ve got a great challenge and a lot of things to explore : hard but funny work [;)]

According to the IEBlog, ES5 will be heavily integrated into IE9. And it looks like it will not be available outside the browser as a generic scripting engine (called now JScript). Can someone confirm this?

The IE9 WILL NOT be available for an OS that's older than 10 years. Plus: even if Microsoft would do this they had to port the whole graphics engine to XP. Meaning to run IE9, you have to have DirectX11 installed. An uprade would be the size of at least another SP, maybe 1-2GB and any OEM vendor had to check their drivers again (espeacially for laptops).

I don't know why some people just say 'this and that has to be done' but don't know anything about the whole thing.

The IE9 WILL NOT be available for an OS that's older than 10 years. Plus: even if Microsoft would do this they had to port the whole graphics engine to XP. Meaning to run IE9, you have to have DirectX11 installed. An uprade would be the size of at least another SP, maybe 1-2GB and any OEM vendor had to check their drivers again (espeacially for laptops).

I don't know why some people just say 'this and that has to be done' but don't know anything about the whole thing.