What is Traceur? It doesn't claim to be an implementation of ECMAScript Harmony, though it looks similar to one. The choice of a non-ECMAScript media type (text/traceur instead of application/ecmascript;version=harmony or something similar) lends me to believe that they want to create a new language entirely. Also, text/traceur doesn't isn't registered, so the private type, text/x-traceur should be used instead. It's unfortunate that library authors completely disregard media type registration nowadays. In order for text/traceur to be registered, there actually has to be a formal specification of the Traceur format, since it's on the standards tree.

It's great to see work in making Harmony more accessible to everyone, but it doesn't make sense to make it another language.

Most of traceur seem to be already supported in Mascara, but I am definitely looking into "traits" and especially "await", which I believe is a much needed addition to JS.

Definitely could be a compelling project, especially if they implement a type system as they've hinted.

http://wiki.ecmascript.org/doku.php?id=strawman:deferred_fun...

I think #(a,b)a+b is somewhat ugly, but it might win because it is unambiguous and doesn't collide with existing identifier.

My favorite lambda syntax is C#'s (a,b)=>a+b, but this may be rejected because it requires lookahead to parse.

    (x) -> x
    (x) -> (x * x)
    (x) -> {
       for(let i = 0; i < x; i++){
           console.log(i);
       }
    }

You end up writing code like:

    function doAsyncStuff() {
        let result = yield someAsyncCall();
        result = yield someOtherAsyncCall(result);

        if (result) {
            Promise.putReturnFromGenerator("foo");
        } else {
            throw new Error("No result!");
        }
    }

    let promise = Promise.fromGenerator(doAsyncStuff);
    promise.get(function(result) {
        print(result); // -> "foo"
    }, function(error) {
        print(error); // -> exception toString() -> "No result!"
    });

It would seem as though Traceur's deferred functions replace the need for the generators by doing the continuation through the "await" keyword.

https://twitter.com/clint/statuses/65523157737537536

As for getting the Traceur features in coffeescript, all you'd have to do is add the new traceur keywords to the coffee grammar as keywords (to avoid treating them as implicit function calls) and then run the coffee compiled js through traceur.

For myself, there are two things that are really pissing me off: 1) Lack of security by default, 2) Lack of choice in client-side scripting. I am at the whim of JavaScript which is pretty terrible. Of course, there is no hope of anyone producing a browser that offers an API, and a set of languages that can access that API. So it's just JS. That's fucked to me. I have more gripes but I'd like to keep this post short. On the server side, it's easier. We have more choices, because our clients are not tied into a specific server technology; I used to write PHP, but since then I moved on to something that's a lot more thought out for serving webpages. MVC is the ideal for this kind of thing. The server will give the browser what it wants, and this does not concern the customer. On the browser end? We are screwed. There is quite likely nowhere to go. Unfortunately, we have four big companies (Google, Microsoft, Mozilla and Opera) pouring in a lot of money to keep this technology afloat. And it's very sad. These companies should be leading the way, not holding back technology.

Glad to see things are moving forward. I hope this leads to a more general API later on down the road.

I use coffeescript for all of my javascript development now and life has never been better. I've never used Emscripten in a serious capacity, but both of these projects are under very active development and show that javascript really is becoming the x86 of the web (as stated by Brendan Eich).

No need for us to wait on the four big companies. Things are moving forward without them.

I'm guessing it will become more of a focus for Google as their Chrome OS matures. If it's a big success for Chrome, perhaps it'll spread elsewhere.

This clearly seems to be borrowed from Python; even the double underscores are present, which looks a little odd in javascript.

Traceur doesn't use the same Python-style semantics as Mozilla does: it doesn't throw an error to stop iteration. Instead, it's closer to Java or C# where moveNext() returns false if the iterator is done.

Thus it's possible that Traceur brings delimited continuations to JavaScript, which are the tool for inverting (and abstracting) control flow.

I see macros as being useful for two things: 1) DSL-type "make my own inner language" stuff, and 2) conditional evaluation. JS is already pretty syntactically flexible, especially with object literals, so that covers some of (1). JS already has closures, so if we can get a nicer function literal syntax, that makes it tolerable to do (2) just by passing functions around (and it's more explicit, which is good to some people).

For what its worth JSShaper [http://jsshaper.org] may be of interest although it doesn't provide macros per se. It's an extensible framework for JavaScript syntax tree shaping (rewriting/transforming). For a macro-like example, I described how I created an assert plugin for it here: http://blog.lassus.se/2011/03/c-style-assertions-in-javascri...

It gives you the power of macros and some, but with more power comes more complexity. Declarative style matching and rewriting remediates some of that, and it's the direction I'm taking JSShaper in.