User:Shaver/ES4 FAQ
Contents
- 1 What is ES4?
- 2 If browsers implement the whole of ES4, will it break my existing scripts?
- 3 What sort of changes are in ES4?
- 4 Do I have to upgrade all my script to ES4?
- 5 Who is designing ES4?
- 6 What are the objections to the ES4 draft?
- 7 Will ES4 require me to specify types, or stop changing the properties of my objects dynamically, as I do today with ES3?
- 8 What is the status of ES4? How can I try it out?
What is ES4?
ES4 (ECMAScript, 4th Edition) is the name that will be given to the next revision of the ECMAScript language, the standardized basis of JavaScript and other similar languages. In this document, "ES4" refers to the current working draft, which is expected to be completed and ratified by ECMA near the end of 2008. An overview of this draft, including motivations for many of the design choices, is now available.
ES4 represents a significant and powerful evolution of the ES3 language, which preserves compatibility with existing programming models and "legacy" code while adding new, optional capabilities to support larger scale programming. It borrows capabilities and techniques from languages such as ActionScript and Python while making them fit with the spirit and existing practice of ECMAScript as used on the web and elsewhere over the last decade.
In addition, as with previous editions of ECMAScript, ES4 contains a number of bug fixes (XXX) to make the specification fit better with deployed behaviour and developer expectation, and repair plain errors in the specification text.
If browsers implement the whole of ES4, will it break my existing scripts?
No.
The ECMA committee chartered to develop and maintain the ECMAScript specification, known as "TG1", has taken compatibility with existing scripts as their number one priority. The vast majority of features in ES4 which could affect existing ES3 (JS1.x) scripts aren't available unless the script author explicitly opts into them. All bug fixes to the language specification are being checked extensively against real-world use, and will be tested in wide-scale browser deployments before the standard is finalized.
What sort of changes are in ES4?
There are several categories of changes introduced in ES4 which can affect existing ES3 code:
- opt-in facilities such as new keywords, which will not affect programs unless the new ES4 capabilities are explicitly requested
- bug fixes to match prevailing (often: all) browser support, such that the specification better reflects what developers can actually expect from implementations; programs that run in the real world today will be unaffected, obviously, as this is codification of existing practice
- bug fixes to match user expectation, where the ES3 behaviour was a trap for the unwary, and not useful in its specified form; the classic example is how this is bound in nested functions, which is one of the most confusing and anger-inducing defects in the ES3 specification.
A complete description of all incompatibilities between ES4 and ES3 (as specified; note again that many of the changes represent codification of what is actually implemented in virtually all engines) is available at XXX.
Do I have to upgrade all my script to ES4?
No.
Significant effort has gone into ensuring that ES4 code and ES3 code can interoperate simply, including preservation of argument types and values when ES4 values pass through ES3 functions and scripts. You can upgrade your code piecemeal as you need and want to use new ES4 capabilities, and don't need to give up your existing ES3 libraries or application code to do so. They will interoperate as you would want and expect; to make people do a wholesale upgrade of everything would make ES4 essentially useless, given the huge and valuable installed base of ES3-based code on the web today.
Who is designing ES4?
The ECMA TG1 committee has as member companies Adobe, Apple, Opera, Mbedthis, Microsoft, Mozilla, and Yahoo!; of these, all but Apple have been active in the ES4 process over the past two years, with Apple joining the committee activities much more recently. As of March 2007, Microsoft indicated that they were planning to implement ES4 "after IE7" (XXX link), but in April of 2007 both Microsoft and Yahoo! have registered their opposition to the current draft, and they have not contributed significantly to the specification since that time. The dissenting minority of TG1 have indicated that they believe the current draft proposal to be incompatible with ES4's goals of ES3- and web-compatibility, and of suitability for implementation on constrained devices and interpreters. As of this writing, there is no alternative proposal from Microsoft and Yahoo! for review by TG1, though they have indicated that they are working on one, and there has not been detailed explanation of how the design of ES4 fails to meet those (critical) goals.
In addition, there are several invited experts in the fields of type theory and programming language design who participate actively in the design of the language and have helped tremendously in the production of what the majority of committee members believe is a robust specification.
What are the objections to the ES4 draft?
As of this writing, no specific technical objections have been provided by the TG1 minority, only general "philosophical" concerns and "skepticism" about the ability of the design to meet its goals. It is not clear what specific elements of the draft are of concern, nor how they might be modified to alleviate the concerns of the dissenting minority. Some of the dissenting representatives have been working on issues currently in scope for ES4, such as Douglas Crockford's revision to the json.org APIs, which could possibly appear as proposals for ES4 at a later (but hopefully soon) date.
Beyond TG1, one noteworthy objection raised by Alex Russell and others is that the interface feature is not useful for web development techniques without accompanying generic method bodies (mixins (XXX link), or similar). These and other issues are welcomed for discussion on the es4-discuss (XXX link) mailing list.
Will ES4 require me to specify types, or stop changing the properties of my objects dynamically, as I do today with ES3?
No.
Even if an author opts into ES4's syntax-incompatible features as mentioned above, it's still up to them to use types, various "fixed binding" features such as classes and intrinsics, and any other ES4 feature as they choose. All the dynamism of ES3 is still available to script authors, but they will now also have options for reducing that dynamism or placing restrictions on how their code can be used, in order to improve security, performance, and reliability of their applications.
What is the status of ES4? How can I try it out?
The ES4 specification has reached the "proposal freeze" milestone set by the TG1 membership, and is now working on ensuring that the details of the design proposals accepted into ES4 are well-understood and well-tested. TG1 expects to submit the final specification to ECMA for approval by the end of 2008.
In addition to being radically more open than most other such standards activities (see the published meeting notes (XXX), for example), TG1 is also committed to producing a reference implementation that developers can use to test the language, especially to ensure compatibility of the specification with their use cases and existing ES3 code. The reference implementation is well underway, though not yet complete, and can be downloaded at (XXX).
Also, the Tamarin project represents another open source project implementing ES4, this time to "production" levels of performance and footprint. Tamarin is based on the ActionScript 3 engine deployed widely in Adobe's Flash 9 player, and is being jointly developed by Mozilla and Adobe as part of the Mozilla project, to be included in future versions of both Firefox and Flash Player.
Opera, renowned for their small-footprint web technology, has also indicated that they will support ES4 in future versions of their browsers, and have been providing very useful input on design choices that help ensure that ES4 is suitable for constrained devices and embeddings.