the_future.exe

If you have been paying attention, you may have seen the controversy surrounding the development of the next generation of JavaScript. There is a lot of stuff going on – see Google blogsearch for ES4. Here are some of the blog posts that together should give you a fairly comprehensive perspective:

neilmix.com has a great overview of the ES4 process
haxe.org presents a similarly good overview of the companies and interests involved
controversy side A: Chris Wilson at Microsoft posts his opinions
controversy side B: Brendan Eich responds to Chris Wilson
Colleague Hรฅvard also gets some discussion going

In a nutshell: Mozilla/Adobe/Opera disagrees about the future of JavaScript with Microsoft and Yahoo representatives. Even though they've spent two years polishing the spec and worked out a lot of details, apparently the Microsoft people think the whole process should start over again, and the funny thing is that the arguments they use to back that up is that the group should focus on exactly the things they have been working on all the time – backwards compatibility with ES3, security, speed etc. Whoops.

ES4 is a remarkable effort. They are trying to change one of the most widely used programming languages in the world fundamentally, yet upgrade it in a way that means all older programs written in it will remain working! And that's no small challenge – I guess more individual programs are written in JavaScript than in any other programming language. I'm no expert on programming language design, but I doubt any language rewrite has ever taken place with a similar scope and under such constraints.

Given the language overview (PDF) and list of incompatibilities with ES3 (PDF) it seems they may just have succeeded in the "don't break the web" requirement. The incompatibilities are minor, and many of them will make the spec more, not less compatible with the web than ES3 was.

For all the controversy, I think ES4 will gain a surprising momentum. It will get implemented in Mozilla and Opera, where it will gain mindshare among authors of extensions and widgets. It likely takes us a couple of years and iterations to get everything right, but that isn't so bad with the rapid release cycles Mozilla and Opera typically have. Many of ES4's features are aimed at library authors, who will start writing their libraries in ES4 for the better performance and debuggability and possibly use automated conversion tools to create ES3 versions to serve the older browsers. Tools like GWT may add possibilities for compiling ES4 and automatically serve browsers the correct library. The ScreamingMonkey IE-plugin will probably have to overcome a lot of technical problems and issues but it might just work. Compatibility issues with existing content will be smaller than the occasional problems WebForms2 caused. All in all, I think this won't be more disruption than the web can handle – and most of the disruption and bugs will be experienced by the early adopters who are in it for the ride :).

One of the coolest things about the ES4 process and spec is that the team working on ES4 also has created a "reference implementation" – now, that's a pretty amazing thought: while we design the language, let's make sure it is implementable and usable by writing an interpreter as we go. This is a great idea for several important reasons:

* The specification will be somewhat battle-tested, not purely theoretical
* They will uncover bugs and contradictions in the spec by writing the implementation – this is usually our headache as browser vendors, because when specs are incomplete or self-contradicting we have to figure out what to do. Vague and underdefined specs is a serious and underestimated source of browser incompatibilities and bugs!
* Browser vendors can use the reference implementation to see correct behaviour if the spec after all turns out to be vague on some points
* They plan to run the reference implementation through existing JS test suites, which is an ingenious way to ensure that ES4 will be compatible with ES3 and not risk breaking the web (hear, hear, Chris W! ๐Ÿ˜‰ )
* And last but not least: you and me can play with the new language immediately. That's right! Simply by getting the interpreter from the ES4 group's download page we can get a sneak preview of the language immediately! We can even file bugs for either the spec or the implementation.

They might as well have named the binary the_future.exe . :hat:

Here's a few things you can play with when you get the new toy: unzip it somewhere and run "es4.bat" on Windows, "run" or "es4" on Mac or Linux. You'll see a command line. This is where you can type ES4 statements and see the output. You can also issue commands :help and :quit.

For example, you can now see for yourself why Chris Pine loves ES4 and test out the decimal maths. Type

1.1 + 1.3

and press enter. You'll see not 2.4 but some ugly number with lots of decimals. Now type

1.1m + 1.3m

and voila, you've just tried decimal maths in JavaScript!

You can declare local variables that only exist inside a block with the new "let" keyword. See it in action:

>> { var a=1; let b=2; }; typeof a;
number
>> { var a=1; let b=2; }; typeof b;
undefined

The braces create a block, so after the closing brace the let variable b does not exist anymore. This will make it easier to improve performance when writing large scripts.

One of the major changes is that you can specify what type of data a variable should contain. This makes it easier to debug large scripts, because if unexpected assignments occur you'll see the errors at an earlier time (but it is strictly optional, so you can keep writing non-typed code if you wish). Here is a demo where I define a variable that must be a String:

>> var foo:String;
>> foo = new Number(1)
**ERROR** EvalError: uncaught exception: TypeError: incompatible types w/o conversion
>> foo = new String('aa')
aa

You can even define your own types! Just use "type" a bit like you'd use "var".

>> type coords = { x:int, y:int }

And, with much controversy – drumrolls – ES4 has classes and class-based inheritance right next to the regular prototype-based inheritance.

>>class Point { x:int; y:int  }

Note that the reference implementation still has bugs, so not all the features in the language overview work as expected yet. At the moment it is a toy :), but a shiny new one that might teach you a thing or two about the future. Have fun.

Advertisements

