InfoQ

News

Is the future of JavaScript ECMAScript 4?

Posted by Rob Thornton on Nov 08, 2007 07:00 AM

Community
Java
Topics
Javascript
Tags
Yahoo! ,
Languages ,
Standardization ,
Microsoft

The discussion on the future of ECMAScript has been quite lively lately. Brendan Eich kicked off a flurry of posts about ECMAScript 4 and if that is the right path.

ECMAScript 4 is the next version of the standard which is implemented as JavaScript and JScript. With the publication of an overview of ECMAScript 4 Eich, the creator of JavaScript, has pushed forward the question of how will we get JavaScript to ECMAScript 4. While work on ECMAScript 4 is progressing, there are many who are unhappy with the specification, arguing that it is too much, too fast, and fails to address some of the critical issues of the language today.

After publishing the overview, Eich beat up on Microsoft for their lack of participation in the debate. That sparked a response from the JScript team at Microsoft, who are consolidating a list of all known divergences of JScript from the specification, as well as the generally accepted behavior of JavaScript. Microsoft believes that ECMAScript 4 is too big of a jump and Chris Wilson, Platform Architect for IE detailed his personal thoughts as well.

Douglas Crockford, a well respected JavaScript expert at Yahoo!, has reservations as well:

There are a lot of people who feel that JavaScript sucks, and are hopeful that the proposed language will suck less. My concern is that it may suck more. If new language is able to prove itself, then it may earn adoption. But it should not be standardized and displacing stable technology until it is proven.

Ajaxian has compiled several posts on the subject and even Dave Thomas has written about version 4:

Just browsing through the wiki shows a language which has prototypes, classes, multi-methods?, static types, dynamic types, etc, etc. This reminds an old guy like myself of other large design by committee languages such as PL/I, Algol 68 and ADA. These ambitious efforts all had smart people involved in the design and implementation but were unfortunately far too complex and came to the market too late. JS is intended to be a language for the people, not another language that only technical wizards can understand. If you are an Ajax developer or care about dynamic languages I suggest that it is time for you to speak up and help put ECMAScript 4 on a much less ambitious path than is currently being charted. Less is truly more when it comes to languages.

Keep up with the future of JavaScript here at InfoQ.

Unfairly pigeonholed by Paul Fremantle Posted Nov 8, 2007 12:12 PM
Can we just get a VM already? by Dan Tines Posted Nov 8, 2007 12:49 PM
Is EMCA Script 4 Necessary Right Now? by Peter Wagener Posted Nov 9, 2007 8:56 AM
JavaScript on big programs by Diego Fernandez Posted Nov 9, 2007 4:00 PM
It is the time! by Kaveh Shahbazian Posted Nov 18, 2007 12:34 AM
  1. Back to top

    Unfairly pigeonholed

    Nov 8, 2007 12:12 PM by Paul Fremantle

    I've been using JavaScript since maybe 1996 and I think its a great language. The naysayers who are trying to hold it back think of JS/ES as an old language they don't want to have to worry about, but its relatively young as languages go. If this was a new language like Ruby or Groovy, these changes would probably be seen as too little! JavaScript spearheaded many of the dynamic features that are now considered cool in the latest batch of languages, but has long been seen as just a toy language only good enough for hacking around in browsers. Holding its development back would be unfair and pointless --- its perfectly easy to define which version of the language a .js is targeted against.

  2. Back to top

    Can we just get a VM already?

    Nov 8, 2007 12:49 PM by Dan Tines

    I wish Microsoft would just completely open up the mini-CLR and we could just be done with these debates over Javascript once and for all

  3. Back to top

    Is EMCA Script 4 Necessary Right Now?

    Nov 9, 2007 8:56 AM by Peter Wagener

    I've spent the last two years doing mostly JS work, and I have to admit I like it more than I thought I would. Coming from the warm & cozy Java world in to the harsh, everything-is-a-compromise world of JavaScript was a bit of a shock, but once I got past that I've been pretty happy with the language. My question is this: do we need ES 4 right now? Can't we wait until the browsers and supportive technologies catch up to ES 3 before barreling ahead with a whole lot of new language features that would disrupt the momentum that JavaScript has (finally) got going for it? It seems to me that a lot of the technologies surrounding JavaScript need some soak time -- not another dose of frills around the language basics. The Dojo Toolkit just shipped their 1.0 release last week; Prototype and the libraries built on top of it are mature and stable; Google Gears holds a lot of promise for moving the browsers towards a full-featured development platform; The browsers themselves are (ever so slowly) moving closer to actually meeting the EMCA 3 specification. The smart thing would be to see how these technologies are adopted by developers in the real world first, and use those observations to help form the next version of the language. I am all for a lot of the proposed changes (namespaces and standardized OO syntax in particular), but the current 'extra' technologies already provide what I need right now, without having to wait for browser support. I figure the ES4 will be 'approved' at some point next year, and no one will care. The browsers will continue their march towards ES3. Developers will be curious about ES4, but mostly for academic reasons.

  4. Back to top

    JavaScript on big programs

    Nov 9, 2007 4:00 PM by Diego Fernandez

    This experience report form the Lively Kernel Project at Sun (http://research.sun.com/projects/dashboard.php?id=176): http://research.sun.com/techrep/2007/abstract-168.html Sheds some light in the current limitations of JavaScript... I think that is really on topic with the JavaScript/ECMAScript debate.

  5. Back to top

    It is the time!

    Nov 18, 2007 12:34 AM by Kaveh Shahbazian

    1 - EcmaScript 4 will suck! Because it ignores the time concerns. Developers can handle functional aspects of languages in a useful and practical manner by now (See: Ruby, Java(anonymous things(functions, types, ...), C#(Closures, Anonymous Methods, Monads!(Yes in linq!)), on-the-horizon-things(Erlnag, Haskell, F#, Scala, ...)). So here we are missing the good things: 2 - the power of JavaScript lies in it's functional aspects(Closures, First Class Functions) and very handy features like prototype-based inheritance(It is as practical as duck-typing in Ruby). So you are going to replace good features with bulky-stupid-coding-fashion of C#, Java and other pain-in-the-neck things. Now people are just starting to what JavaScript is! And I tell you it is a real ACCEPTABLE-LISP! Tell me; where you CAN define a beautiful DSL like JQuery? 3 - Please forget about EcmaScript 4; And try to make more useful things like FireFox! Cheers!

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.