3 ms·
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 th
by kbd 15y ago
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-blocks-procs-and-lambdas/ http://www.robertsosinski.com/2008/12/21/understanding-ruby-...
- Joeri 15y ago"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.
- BasDirks 15y agoSeeing 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.
- petermichaux 15y agoYes but many of the ideas in CoffeeScript were likely slated for ES.next before CoffeeScript. So it has been working in both directions.
- bgrohman 15y agoGood 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.
- petermichaux 15y agoThere was an ES4-to-ES3 compiler. The Traceur compiler takes many of the Harmony ideas and compiles to ES3.
- bgrohman 15y agoOops, meant to say "compiling new versions of javascript to old versions", not the other way around.
- aufreak3 15y agoWhat 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.
- yid 15y agoThis 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.