Evolving ECMAScript

Bài viết
11/22/2011

For the Web and Web applications to keep making progress, the programming language of the Web must continue to improve. Today’s JavaScript standard lacks a few basic objects and library helpers that are vital for building rich, world-wide Web applications. Last week at the Ecma TC39 meeting at Apple’s campus in Cupertino, Microsoft shared reference implementations of proposals to address gaps in Math, String, and Number functionality as well as Globalization.

To ensure that others in the community are also able to provide feedback, we’re releasing these reference implementations via HTML5 Labs. We encourage you to download the prototypes, and play with the sample Web pages which demonstrate their usage. Try it out, and let us know if you have any feedback or suggestions in the comments.

These proposals provide a great deal of much needed functionality by adding only a few objects and library helpers:

Math	String	Number
cosh, sinh, tanh acosh, asinh, atanh log2, log10, log1p, expm1 sign trunc	startsWith, endsWith contains repeat toArray reverse	isFinite isNaN isInteger toInteger

Number Format	Date Format	Collator
format ( number )	format ( date )	compare ( x , y )

When running on Windows 7, the prototype implementation supports 363 available Locales, 18 numbering systems, many date patterns, and includes support for the Gregorian, Islamic, Hebrew, Buddhist, Korean, and Japanese calendars.

Note that as with all previous releases of HTML5 labs, this is an unsupported component with an indefinite lifetime. This should be used for evaluation purposes only and should not be used for production level applications.

Details on the proposals

Computationally intensive Web applications quickly demonstrate that the built-in JavaScript math library is missing basic functions such as cosh and log10 that have been available in other programming language platforms such as C++, .NET, Java, and Python for years. String and Number can also benefit from some basic functionality common to all modern programming language platforms like testing if a String starts with a specific substring or checking that a Number is an Integer. These are addressed in the proposed additions to the Math, String, and Number APIs.

Web applications have been harder to globalize than native applications because JavaScript has not provided native date and currency formats that the underlying OS has. The drop includes a reference implementation of the proposed Globalization APIs which enable applications to deal correctly with locale specific number and date formats and strings in other languages. With this library, developers can show date and numbers in the specified locale and set collation options for the purposes of sorting and searching strings. Developers can also set date and number formats to use alternate calendars like the Islamic calendar or to show a number as the Chinese Yuan currency. This means that JavaScript applications no longer have to round trip to the server to properly display locale specific dates and numbers, which ultimately translates to faster interactive applications for end-users.

The Role of JavaScript in Improving the Web

These proposals are just part of a larger story of the evolution of JavaScript. In 1998, a complex JavaScript application was a few dozen lines of code. By 2008, leading-edge Web applications like Hotmail, Gmail, and CNN.com included hundreds of thousands of lines of JavaScript. Today, there are Web applications with a million lines of JavaScript. These Web applications look more and more like the applications we run on our desktops, with fewer page transitions and more processing occurring on the client, relying on the server for the occasional burst of data rather than frequent expensive server round-trips.

JavaScript is evolving to meet these needs, and it’s important that it does so in a way that respects everything that developers have invested in their own Web sites and their skill sets by focusing on compatibility and incremental introduction of new functionality.

We strongly believe in the community process driven through TC39 as the keepers of these principles. TC39’s work on ECMAScript 5 is a solid step forward for JavaScript in the Web platform. Some of the principles used to design ES5 provide a good template for future versions of the JavaScript standard:

Preserving the fundamental syntax of tomorrow’s “text/javascript” to ensure continuity in the developer skillset and deliver seamless compatibility between today’s JavaScript and tomorrow’s JavaScript.
Provide features that are additive and pay-as-you-go, to help developers get more value with minimal new effort or learning.
Strive for features to be locally detectable, to help developers build applications that work on the broadest range of browsers.
Where possible, allow for a possibly slower library alternative (or ‘polyfill’) for browsers that do not yet support the feature.

We are working with TC39 on applying these same approaches as broadly as possible for the next revision of the ECMAScript standard.

Furthering the JavaScript Runtime

Looking ahead, there is a great opportunity for JavaScript to continue to evolve the core runtime. From talking to developers building HTML5 Web sites, we understand that these areas represent the most value:

Better integration with the native browser platform . With the introduction of recent APIs in HTML5, such as the File API, Canvas Pixel Array, and XHR2, there is an increasing need for JavaScript to have better interoperability with binary data streams. The need is so acute that there are many proposals across many Web communities and they are starting to converge in the Binary Data proposal. The Binary Data proposal aims to improve usability and expressivity for the use cases above.
Improved site load, especially for larger sites. JavaScript today would benefit from a standardized pattern for loading units of code consistently, in a way that won’t cross-contaminate the global scope, with a predictable loading order. A solution would benefit from being integrated into the runtime to ensure efficient page load times in coordination with the other browser subsystems. The modules and module loader proposals look like promising starting points which we aim to make available to scripts in “text/javascript” without needing to introduce breaking changes.
Execution performance and responsiveness. Libraries for interacting with intrinsic JavaScript types should continue to be filled out. As the String and Math extensions proposals suggest, JavaScript would benefit from an intrinsic string search like startsWith or contains and additions to the set of math functions to match other client platforms. JavaScript would also benefit from a format capability to replace variables in strings. Like ES5, when integrated into the runtime, these features can provide clear performance improvements for many real-world Web sites with minimal developer effort.