11 thoughts on “the_future.exe

  1. shadowk: I have not tried most of the features yet, but my understanding is that the backward compatibility should keep JS as flexible as it currently is. In other words, it doesn't have to feel like Java ๐Ÿ˜‰ but it can if you're writing something that should be re-usable in a way that is best implemented with class-based programming.

  2. I've read the specs, and i do not know why it makes me think that the people behind it took every new language "feature" that appeared since ES3 was developed.Ohh and the fact that iterators throw a Stop Iteration error makes me think of try/catch which is kinda strange and could have been done better.It also makes me feel like coding Java, a language which i do not really enjoy using.Btw, why isn't Google involved?They have a lot of products that depend on js so i think it would be normal for them to take care any new "standard" won't break their suite of products.

  3. It still makes me uncomfortable that a minimal language is being turned into such a complex beast, but ES4 is definitely very exciting.I can't figure out how to get the specs though. All I find is stuff like discussions and proposals at wiki.ecmascript.org. The wiki has a spec section, but it's unaccessible and labeled "known obsolete".Mozilla changed the way for-in loops work between JavaScript 1.7 and JavaScript 1.8 (bug 366941), and I want to see the specs that required that change. There are proposals where JS1.7's way would be valid and proposals where it would be wrong.

  4. Hm.."let", wonder what will happen to closure if "let" is implemented would this still work like in ES3 with var?

    function foo(){
       var a = 1;
       let b = 2;
       function bar(){
         return b;
       }
       alert(bar());
    }
    foo();
    

    got to test this one

  5. Regarding the new complexity: some mailing list members have looked through the new features and done some math to conclude that ES4 is about twice as complex as ES3. It sure seems like there is a lot of new stuff to get familiar with – and I have no overall impression of how the bits are going to fit together. For example I can't figure out the apparently stupid question "when should I use custom types and when should I use classes?" yet (if you are more familiar with Java than I am it might be obvious..)Yet I try to keep in mind that the more complex new stuff is aimed at the true professionals, the library/extension/widgets/web application authors. Most authors can and will keep writing JS the way they've always done, and that's fine. The success criteria for ES4 might be "sneaks in over time as better code for browsers that can handle it" rather than "widespread immediate adoption".More comments on specific issues:shadowk: your feedback on iterators is more than welcome on the es4-discuss mailing list.HeroreV: I too think the spec should be available even if only a draft, I'm not sure why it isn't but it is likely to contain much the same information as the "proposals" section on the wiki.Regarding what Google is up to: no idea, ask Larry and Sergey :-p . But if us browser vendors come up with good, solid implementations of ES4 I expect those brilliant PhDs at Google can't keep their hands off the new features eventually :)Let variables and closures: this was recently raised on the mailing list, it is AFAIK still an open issue but Lars T Hansen was arguing that implementing closure for let variables would be considerably more complex than an implementation where let vars are not part of a closure, so "won't work" might become the final answer.

  6. Originally posted by HeroreV:

    It still makes me uncomfortable that a minimal language is being turned into such a complex beast

    But that's the beauty of it, isn't it? You don't have to use everything if you don't want to.

  7. Originally posted by HeroreV:

    It still makes me uncomfortable that a minimal language is being turned into such a complex beast, but ES4 is definitely very exciting.

    I keep reading this opinion on many blogs.Guys, the point is we want the Web to evolve, to allow us to build serious Web applications, not just toys, Web sites. We do not want to use Flash, Silverlight or any other proprietary technology for serious Web development.Obviously, ECMAScript must evolve to the level of complexity required by complex Web applications. You simply cannot build highly complex, performance-efficient, Web spplications with a simple scripting language.I've also read the opinion that a new language should be written for "complex stuff". Why? Why make a break? The guys from ECMA TG-1 made this spec which allows us to write simple ES3-compatible scripts, while we can also use new features. That's very, very good. You can't ask for more.Additionally, I consider this kind of work "too late". In the sense that Flash, Silverlight, and Apollo already provide capabilities which go far beyond what HTML+CSS+JS+SVG can do, for now. Here's a point: "we will soon be able to make Web sites as eye-catchy as the Flash ones, with XHTML+SVG+JS+". Doesn't this sound sucky? It does, but it's a painful truth: we can't do that just yet – maybe only in experimental Firefox/Opera builds, but the result won't be usable for at least 1-2 years (too buggy for now).
    Yet, I believe once we get there, the possibilities will span wider than Flash will be able to offer (I can provide arguments). That's really good.
    So, there you have it: ES4 should have been finished two years ago. The same goes for HTML5 and CSS 3 (at least some modules).
    There's this "fear" about feature-creep: well, doh, let's drop all the features of the Web, and let's go back to square one. Better yet, let's make the Web such that we can only embed plugins (Flash, Silverlight, insert-your-favorite-plugin).
    By the way, there was the same kind of beauty associated with Flash ActionScript 1, back in the days of Flash 4-5. It was easy-peasy to write your scripts – just like with JS. That changed with AS2, and now with AS3. You can write full-blown Flash applications with AS3. Yet, you can still write simple scripts.

  8. one last note about iterators, which i shall add to the mailing list too.According to final draft page 26.

    for ( i in obj )
      print(i)
    

    is equivalent to this:

    let ($it = o.iterator::get(true)) {
     while (true) {
       try {
            i = $it.next()
       }
       catch (e: iterator::StopIterationClass) { 
            break;
       }
        print(i)
     }
    }
    

    which looks a lot like python(wiki)

    it = iter(sequence)
     while True:
         try:
             value = it.next()
         except StopIteration:
             break
         print value
    

    My question is wouldn't it make more sense to borrow the way Java(wiki) does it?

    Iterator iter = list.iterator();
    //Iterator<MyType> iter = list.iterator();    in J2SE 5.0
    while (iter.hasNext())
        System.out.println(iter.next());
    
  9. Shadowk, the reason I've heard for doing it this way is efficiency. Java's way requires two calls to the iterator and a test for every cycle through the loop. With the exception way you only have to make one call for each cycle, and it doesn't require a test (assuming while(true) was optimized away).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s