ECMAScript 3 and beyond - the road to "Harmony"

  • Article

The current ECMAScript specification was completed in 1999 and certainly needed to be updated to reflect today’s web environment and practices. Some participants in the standards process wanted to use what they thought of as a once-in-a-decade opportunity to make some significant changes that they felt would make the language better. Other participants, including Microsoft, were concerned about the ability of the web to “digest” such large changes and favoured a smaller set of revisions. There were passionate and well thought opinions on both sides of these issues and everybody seemed truly motivated by what they thought would be “best for the web”. However, the net effect of the disagreement was to block any real chance of actually achieving an approved revision to the ECMAScript specification any time soon.

 

Most of these points of disagreement have now been resolved. Rather than re-telling this story, we’d like to point to ECMA's press release and the accompanying white paper that lay out the agreements that have been reached in the ECMAScript technical committee. We think that these agreements set the stage for real progress in advancing standards-based web scripting and Microsoft is committed to being an active participant in making these advances. We want to thank and congratulate our colleagues at Adobe, Apple, Google, IBM, Mozilla, Opera, Yahoo!, and other organizations for working hard to get past these differences in order to find a common path forward for ECMAScript.

 

Pratap Lakshman

Allen Wirfs-Brock

Comments

  • Anonymous
    August 20, 2008
    PingBack from http://housesfunnywallpaper.cn/?p=1679

  • Anonymous
    August 20, 2008
    It's good to finally see an update on the JScript blog after so long. It feels like the forgotten/ignored language of Microsoft. I'm curious to what direction ManagedJScript will go? Is the plan to be ES3+ compliant? How will this correspond to the current state of the multiple differing implementations already being provided in the differing OSes? Will these differing branches ultimately be consolidated or some of them deprecated? ManagedJScript JScript.NET JScript 5.7 WSH Internet Explorer JScript Classic ASP JScript (ECMA-327)...Diet JScript?

  • Anonymous
    August 21, 2008
    Question 1: Will IE8 support a new level of JScript? Question 2: If so which version of ECMAScript will it be based on? Question 3: Regardless of ECMAScript version the biggest issue for Web Developers is IE's lack of following 2 critical DOM related issues. Properly supporting prototyping on Elements and properly supporting the DOM Event Listener methods.  Will these be fixed in IE8?

  • Anonymous
    August 22, 2008
    Congratulations on Harmony! I think it was the right decision. I have two questions on ManagedJscript. Question 1: Do you have a prediction on a release date for ManagedJscript. Question 2: Is there already (or will there be) a way to run ManagedJscript from a console (like there is for IronRuby and IronPython)? So far, the only containers for ManagedJScript that I have seen are ASPX and Silverlight. We would like to use it for batch files. Thank you Andrew Csontos

  • Anonymous
    August 24, 2008
    Here is some inspiration for IE 8: http://weblogs.mozillazine.org/roadmap/archives/2008/08/tracemonkey_javascript_lightsp.html

  • Anonymous
    August 30, 2008
    "It's good to finally see an update on the JScript blog after so long. It feels like the forgotten/ignored language of Microsoft."

  • That would be VBScript. It will be getting no new functionality, and last I read it was the Sustaining Engineering Team's responsibility. That's probably where it belongs, too :P. "JScript 5.7 WSH, Internet Explorer JScript, Classic ASP JScript"

  • Those are all the same thing, are they not? Are there different versions of JScript.DLL floating around for each of those? I thought WSH, ASP, and Internet Explorer were all merely host environments.

  • Anonymous
    September 01, 2008
    @TNO: Managed JScript is an implementation based on the published ECMAScript 3rd Edition Specification. By ES3+ (as you call it) if you are referring to a future revision to the ECMAScript standard, it is premature to make such a commitment; the definition of such an ES3+ is not yet complete. Nevertheless we are eager to hear your opinion and that of the community at large on such matters. @Clark: Regarding the first two questions, JScript is based on the published ECMAScript 3rd Edition Specification. It is reasonable to assume that for the short term JScript in IE will continue to be based upon ECMAScript 3rd Edition. Compatibility between ECMAScript implementations within different browsers is a major issue for web applications developers and Microsoft wants to help minimize this problem. As the new revision to the ECMAScript standard, IE will try to provide timely support for it. Regarding your third question, details regarding any support for DOM customization will be forthcoming through the various IE communication channels. @Csontos: At the moment there is no way to run Managed JScript from a console. Regarding your mention of batch file, I am very interested in knowing more about the actual scenario. @Les, @TNO: You are correct.

  • Anonymous
    September 09, 2008
    @Les Depending on system setup you may indeed have these versions side by side. Do a quick search on your computer for the .dll's and compare the versions. @Lakshman In regards to ManagedJScript, of course the community at large expects continued ECMA compliance at a minimum otherwise its a waste of time. Isn't that the point in  participating in ES Harmony? Implementing a branched, noncompliant version of ES 3.1 (or whatever its designation will be) would alienate the JS hackers since they would have no confidence in their learned skill sets and habits with the language. I'd hate to see ManagedJScript turn into another JScript.NET, broken then abandoned... Since the JScript team is committed to providing cross-browser language support, what is the road map for JScript 5.8 vs ManagedJScript? Is it parallel or planning to diverge? Since the other mainstream browsers are now pushing JIT compilers, will the response be replacing JScript 5.8 with ManagedJScript since there are already compilers to MSIL? (Not expecting an answer on this one) Csontos has a very interesting point. Right now we have available and JScript 5.7 in the WSH. A few years ago there was a mention of WSH.NET but that fell to the way side in favor of PowerShell. This leaves system admins and client side hackers who use this technology nowhere to go for new features except to learn a new language and have to port all their old code (JScript.NET was and is not the answer for this). Offering a client desktop compiler alternative for jsc.exe with the ManagedJScript compiler would be a major plus especially since there is a viable option now to actually have Visual Studio Support the language.

  • Anonymous
    September 29, 2008
    @TNO That is exactly what I was talking about when I mentioned a console container. We have tons of WSF batch files written in JavaScript.  It would be great to have something like a WSH.NET so we could access to the .NET library and still reuse all or most of our existing code.

  • Anonymous
    January 16, 2009
    Having a .NET version of WSH, based on the .NET DLR (Managed JScript, IronPython, etc...) would probably not let you use existing native WSH scripts that easily anyway, as most WSH scripts are heavily dependent on COM objects, which are not exposed exactly in the same way within ManagedJScript. As for a Managed JScript console, I actually have one working, but still in beta and based on a pre-release of Managed JScript. I worked on a command shell that supports hosting any script engine to interact with it interactively, including native JScript, VBScript, RubyScript, PerlScript, Python,... which is working fine since years, and the native version has a .NET DLR counterpart that lets you use IronPython (not yet updated for the released version though, but will be soon), and tested with custom builds with Managed JScript too. The current release is on http://www.phm.lu/products/MAS/ and includes IronPyton support. Managed JScript support will be included as soon as there is a build working on the release version of the DLR. The documentation actually already includes Managed JScript samples.

  • Anonymous
    April 25, 2010
    That is exactly what I was talking about when I mentioned a console container. We have tons of WSF batch files written in JavaScript.  It would be great to have something like a WSH.NET so we could access to the .NET library and still reuse all or most of our existing code.