Google Releases JavaScript.next to JavaScript Compiler Traceur | Hacker News Reader

Google Releases JavaScript.next to JavaScript Compiler Traceur

code.google.com

139 pointsssclafani34 comments

Mascara (http://www.mascaraengine.com/) is a much more mature project that implements ECMAScript Harmony, though it's not open source.

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.

Mascara focus on being stable and usable in production more than being a testbed for experimental language features. But will definitely look into Traceur for inspiration and perhaps adopt some of the more stable features. I am very happy to see other implementation of some of the Harmony features. (I am the developer of Mascara.)

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.

My impression was this is a test bed for new language features, not a fork of the language or implementation of any particular future standard.

One of the devs here. It's definitely not intended to be a new language. My understanding is "text/traceur" was chosen because some of the features haven't been accepted officially into harmony yet (i.e. they are strawman proposals: http://wiki.ecmascript.org/doku.php?id=strawman:strawman), in particular classes/traits and async.

Amusing to see how many former C#/.NET compiler and framework developers are on this team. And they even used the "await" keyword!

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

The `await` keyword is part of a Harmony proposal (not Traceur specific):

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

If you look at the changelog for that page, the person responsible for all the edits is Peter Hallam, who is one of the Traceur developers at Google and was also formerly on the C# compiler team at Microsoft.

What about the "shorter function syntax" (from strawman http://wiki.ecmascript.org/doku.php?id=strawman:shorter_func... )? I'm crossing my fingers and toes that this makes it in.

This seem to be a "bike shed" issue where everyone have their favorite syntax. Mascara supports function(a,b)a+b. "function" is still long though, so other suggestions is "#", "^", "fn", the florin-sign, "lambda" and others.

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.

Brendan mentioned that he was wanting to keep # for something else and just adopt the coffeescript -> as the short form.

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

Was the set of syntax examples given.

Traceur dev here. It's on the to-do list. We've been mostly focused on stuff that's either approved for Harmony (modules, spread, etc.) or that we think will need a lot of iteration (classes, traits). I'm personally really keen on a better function syntax (especially a single-expression-body one).

We definitely could use something like this.

Generators (yield) look very nice, especially when combined with deferred functions. The nicer scoping of let/const and yield are the two things I prefer of gjs (which is built on top of Spidermonkey, which supports those features) over Node.

You can actually combine generators with pseudo-deferred functions today in normal JavaScript 1.7+. For example, see async.js (https://github.com/eligrey/async.js). Disclaimer: I wrote the library.

gjs has something similar: http://git.gnome.org/browse/gjs/tree/modules/promise.js

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!"
    });

The nice thing is the synchronous feel of doAsyncStuff() although it's actually pausing at each yield, waiting for a callback, and continuing execution from there.

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

Now need to combine Traceur with CoffeeScript :)

Seems like someone did it with Narcissus instead:

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

Not really. The talk that tweet is about was on the module loading system and was a demo of Dave Herman's experiment of adding a hook to the module system. The traceur compiler transforms js extended with various js.next proposals into (ugly) js that will execute in current browsers. You could define a traceur hook in Dave Herman's system to get the traceur extensions in Firefox today using Narcissus/Zaphod.

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.

I made this comment awhile ago:

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.

You really need to look at Coffeescript (http://jashkenas.github.com/coffee-script/) and Emscripten (https://github.com/kripken/emscripten).

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.

Emscripten was actually creatd by a Mozilla employee. He has mentioned that Mozilla is interested in it.

sgk284 is on the mark with emscripten and to a slightly lesser extent coffeescript. But another project to keep an eye on is Google's Native Client, particularly the paradoxically-named Portable Native Client (PNaCl). If anything becomes the next standard scripting extension to the browser, PNaCl stands a good chance of being it, IMO. Once we have that, the browser really isn't much inferior to any other applications platform.

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.

"You can also create your own iterable objects. Normally this is done via the yield keyword (discussed below in Generators) but it could be done explicitly by returning an object that has __iterator__"

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

There is a precedent for double underscores in JavaScript, for example the __proto__ property. However that convention is usually reserved for private APIs, which arguably __iterator__ isn't.

The double underscore syntax is used in Javascript already for getters and setters: this.__defineGetter__

The naming here comes from Mozilla's earlier implementation (https://developer.mozilla.org/en/JavaScript/Guide/Iterators_...). Personally, I would have preferred iterate().

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.

There's a nice JSConf presentation on Traceur: http://traceur-compiler.googlecode.com/svn/branches/v0.10/pr...

The paper "Yield: Mainstream Delimited Continuations" (http://parametricity.net/dropbox/yield.subc.pdf) states that yield in mainstream languages is equal in power to delimited continuations.

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

Mozilla (and Mascara for that matter) already supports yield.

i see no macros, why not add the feature that lets users add features?

I'm on the Traceur team, but I don't speak for all of us (or Google). Personally, I think macros would be really cool, but they're a challenge in a language that isn't homoiconic, has both statements and expressions, and a pretty complex grammar. I don't know if it would be possible to design a general purpose macro system within those limitations that was usable by mere mortals.

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

I'd also like to see macro capabilities in JS, although as others have said it's not trivial (but certainly not impossible) to add.

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.

Wouldn't it be harder to use macros effectively in a non-homoiconic language?

That's a fair point. Would the AST strawman proposal (http://wiki.ecmascript.org/doku.php?id=strawman:ast) get you most of the way there? If nothing else, it would make some metaprogramming of the source tree possible. Combine that with module loaders (http://wiki.ecmascript.org/doku.php?id=harmony:module_loader...) and I think you're pretty close to macros.

Reply on news.ycombinator.com