Over a million developers have joined DZone.

Where ECMAScript Needs to Go: Three Goals

DZone's Guide to

Where ECMAScript Needs to Go: Three Goals

· Web Dev Zone ·
Free Resource

Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.

We've been following ECMAScript a bit here on DZone, but so far mostly just specific suggestions, or reports on recent advances. This sort of spotty coverage helps me less than existing JavaScript ninjas, though, because I haven't even written enough JavaScript to get mad at its 'bad parts'.

What I can grasp better, though, is a post like this, from the IEBlog's JavaScript team.

The earlier part does give a specific proposal (for better math support -- which again even we non-JS-ninjas can get). But the rest of the article also outlines why these specific changes matter, and how they fit into the bigger picture of ECMAScript's evolution.

The three central desiderata for ECMAScript.next, according to the post, are:

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

This seems like a good way of putting it -- and an intelligible way of putting it to people who are less annoyed at JavaScript and more interested in how improvements in ECMAScript can contribute to the improvement of user experience that HTML5 and other new standards are being orchestrated to achieve.

Check out the full article for more discussion.


Take a look at an Indigo.Design sample application to learn more about how apps are created with design to code software.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}