Larger Scale JavaScript

When building applications on a larger scale, developers depend upon high quality authoring and tooling experiences. For applications of this scale, higher-level abstractions such as classes and other common programming patterns can be the basis for better tooling.

The Office Web Applications, which consist of hundreds of thousands of lines of JavaScript, are written primarily in a variant of Script# that is then compiled into JavaScript that can be executed on today’s browsers. Other toolsets like the Google Web Toolkit take similar approaches. More recently, transforming compiler libraries like Traceur and CoffeeScript show how syntax additions to JavaScript and even completely alternative syntaxes can be supported in today’s browsers, without changes to the runtime.

Some examples, like Dart, portend that JavaScript has fundamental flaws and to support these scenarios requires a “clean break” from JavaScript in both syntax and runtime. We disagree with this point of view. We believe that with committee participant focus, the standards runtime can be expanded and the syntactic features necessary to support JavaScript at scale can be built upon the existing JavaScript standard.

The ECMAScript Standards Process

For the past couple of years, TC39 has been accepting proposals for new features to add to the ECMAScript standard. As we look at the current work being pursued in the committee, we see two categories of investments:

Work on the JavaScript runtime. This work (binary data, private names, globalization, etc.) offers valuable new capabilities to the platform, and can be made available in a feature-detectable way under the existing JavaScript script tags, allowing for smooth and near-term adoption of these features.
Work on JavaScript syntax. This work (let, destructuring, iterators, object literals, etc.) adds to the expressiveness of the JavaScript language, but also requires heavier weight versioning for developers, such as opting in to new script tags.

We prioritize the JavaScript runtime because it fundamentally limits the capabilities of the Web. We participate in the standards body to make sure these features can become ubiquitous tools developers can depend upon.

Looking forward to the future of the Web

As the Web transitions from Web sites to Web apps, and as Web developers build new experiences in HTML5, we know that JavaScript will also need to make this transition without compromising its simplicity, flexibility, or performance. An approach that enables broad, incremental adoption by the Web developer community has the highest chance of success. Many of the ideas coming forward in the community support these ideas, and Microsoft will continue to work in the ECMA TC39 standards body to refine proposals for the core JavaScript runtime advancements. Most importantly, progress on the standard should be based on a dialog with Web developers on what is most needed in the Web platform.

We welcome your feedback and look forward to continuing to participate in this dialog.

—Shanku Niyogi, Amanda Silver, John Montgomery, Luke Hoban, Steve Lucco - JavaScript Team

Comments

