Comment by kbd | Hacker News Reader

Comment by kbd | Hacker News Reader

Great and thorough article. Here's a TLDR:

* Javascript has some warts, and here are some examples.

* It's going to take way too long to get these fixed to the point that we can actually start using new versions of Javascript because of slow browser adoption.

* To get around this problem, people are treating Javascript as a compilation target for other languages, the most prominent example being CoffeeScript.

* Discussion follows of features that would make Javascript better serve its increasing role as a compilation target.

* There is discussion of Harmony throughout.

Sometimes offering a TLDR indicates that the article isn't worth reading "so here are the author's points so you can skip it". That's not the case here. For example, I learned about "Tennet's Correspondence Principle", which helps to give a name to the different ways procs/blocks and methods/lambdas behave in Ruby, as explained in this article[1].

[1] http://www.robertsosinski.com/2008/12/21/understanding-ruby-...

What if the standard could be changed from a language to a runtime specification? For example, a subset of LLVM assembler could play the role of a substrate (very much like what NaCl is doing) and leave the language part open. Runtimes with sufficiently rich capabilities can evolve over a much longer period than languages. This could liberate client-side coding from language specific-ness just like it doesn't matter what language you use on the server side.

That might sound a lot like Java, but it can can use some fresh thinking. I'm quite excited about NaCl on this front, for example.

This is a great idea, and I agree NaCl is the most exciting thing I've seen in a while. However, the modern JS engines already have JIT compilers for JS. As these improve more, JS effectively becomes your "bytecode". That's also an entirely reasonable direction that maintains backward compatibility.

"It's going to take way too long to get these fixed to the point that we can actually start using new versions of Javascript because of slow browser adoption."

Which isn't true, because you could compile newer versions of javascript to older versions. I see languages like coffeescript as interesting experiments in how the language can evolve, but eventually it needs to come back home to javascript and get deployed natively in browsers.

Seeing how a handful of ideas in CoffeeScript have been rumored to be included in the next JS release, it seems like individual experimental language design might be the way to push for change.

Yes but many of the ideas in CoffeeScript were likely slated for ES.next before CoffeeScript. So it has been working in both directions.

Good point. I hadn't thought of compiling old versions of javascript to new versions - that keeps everyone writing in the same language and seems like a better solution to me.

There was an ES4-to-ES3 compiler. The Traceur compiler takes many of the Harmony ideas and compiles to ES3.

Oops, meant to say "compiling new versions of javascript to old versions", not the other way around.

Reply on news.ycombinator.com