Heh, I started this :) strange thing how the interwebs works.
I was searching like mad for a coffeescript + operator overloading and classes with private/protected methods.
In my desperate search I started to make a list with languages that compile to JS.
Then - an idea came to me. How about I put this in the coffeescript wiki, post it on Hacker News then people will crowdsource it.
It worked like mad, in an instant people were adding projects and I was organizing it.
Now I see people making sites/communities out of it. Small world. I guess it's a topic of interest.
PS
Crowd-sourcing is an amazing experience.
1. commit 8a0bae391e5711bce233ccac756d2b80070868da in CS wiki
2. Previous discussion in my original thread http://news.ycombinator.com/item?id=2075111
Previous submission & discussion is at http://news.ycombinator.com/item?id=2075111 , but as it was about 500 days ago and many, many things have changes since then, I thought re-submitting this wiki (by changing 'https' to 'http') would be OK and hopefully illuminating to some.
I'm particularly eager to learn how IcedCoffeeScript has changes since then. I'm starting a rather big CoffeeScript/Node.js project and I can't decide whether to go with IcedCoffeeScript (I love its simplicity), or go the 'async.js' way... If anyone has used both Iced and async, I'd be more than thankful if they could share their experience (I Would've asked this question on StackOverflow, but I'm sure it'll be closed within 5 minutes as not a real question or something like that).
I've used CoffeeScript both for front-end projects and node.js backends, and node.js based command line scripts (similar to what is often done in perl). It works great, but for things like command line stuff which typically runs synchronously, the CPS/callback style of programming gets really messy really fast. Using await/defer (as supported by IcedCoffeeScript) synchronous programming can be done cleanly, if you make sure you write all your own functions in a callback style, and then consistently use await/defer when you want to call them synchronously. Trying to mix the metaphors creates a huge mess; your own functions may be synchronous, but every lib you will be using will be async. Better to keep all functions - including your own - async, and then consistently call them using await/defer when you want sync behaviour.
I've been using iced for a small project I'm doing in node. It works remarkably well for me.
However, I've come to realize that it's biggest win is in forcing a simple convention on you for async code that makes it easy and clear to write even when you don't use iced.
One thing I forgot to mention about async.js: It's downright disgusting when you try to use it with CoffeeScript, so even though it's a mature, well-architectured piece of framework, I don't like to use it with CoffeeScript...
As someone who was just about to add some async.js to a CoffeeScript/Node project, I'd be very interested to hear about what problems you've had before I go and potentially do something stupid.
Why do so many languages choose JS as a 'middle' language? Is it something inherent to the language itself that makes it particularly easy/attractive? Or is it simply because of the availability of the interpreter in the browser?
When Rich Hickey announced ClojureScript he said "Why are we doing this? Because Clojure rocks, and JavaScript reaches." The simplest reason is because JS is the Language of the Web.
It's worth wondering why this is, and I don't really have an answer. In JS's infancy, Java was meant to be the Language of the Web and JS was its asthmatic younger brother. There are probably purely aesthetic problems which led to Java being overtaken by Flash, but I don't know. I sometimes like to say that Java looked consistent in every browser -- but consistently ugly. But Java is not necessarily fun to develop in either, and getting people to install Java always seemed like it was more pain than getting them to install the Flash plugin.
You can treat it as a black box, of course: even to this day, for lots of people, Java on the web just plain doesn't work. But I think you're asking why it doesn't work, and that's much more subtle. You know who would be an interesting person to ask? An advertiser. You see flash ads, you see JS ads, you see flat image ads -- but you never see Java ads.
In any case, I think JS won because it gave immediate gratification: you took the image that you had already placed on the page and, onmouseover, you replaced it with an animated GIF which you'd already loaded and cached. It was event-driven design with a GUI language that you already needed to know when you were making a web app in the first place -- you didn't have to learn AWT and Swing and such before you could make and place a drop-down menu; you just placed a SELECT with OPTIONs, the same as for a form.
When CSS replaced FONT tags and ECMA partly solved the problem of Microsoft trying to kill Javascript in favor of JScript, it became clear to me that JS was indeed the Language of the Web, and that HTML and CSS were just very smart declarative domain-specific languages for its GUIs. If you want a single lesson, there it is: make sure your language allows for declarative programming, and make sure your GUI language is declarative and event-driven.
Its other strengths would not necessarily have been strengths elsewhere. It's an asynchronous language with no race conditions. That's perfect for a responsive GUI, but it's probably wrong for anything which needs lots of processing power. It's got light objects and first-class functions, which is beautiful when you want to package data and write jQuery, but the cool stuff you can do with the Haskell type checker is pretty much not allowed by this model.
But those are the reasons why you might still prefer JS, even when other middle languages exist.
> You can treat it as a black box, of course: even to this day, for lots of people, Java on the web just plain doesn't work. But I think you're asking why it doesn't work, and that's much more subtle. You know who would be an interesting person to ask? An advertiser. You see flash ads, you see JS ads, you see flat image ads -- but you never see Java ads.
Well, to begin with, a typical Java applet take around 30 seconds to one minute just to load and start execution, usually suspending the whole page. There's nothing more annoying on the Internet for me than encountering an unexpected embedded Java applet. Hitting "back" and killing the Java process is almost subconscious reaction to me now. Java Web Start was actually something nice and I used it to launch programs and play games written in Java. It at least asks before hunging your browser up.
And then again, Java applets are consistently ugly. Maybe it has something to do with default GUI libraries, which look bad and break UI conventions. Only today I had to deal with a Java program that reinvented tree view, so that you couldn't rename elements without killing and reinserting them.
So yeah. Execution sucked then and still does now.
As far as why JS, source-map for debugging is a big deal here. This makes it a very good host language because it enables source debugging even when used as a compiler target.
Don't underestimate how influential Microsoft was. They were terrified of Java and did everything they could to kill it. There were problems in Sun's execution too but Microsoft's recalcitrance sealed the deal.
In our case (NS Basic/App Studio) we wrote a translator for VB style BASIC to JavaScript.
We wanted to create a cross platform development that could target iOS, Android and other mobile platforms. We started the project about 2 years ago, and saw a few key developments in the JavaScript space.
1. HTML5: the extensions did a lot to move it from a web scripting language to something that could be used for real applications. The Cache Manifest allowed the developer to specify a list of files to be stored on the device, so the app could run offline, with no access to a server.
2. Home Screen: The mobile platforms added the ability to pin web apps to the Home screen with their own icon, making it possible to start them much like native apps.
3. Performance: Work by the browser folks on the internals of the JavaScript engine resulted in huge boosts in performance. The results are in this table: http://www.nsbasic.com/speedtest.htm. You can see the transition from early BlackBerrys being able to run a few hundred JS loops per second to the Motorola Xoom at 718,000. The benchmark is simplistic, but the message is clear: JavaScript on mobile device is 1000 times faster than a few years ago.
It turned out that it was fairly straight forward to write the Translator. Yes, there were enough weird edge cases to question anyone's sanity to do this again, but the result works well. All the control structures translated one to one, so there was little or no drop in performance.
We then built a Visual Studio style IDE around it, with support for frameworks like jQuery Mobile, jqWidgets and Sencha to build a complete dev environment. It's been a lot of fun.
(and yes, you can use JavaScript instead of BASIC if you want!)
This is possibly going to be downvoted to oblivion because it's a "negative" post, but it's very true for many of us.
A lot of people, myself included, would rather not do any Javascript at all. Particularly those of us who dealt with it early on, since the 90s. It's a pain, a moving target of practices, compatibility and libraries, and quite simply, we hate it. There is massive demand for anything that successfully abstracts as much JS as possible out of the picture. Libraries like Jquery, Prototype, Mootools, ... and whole substitutive systems like Coffeescript, Clojurescript and those others listed.
Happens to Java too. These languages are intensely disliked by many people who have to deal with them because they are infrastructural in their environments. Their architecture is often forced on people who'd much rather program in something else.
Almost certainly the latter. And it's not so much "I want to design a language. Ooh, I'll make it compile to JavaScript!" as "Dammit, why is X so hard in JavaScript X but trivial in language Y? Hmm, I know...". To me, it's testament to just how dynamic JavaScript and prototypal inheritance are.
How would you not make it a middle language if you want a web front-end language?
The only other way I can think of is baking it up with the browser. Like Google is doing with Dart. But even they are making Dart compile to JavaScript to make sure you don't lose compatibility between different browsers who opt to not cook Dart in. I remember an interview with one of the Dart developers where he said that having it as a requirement that Dart compiles to JS was greatly limiting the potential of what they can do with Dart. But they can't opt out of it, because compatibility with other browsers is too important.
In short, they're using JS as a middle language because there's no other way to do it. JS is a terrible language, but because of how the web historically developed, we're forced to use it.
> In short, they're using JS as a middle language because there's no other way to do it. JS is a terrible language, but because of how the web historically developed, we're forced to use it.
Like any language, some people like it and some people hate it. I love it. If you stay away from the bad parts, it's a cool, flexible dynamic language. And it is pretty good to compile to, benchmarks of C compiled to JS for example are quite good.
I've heard that same argument for a long time from PHP people. Yea, these are all but tools we use for the job. But bottom line is, some tools are just worse than others at pretty much any real practical use. [1] You make it sound like you've read the Javascript: The Good Parts book [2]. I've read it too, and it's a great book I recommend for anyone who must work with Javascript and have no way out of it. But keep in mind that an important premise of the book is aid those who are in this position where they can't run away from Javascript. As shown by this thread of languages that compile to it, it's often perfectly possible to dodge the shortcomings of JS by just not using it. You shouldn't torture yourself for no good reason. If you are in a position where you must work with JavaScript. Then I recommend reading this book to learn to stay away from the bad parts, as you said. But if you can work with any of the compilable languages, I highly recommend you stay away from JS as much as you can.
I would repeat the exact same argument for using SASS or LESS instead of CSS. There is no good reason to torture yourself with CSS instead of these better languages. It's very clear that there is such thing as one language that is much better than another in every practical sense.
His argument wasn't that "it's just a tool for the job" but that JavaScript is actually a rather cool language. And it is. At any rate, I certainly like it more than most other "scripting" languages, except maybe for Lua.
I would never suggest using most of the languages on that list over JavaScript. In fact, the only ones I recommend are Lisp, Ocaml and Haskell. Maybe something like Ur/Web as well. Coffeescript is good too, but it's basically lightly improved JavaScript. I find JavaScript simpler, more expressive and generally nicer than most of the other languages listed (ignoring the ones I've never seen or used).
Ultimately, JavaScript is a nice language with some warts. But, for whatever reason, the warts are blown out of proportion compared to other languages--in my experience (out of the languages I've used significantly) Python, Perl and Java all have more significant shortcomings. I think the main reason is that JavaScript position in the browser forced a lot of people to use it against their will, which leads to more complaining.
I think javascript's main "problem" is the combination of duck typing with prototypal inheritance. People coming from a classical strictly typed OO language are very put off by that.
Ofcourse, my problem is I'm so used to javascript's duck typing that I now feel horribly constrained by a strictly typed environment.
I'm the creator of LiveScript (http://gkz.github.com/LiveScript/) which is on that list. Feel free to ask any questions!
LiveScript has unnested callbacks, paren free chaining, function composition and piping operators, proper list comprehensions, and a lot of other improvements over CoffeeScript.
Most of my changes would be unacceptable to Satyr, the maintainer of Coco. For instance, I posted an issue about creating proper list comprehensions in both CoffeeScript and Coco, and both times was shut down. That's why I decided to create my own project, and make the changes I want without being shut down all the time. I don't expect any of my changes to be merged into Coco or CoffeeScript, but if they want to then I would encourage them to do so.
Funny to see this post together with LLVM 3.1 announcement on the same page as both are used as backends for programming languages these days. Now question, is this world gone mad? While I can justify existence of CoffeScript(it is only a nicer Javascript, with similar or improved semantics), the whole hype about the "assembly of the web" is ridiculous. Shame that with all the advances of the technologies today we have to compile to Javascript.
IMHO such lists are rather useless without information about the state of the compiler, indicators for active development, financial situation (who pays the bills?), community size etc.
It's just an index so you can see if your favourite language is supported. Follow the links for the rest. You couldn't trust extra information in the wiki itself because most of the details you need would get outdated pretty fast.
[..]
Family (share genes with CoffeeScript)[citation required]
And now you have to find a tertiary source (not even a secondary, or god forbid first-hand, like for example coffeescript.com) that proves that they share genes.
I'm not trying to be funny or sarcastic, so don't downvote me! That's what Wikipedia is, for better or for worse.
This might work if you create a category and add these languages to it. Ontology-wise you would need one category for the compilers that target javascript (subcat of compilers), and another for languages (primarily?) designed to be compiled as JS (subcat of programming languages). And maybe one more for languages+environments that compile as JS, primarily run in browsers, and wrap some browser APIs in their standard library.
I just discovered Perlito thanks to this list, and it's awesome (compiles perl5/perl6 to Javascript/Python/CLISP/Go/Ruby). I don't know what it can be used for but I like it :)
I was searching like mad for a coffeescript + operator overloading and classes with private/protected methods. In my desperate search I started to make a list with languages that compile to JS. Then - an idea came to me. How about I put this in the coffeescript wiki, post it on Hacker News then people will crowdsource it. It worked like mad, in an instant people were adding projects and I was organizing it.
Now I see people making sites/communities out of it. Small world. I guess it's a topic of interest.