Evolving ECMAScript

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
startsWith, endsWith
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 (28)

  1. FremyCompany says:

    While I agree with you that keeping the syntax identical allows higher compatibility, you should note that introducing new syntax is needed at some point to introduce new features "the right way".

    Web applications are coming to a point where new browsers will become a requirement, not due to impossibility of making the app using fallbacks but due to poor performance and too high maintenance and bug finding costs.

    I trust Microsoft for doing the things right. ES4 was a mistake you saved us from. It was too much, too quickly. But syntax changes will come someday. Don't hesitate too much… or you will fragment the web scripting with tons of languages like CoffeeScript. It isn't a good idea. Or at least it doesn't seems to me.

  2. Lavinski says:

    Good article I was just wondering about this. As a side note however a browser IL would be better than another browser language.

  3. Joe says:

    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).

  4. Ideas Man says:

    Here's an idea for the next ECMAScript standard. Rename ECMAScript back to JavaScript!

  5. FremyCompany says:

    If the goal of JavaScript is to become an IL, maybe a true IL would suit better. JavaScript is a very nice language, I don't understand the current hype consisting in viewing JavaScript has an IL. If JavaScript was a lame language I could understand. But it isn't.

  6. Miguel Web developer says:

    jsPerf — JavaScript performance playground


  7. Peter says:

    Not to change the topic too drastically, but Office Web Apps is written in a version of Script#? That's news to me.

  8. Scott Koon says:

    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.

  9. Jon says:

    It's great to see Microsoft getting behind JS like this. I agree that evolving what we have is a better option than trying to start all over with a proprietary thing like Dart.

    I think the most important featured needed in JS is a short function syntax, like the => operator in CoffeeScript and C#. Given the increasing importance of functional programming, and the already core nature of first class functions in JS, it's high time we had a more convenient syntax for them in JS

  10. F says:

    Im with google, javascript needs to die. or at the most just use it as the assembly language of the the web.

  11. André says:

    Very nice, very true, but if you want all this to be worth a dime then PICK UP THE PACE. At the rate JS is currently evolving, those features will be introduced into the language in 2096, what do we do until then? setTimeout()?

  12. Frank Wienberg says:

    Concerning "Larger Scale JavaScript": interesting that the Office Web Applications use Script#! <a href="http://www.jangaroo.net">Jangaroo</a&gt; follows a similar approach: it compiles ActionScript 3 to JavaScript to support "programming in the large" for JavaScript developers.

  13. Frank Wienberg says:

    Sorry about the broken link. Here we go again: http://www.jangaroo.net

  14. Baldur Norddahl says:

    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.

  15. Mike Collier says:

    Really useful. Thanks. I'm going to try and apply this to: http://www.spiralyne.co.uk

  16. David Daly says:

    I also agree that javascript needs to make way for something better

  17. Xero says:

    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

  18. steve says:

    @Xero – IE8 is also dog slow on those tests… brutally dog slow.

    @Microsoft – I fully endorse your requests to improve JavaScript – on one condition:

    FIRST!!!!!! – Remove your request to FORCE ambiguous broken IE behavior onto other vendors vs. fixing your own IE browser:


    Under **NO CIRCUMSTANCES EVER!!!** should an ID and NAME attribute be part of the same collection due to similarities in the VALUE they contain.

    If I have 5 checkboxes with the NAME "item" and a div elsewhere that has the ID "item", these are 2 **completely** **mutually** **exclusive** sets that **I WILL NEVER** want combined **automagically** by the browser.

    We've fought damn hard to get bugs out of IE so that it can be a capable browser that follows standards.  Propagating the above bug by requesting that it be added into the HTML5 specs is a disgusting breach of developer trust, standards, and transparency.

    MSFT has already mucked up HTML5 with their lack of built-in non-DRM encumbered HTMLAudio/HTMLVideo codecs – please do not further ruin the Web.


    PS And for the love of all things sane, please fix this @#$dam mother !@^#$ing comment form on this blog!!!!!!! just use a standard form submit button because your attempts at doing fancy ajax stuff have failed massively! [/endrant]

  19. Jorge says:

    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.

  20. Tester says:

    @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.

  21. Tyler Egeto says:

    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.

  22. steve says:

    @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:


    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.


  23. @steve says:

    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.

  24. steve says:

    @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? 😛

  25. tommy says:

    JavaScript, HTML, CSS were designed to solve a problem of sharing and linking documents on the web.  They were never intended to be an application development platform and it shows.  I think a fresh start is needed to really move the web forward.

    Something a long the lines of a VM in the browser would make the most sense to me.  This has been proven in the server (JVM, CLR).  

    I really hope client side development doesn't have to suck for another 10 years.

  26. I completely agree with @steve and I also approve of the proposals as outlined above.

    Please remove the existing DOM and JavaScript bugs from any new versions of IE and properly support innerHTML, table, thead, tbody etc…

    To me, the DOM is the bigger problem but to be fair I'm no standards junkie. I only know what behaves the way I expect it to and what doesn't. So maybe some things are working as the spec indicates while others are not. Not my call, and to be honest I don't care. What I do care about is that things work consistently and for the power and ease of the developer.

    The different DOM implementations are the MAIN reason why so many specialized JavaScript libraries exist in the first place. Of course JavaScript is so flexible and powerful there's almost never a brick wall but the same cannot be said for the DOM. At some point you end up saying forget it and going back to your customer and say "Hey this is not a native application, what you're asking for is not possible in the web."

    For example, if I want to enter a tab character into anything other than a TextArea it's a cross browser nightmare and don't event think about trying to do text selection cross browser without a good JavaScript library to help. Iframe style and positioning, same problem. Funny enough, and in general especially with these elements, I usually appreciate to a greater degree, the way the Chrome browser behaves over IE or Firefox. While I have not had a chance to waste er. (spend) time trying these things in IE 10, they certainly still suck in IE 9.

    DOM elements are for developers, they are used to construct an HTML page just like bricks are used to construct a house. Don't give us element X in IE which behaves differently in browser (a, b, c, etc) and then expect us to continue being happy about supporting IE. Fix it or listen to rants like this and @steve's forever.

    For the DOM spec in general, stop limiting us when it comes to ContentEditable. For example, pull up an example of the Word "Office Web App". Start typing a letter to someone. Use the tab key to indent various paragraphs, notes, etc… Now inspect the live DOM, do you see the # 09 tab symbols in there or do you see nbsp characters over and over again? How will your document be saved to the server? How will the server know you pressed the tab key? It won't because the DOM cannot reliably handle the tab character so the server thinks you pressed the space bar 5 times. When you're trying to let your customer edit an existing document from another source this is really a problem because because formatting is not being applied consistently. #$ck!  

    This stuff isn't rocket science. It's just common sense. I truly believe the problem with MS and IE all these years is that they have just now begun to REALLY use the web and they are finally dogfooding, hence the improvements. Unfortunately, I fear it's going to take a while for them to discover and catch up on all the things we have hated for so many years. Most of these things are probably "news" to them and there's no comprehensive list of what all of the issues are. Just ask your Office Web Apps team. I'll bet they can share a bunch of crap they had to deal with to get the sub-par Word application working as good as it does.

  27. Regexp says:

    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.

  28. Gill says:

    @Microsoft you didn't clarify __WHEN__ you are going to remove your request to ruin HTML5 by forcing the specs to allow the invalid, undesired and utterly ridiculous intentional namespace collision between elements that are allowed to have a NAME (e.g. iframes and form elements) and anything that can have an ID (e.g. every possible element).


    Please explain that you intend to take care of this and fix this mess immediately before suggesting new things to add to JavaScript/ECMAScript.  We're tired of trying to build skyscrapers on top of IE's foundation of broken glass and wet cardboard.

    yesterday: ID != NAME

    today: ID != NAME

    tomorrow: ID != NAME

    forever: ID != NAME

    on planet earth: ID != NAME

    on the Internet: ID != NAME

    on Windows: ID != NAME

    on Mac: ID != NAME

    on iPhone: ID != NAME

    on BlackBerry: ID != NAME

    on Android: ID != NAME

    on any piece of software ever written: ID != NAME

    Don't you dare try and shove IE's broken behavior on ANY other browser, on ANY other device, tablet, phone, touchscreen, TV, fridge, toaster, car – or any other device that can connect to the Internet.

    FIX Internet Explorer ***BEFORE*** you go adding **ANYTHING** else!!!!!