Sam Ruby, Brendan Eich, and Jeremy Ashkenas on CoffeeScript and "JS-next" | Hacker News Reader

Sam Ruby, Brendan Eich, and Jeremy Ashkenas on CoffeeScript and "JS-next"

intertwingly.net

65 pointssstephenson17 comments

The bottom line is while all the debate about how to improve Javascript is going on, all the while with no real changes coming to all browsers (I'm looking at you, IE), Jeremy went ahead and shipped something that's great that you can use now. As usual, the people who ship will win. Good luck with all the wrangling of the big vendors to change a tiny bit of syntax, I'll be happily sitting here writing CoffeeScript today.

All that's missing is a layer of tooling in modern browsers (Chrome, FF) that make it so you can look at CoffeeScript as if it were in the browser, and the abstraction would be pretty complete. You'll still have to precompile the stuff on your server, which sucks, but practically speaking we're not talking about anything that can't be clean and easy to use without appropriate tools. Generally speaking client side code is short and sweet, so running your system in development mode where the script compiles on the client and doing a full compile server side for production mode isn't that far off from doing a debug vs release build in the world of native apps.

Brendan opened a Firefox ticket this morning to make line-number mapping possible, and that's really the biggest outstanding issue for debugging, since the semantics are otherwise one-to-one. In fact, it would make <script type="text/coffeescript"> tags a lot more fun to work with than they already are, since debugging through an "eval" would be far less painful if exceptions pointed back to the proper position in the original source.

https://bugzilla.mozilla.org/show_bug.cgi?id=618650

We could go one step farther than line number mapping and just define and implement a standard for full-on support for original source pointers. Then we could implement any number of langs using minified Javascript as an intermediate language.

The bug I filed based on Jeremy's suggestion is about source coordinates, not line numbers. We are way past the ancient mistake of numbering lines but not columns, which bites minifiers all the time.

I'm not sure I believe in a new "built from scratch" standard language for the web. Sure, we could get rid of all the JavaScript cruft and mistakes, but wont we just replace them with fresh cruft and mistakes in the new language?

I believe in evolving the core JavaScript to be more flexible, and then innovate at a level above JavaScript, like CoffeeScript (or my own http://mascaraengine.com).

ECMA should not so much focus on building more powerful abstractions (like classes, packages) into the core language, but rather on making the core more flexible. E.g. adding continuations (if possible) would be much more valuable than adding classes, because classes can already be emulated at a higher level.

Stronger support in browsers for debugging would help everyone.

I'm with you there, to an extent. My bet is on some sort of bytecode standard as the next step in client-side browser code. Language designers could iterate more rapidly with a common compilation target at a level lower than JavaScript.

All the major browser JS implementations are moving towards the same type of VM. It's just a matter of time before one of the browsers adds support for running bytecode from a <script> tag.

The web moves forward by progressive enhancement, not by grand sweeping redesigns. So I think "JS-next" will be motivated not by committees and specifications but by incremental attempts to expose technology that's already in place (modern browsers' fast JS VMs).

Yes, yes! Standardizing the VM is better than standardizing the language. But please don't standardize a Javascript VM that run JS fast but runs, e.g. OCaml relatively slowly (compared to a native code compiler). For things where performance is important, having fast languages run really fast is more valuable than having a slow language run somewhat fast.

Using something like LLVM IR would be great, and that's what Google is doing with native client.

The question is how that bytecode should look to provide benefit. If it's just a bytecode equivalent to JavaScript, it won't provide much benefit except parsing speed - and I don't think this is a big issue anyway. A typical stack-based VM will not provide continuations for example.

So I think "JS-next" will be motivated not by committees and specifications but by incremental attempts to expose technology that's already in place (modern browsers' fast JS VMs)

If we had some sort of standardized support for "original source pointers" then we could have any number of languages in the browser as first-class citizens. They would just use minified JS as their compiler target. Development and debugging could be entirely in the new languages.

This would be a relatively small change, but it would open up innumerable opportunities.

Something like the #line directive [1] from C# would be useful, though it would only work in pre-compressed JS. The real challenge would be adding support in the various 'developer tools'/consoles.

1: http://msdn.microsoft.com/en-us/library/34dk387t(VS.71).aspx

We had a pretty good discussion about browser bytecode a month ago: http://news.ycombinator.com/item?id=1893686

You're right: the temptation to build from scratch is strong, and probably inappropriate. I think we're dealing with two fundamental problems:

1. Most developers don't grok JavaScript. The object model (prototype-based) really throws off a lot of folks, and the fact that JavaScript can't seem to make up its mind if it's classical or prototypical doesn't help. There are numerous other problems as well made evident, and worse, by the lousy code you see floating around.

2. Fixing and improving JavaScript moves at a glacial pace due to the rate of turnover in browser versions. Chrome has it right insofar that they make upgrades automatic, easy and transparent. As always IE is a major problem, and MS' refusal to adopt a Chrome-style upgrade process isn't helping any.

The original blog post that kicked off the conversation is here: http://brendaneich.com/2010/11/paren-free/

Some previous discussion and counterpoints here: http://www.reddit.com/r/programming/comments/eb3xt/so_you_ki...

The idea about supporting source coordinate mapping in Firefox/Firebug is great! This could make it much more pleasant to debug generated JavaScript.

So your “do both” suggestion is good, if it is possible: evolve JS while tracking up-and-coming languages, and try to align JS as it evolves with the best-of.

C# seems to have pulled this off over the years. It keeps taking ideas from other languages (I'm mostly aware of the Ruby ones) and leaping forwards. It's just a shame there's a stigma attached to it.

Good point. C# also has the advantage of being single-vendor if not single-designer.

That single-vendor status, and the identity and reputation of the particular vendor, account for a lot of the stigma, in my opinion. This in spite of C#'s technical merits and more responsive evolution compared to, say, Java (which is also all too clearly single-vendor now, if it wasn't always).

JS evolution is on the uptick, but can Ecma TC39 keep pace while specifying the changes correctly and clearly?

"Let a thousand little languages bloom, before picking your bouquet."

That's a fantastic way of approaching web standardization.

Reply on news.ycombinator.com