Anonymous
November 22, 2011
The comment has been removed
Anonymous
November 22, 2011
Good article I was just wondering about this. As a side note however a browser IL would be better than another browser language.
Anonymous
November 22, 2011
It's great that you're engaging like this and moving JavaScript forward. I can't help but think that we should be talking about a runtime standard rather than a language standard. Why not put ECMA-CLI on the table and provide a javascript implementation for it for browsers that don't support it (like the JSIL project).
Anonymous
November 22, 2011
Here's an idea for the next ECMAScript standard. Rename ECMAScript back to JavaScript!
Anonymous
November 22, 2011
The comment has been removed
Anonymous
November 22, 2011
jsPerf — JavaScript performance playground http://jsperf.com/
Anonymous
November 22, 2011
Not to change the topic too drastically, but Office Web Apps is written in a version of Script#? That's news to me.
Anonymous
November 23, 2011
I can get behind hanging "format" methods as statics off of string and Date, but I think the Math functions really would work better in a JS standard library. The "isFinite/NaN/Integer" shouldn't be in there, there are already methods for detecting those states in JS, again those might work in a stdlib.js. I'm not sure that adding some of those string functions would add much. I can see their usefulness, but again they seem more like stblib kind of functions.
Anonymous
November 23, 2011
The comment has been removed
Anonymous
November 23, 2011
Im with google, javascript needs to die. or at the most just use it as the assembly language of the the web.
Anonymous
November 23, 2011
The comment has been removed
Anonymous
November 23, 2011
Concerning "Larger Scale JavaScript": interesting that the Office Web Applications use Script#! <a href="http://www.jangaroo.net">Jangaroo</a> follows a similar approach: it compiles ActionScript 3 to JavaScript to support "programming in the large" for JavaScript developers.
Anonymous
November 23, 2011
Sorry about the broken link. Here we go again: http://www.jangaroo.net
Anonymous
November 24, 2011
Instead of focusing on a particular language we would be better served by a proper middle-tier byte code system. This could be .net or the JVM but both of those have too much baggage. A promising alternative is the Native Client with LLVM byte code. Unfortunately Native Client is a Google project, but hopefully Microsoft will consider it anyway. A common virtual machine with a standardized byte code will be much more efficient that translating everything to javascript. As for runtime library this would just be the same as HTML5 makes available.
Anonymous
November 24, 2011
The comment has been removed
Anonymous
November 24, 2011
I also agree that javascript needs to make way for something better
Anonymous
November 24, 2011
Great work regarding evolution of ECMAScript. Yet there is some serious performance issue with IE when dealing with DOM without using fragmentats nontroppo.org/.../Hixie_DOM.html. When compared to Safari, IE9 perform 258 times slower. More on connect.microsoft.com/.../a-dom-manipulation-test-ie-performance
Anonymous
November 24, 2011
The comment has been removed
Anonymous
November 25, 2011
Given Microsoft's previous track record of 'improving javascript' (explorer's badly broken window/global object, broken function expressions, broken try/catch scopes, dom elements' ids that become JS globals, broken JS garbage collector (the circular references bug), string concatenation bug, sudden unexpected deletion of expando properties, + etc etc etc) I shudder to think about any further 'JS improvements' coming from Microsoft.
Anonymous
November 25, 2011
@Jorge, steve and other trolls; checkout the standard compliance test on official ECMA website http://test262.ecmascript.org/. IE10 preview only fails 3 out of 11029 tests while your favorite browsers (Chrome/FF) fail more than 100. Keep your record straight and try again.
Anonymous
November 26, 2011
Can you guys try to fix the DOM please? It's down right terrible. "HTML5" is suppose to be the big thing on the web, but its not at all designed for display programming outside of document structures.
Anonymous
November 27, 2011
@Tester - I am not a troll. I have been contributing to the Web for over a decade including submitting 100's of bug reports to MSFT as well as helping other developers overcome IE's vast array of bugs. The IE bug with auto-globals has been well documented, and has been shown to be one of the worst things to happen to the Web in terms of completely derailing standards. I haven't checked yet, but you are likely right that the IE10 preview browser does very well on those tests (I would hope that an alpha/beta browser on the cusp of 2012 would be quite good at those tests. However as we were discussing although we are quite happy to see IE finally improving their standards support over the last half of the past decade - MSFT needs to be equally focused on clearing out the legacy bugs that made IE the bane of the Internet since 2000. All I was saying was that by all means step up and provide suggestions on improving the JavaScript language but don't forge ahead without fixing the bugs of the past - and more importantly, don't you dare use your 800 lb gorilla status to try and push your bugs on the W3C to adopt as part of a standard. We won't stand for it. It took approximately 8 (EIGHT) YEARS to get Microsoft to fix their document.getElementById(id) BUG(S) (yes, plural!!!). We just want to make sure that the broken behavior of mixing elements with NO CONNECTION into the same collection is not only NOT added to the HTML5 specifications, but also removed from IE completely so that developers can rely on a standard API, not this auto-magical-were-going-to-guess-what-you-want-thus-constantly-bork-it-up DOM access. @Tester - if you'd like to chime in on the specifics of this W3C specification item and how MSFT is pushing the W3C to adopt their broken behavior please by all means do so: dev.w3.org/.../Overview.html The more developers we have discussing the specs the better chance we have of getting these things fixed so that web development for us, and the next generation(s) of developers is easier, more reliable, and not burdened with legacy bugs brought in by deprecated browser behavior from IE6 and earlier. Steve
Anonymous
November 27, 2011
One of the most annoying issue for developers was selectDropdown.innerHTML to replace all the option elements. The issue is resolved in IE10 developer's preview.
Anonymous
November 28, 2011
@steve - agreed, that in combination with all the related .innerHTML bugs on table, thead, tbody, tr... it only took what... like 15 years to fix? :-P
Anonymous
November 30, 2011
The comment has been removed
Anonymous
November 30, 2011
The comment has been removed
Anonymous
December 01, 2011
Is nobody going to point out that .contains, .startsWith, and .endsWith can easily be done using regular expressions (.match(//), .match(/^/), and .match(/$/))? I'm all for adding new features that would otherwise take many (or at least multiple) lines of code, but these are just too simple to bother bloating the language with. And don't tell me regular expressions are too hard. The only hard part is remembering to escape special characters (.match(/$10/) won't work), so maybe a String.escapeRegExp function could be good, but otherwise people should just learn what they need to know about regular expressions.
Anonymous
December 04, 2011
The comment has been removed

Chia sẻ qua