

Sam Ruby, Brendan Eich, and Jeremy Ashkenas on CoffeeScript and "JS-next" - sstephenson
http://intertwingly.net/blog/2010/11/25/Hobgoblin-of-Little-Minds#c1292138238

======
gfodor
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.

~~~
jashkenas
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>

~~~
stcredzero
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.

~~~
BrendanEich
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.

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

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

~~~
stcredzero
_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.

~~~
barake
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>

------
jashkenas
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...](http://www.reddit.com/r/programming/comments/eb3xt/so_you_kids_want_coffeescript_do_you_brendan_eich/)

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

------
petercooper
_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.

~~~
BrendanEich
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?

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

That's a fantastic way of approaching web standardization.

