List of languages that compile to JS | Hacker News Reader

List of languages that compile to JS

github.com

96 pointsclyfe55 comments

Am I the only one who just plain doesn't understand the value these tools provide? From my perspective, why not just _write_ javascript? Seems ridiculous. I mean, they're fun and all, but no one sets out to do a project of meaning or scale and chooses these tools, do they?

I enjoy using CoffeeScript on my hobby projects. If you write your server code in a language like Python or Ruby, CoffeeScript makes Javascript more familiar. It adds nice features like list comprehensions, and I prefer the way it handles classes and objects. But no, it isn't for everyone.

The same reason people don't just write in assembly (or more accuratley, C) to write a desktop application very often. Javascript is the assembly language of the web.

That analogy breaks down though. JavaScript is just as much of a high-level language as most of the things that are compiling to it. Most of the time the reason people don't just write in JavaScript is because they don't like it's _style_, rather then with C or assembly, where the goal is to work at a higher level to avoid writing boilerplate and managing things are are unnecessary.

It doesn't break down entirely though. Imagine we were all restricted to C++ for writing desktop software (although that's nonsensical, it's the case with JS and the web) - wouldn't it be reasonable to start developing other languages that compile to C++?

If you can output JS that's fast enough, why not?

I agree with you esp. when it comes to GWT - going from Java to JavaScript is going from a terrible language to an ok one. There are two reasons why it has become popular:

  Java programmers don't want to learn JavaScript
  It comes with good UI building tools

If GWT didn't have good UI building tools, Java programmers wouldn't have any excuse not to learn JS and program normal web applications. But here's a tool that lets them use their existing Java knowledge to build halfway decent web GUIs.

This is just another example of how technologies are chosen by considerations other than objective technical merits.

Google Wave and AdWords were built on GWT, which is Java->JS. So yes, they do.

AdWords UI didn't start out on top of GWT, I think they switched over sometime in 2009.

I used to think the same way as you do... I couldn't understand the point of using ruby or java (GWT) to generate javascript (and I didn't understand the popularity of rjs in rails). First, on the contrary to many, I actually like javascript and, second, I founnd that it's just didn't feel like a really good fit...

Now though, I use CoffeeScript but it's very different to the above. It was made with javascript in mind, it's more of a clean syntax for javascript, allowing you to code exactly like you would normally in javascript but in cleaner, neater way..

For the same reason people don't write everything in Javascript. It is not the global optimum language any more than any other language is, and there are tasks where it is easier in programmer terms to write in another language that can have stronger guarantees or a better DSL for some task or whatever than Javascript. As more and more stuff moves to the client an expanding range of client tasks falls under this category.

One reason is to be able to consistently work with the same language both on the server and on the client. In this way one doesn't need to change gears all the time. I do like JS, but I'd rather use Ruby (or language of choice) most of the time.

no one sets out to do a project of meaning or scale and chooses these tools, do they?

We certainly have (Parenscript) and it's vital for two reasons: (1) there are cases where we need to run the same code on either the server or the client; (2) we get the full power of Lisp macros. The latter means our source code is much smaller than JS we would have had to write by hand. Somewhat unexpectedly, there's a key efficiency issue here: making heavy use of abstractions in JS would make our code significantly slower. With Parenscript, we can write concise source code with nice abstractions that compiles to low-level, efficient (but still readable) JS. It's one of those rare times you get to have your cake and eat it too (an adage that really doesn't make sense, yet still always comes up #1 in the search results in my brain!)

I've switched over to CoffeeScript for all projects where I get to choose. It's an all around better language than js if you tend towards the functional side.

Iteration/comprehensions work like they should[1], destructuring simplifies extraction, there's a prototype binding construct in the language, less line noise, and everything is an expression. I also happen to like indent-significant languages and think it's a great DSL language.

I could certainly produce the same code writing in JS, but what would the advantage be? I'm already doing a build step for combo/minification and if not, a --watch compile gives roughly the same workflow as raw JS. I have to search for a snippet of text rather than going to a line number when I'm debugging, but I think the coding gains/cleanliness is worth the slightly increased debugging effort.

[1] With one gripe, `y = x + 1 for x in 0...10` got changed in August to match up with `z = x if x % 2` and friends (it was special cased) so y is now 10 instead of the array 1..10 and you have to wrap the comprehension in parens.

Most projects do just use straight JavaScript which is a big problem. JavaScript does all the wrong things by default. "for in" loops and "==" comparisons are a couple big offenders, that often appear to do the right thing (but fail later in unexpected ways). Any of these compilers worth their salt will limit their output to properly formed loops and comparisons and otherwise cross-browser compatible code, etc, saving you from a great deal of pain.

Are you serious? GWT is used in a lot of large, commercial projects. And of course by Google itself which also isn't exactly small-scale :)

I note that doesn't read 'good JS' or 'fast JS'. You can put me in a tutu but I won't be a prima ballerina.

Define good in this context. I'm inclined to say that if it doesn't have cross-browser bugs and it's fast, then it's good. The output being readable to human programmers probably shouldn't be a goal when JS is being used as a compiler target.

I'd define good as it takes full advantage of the javascript language and produces & can be used to create structures optimised for javascript, not the language it was written in.

This is why I think it's better to reduce the context-switch between server and browser and not eliminate it. There's going to be a context-switch there no matter what you do, so there's no sense in paying such high prices to try to eliminate it.

Agreed in principle, but readability still matters a great deal for debugging. There's vastly more browser tool support for JS (e.g. Firebug) than for languages targeting JS. These tools get harder to take advantage of as one's compiled JS gets less readable.

Sometimes I think the holy grail for what we do would be a Slime-like REPL in the web browser that speaks Parenscript, maps to source code, and had full debugging support. In the meantime, though, things like Firebug are indispensable.

"The output being readable to human programmers probably shouldn't be a goal when JS is being used as a compiler target."

Everyone says that until they have to debug the generated JavaScript in IE.

I'm not sure about all of them but CoffeeScript emits good, portable, fast JS.

Coffeescript I'm familiar with and yes, is very nice indeed. It's some of the others I'd be more concerned about.

If we can enable source pointers for debugging, then "good" matters less -- about as much as how "good" x86 ISA is.

CoffeeScript is largely an alternate syntax to JS with a couple of macros added on. That's more like the prima ballerina changing from her pajamas into a tutu.

Indeed, they don't go as far as some of the other ones, but it's still a language that compiles down to JS. It's nice that it's a strict superset of JS (iirc anyway) but that alone doesn't mean that it's impossible to produce slow or bloated JS.

Of course any language that does a lot more than CS is going to be slower, e.g. Objective-J's object system providing method-missing functionality and a whack of other features not found natively in JS.

For those that think JavaScript makes a good VM format for the web, I've written a couple blog posts recently on this topic:

http://chadaustin.me/2011/01/native-client-is-widely-misunde...

http://chadaustin.me/2011/01/digging-into-javascript-perform...

Basically, we need another 10x to 30x in performance for JavaScript to match native code performance...

Your lines of code measurement would be more compelling if you used sloccount instead of wc -l. Also, are you counting the lines of code in directories with tests in the name for Mozilla? I don't grok that find(3) incantation fully.

Added emscripten which to my untrained eyes seems like the place where a lot of gains can be made. You can gain a lot by removing the middleman but sometimes you can gain a lot by adding one.

Emscripten is the most exciting project IMO - it's basically a more portable NaCl. I wonder if Google will start using it if they're serious about NaCl.

How about a list of languages that compile to PHP? haXe is the only mature one I know about.

http://news.ycombinator.com/item?id=833954

I just so happen to have this list.

http://haxe.org/doc

http://github.com/scriptor/pharen

http://www.mathgladiator.com/projects/kira/

http://www.scriptol.net/

http://sunra.nachtkabarett.com/

http://users.xelent.net/mlewis/tellpdf.php?seid=12457c30afd9...

http://ialexi.com/portfolio/original-works/components/quirk/

And a somewhat related list:

https://github.com/ryantenney/php7 Hacking the PHP compiler and standard libraries in the name of turning it into a not crappy language.

https://github.com/tenderlove/phuby Phuby wraps PHP in a loving embrace. Exposes a PHP runtime in ruby

https://code.google.com/p/japha/ implementation of the Java 1.4.2 library in PHP

https://github.com/lunant/lisphp Lisphp is a Lisp dialect written in PHP

https://code.google.com/p/php-alternative-syntax/ Scala inspired syntax for PHP

https://code.google.com/p/java-php-toolkit/ a cross language compiler than transforms java code to php code deployable on any server supporting PHP >= 5.3

https://github.com/bendemott/pyhp Pyhp is a way to execute PHP Source Code directly within Python Scripts

https://github.com/ramen/phply PHP parser written in Python using PLY

https://github.com/skeltoac/php_app A PHP eval server for Erlang/OTP

Hey, creator of Pharen here. I've been procrastinating on another release for a while but still developing it. If anyone wants to check it out there is a better site over at http://scriptor.github.com/pharen.

tehre is also php.rb a gem for ruby

NS Basic/App Studio compiles Visual Basic style BASIC to JavaScript + HTML5. Also includes an IDE. Targets iOS and Android. (http://www.nsbasic.com/app)

Wow, that's a blast from the past, from the Palm OS days. Interesting that they're still around.

NS Basic was actually around long before Palm OS, starting with the Newton. (!) We think /App Studio is our best yet.

Ah, nice! That's a long history - you've held out better than some of the other tools I remember using for Palm, like CASL, HB++ and AppForge. (Also amusing that Palm got their start on the Newton, with Graffiti.)

Two Haskell compilers (UHC and YHC) have JavaScript backends which convert their core languages to JS. I've added them to the wiki page.

WebSharper lets you compile F# to JS (it's a commercial product though.)

This is a great list. I was just thinking about what might be out there the other day. I'm very interested in Ruby --> JS. However haven't tried them. I followed Charles Nutter's work on JRuby for a while and it seems to me that it's extremely involved to actually compile a fully functioning ruby into another language and/or bytecode.

How about Links at http://groups.inf.ed.ac.uk/links/ and HOP at www.hop.inria.fr in the tierless category. Also, why isn't there a tierless JS since we can already run JS on the client and server side? I asked this question here: http://news.ycombinator.com/item?id=2068395

Mascara (http://www.mascaraengine.com/) compiles a typed version of ECMAScript (based on Harmony and other proposals for ECMAScript extensions) into JavaScript. It is backwardly compatible with JavaScript, so you can gradually upgrade code to take advantage of it.

Thank you for posting this list! I don't think I would have ever heard about http://cluecc.sourceforge.net/ otherwise. It seems like a really big deal, I'm very surprised I haven't heard about it before. Def. checking it out.

Feel free to contribute, it's a wiki!

List of interpreters implemented in JavaScript for various languages would be also nice. I think they can be useful for educational purposes i.e. writing interactive materials on the web.

Wasabi?

http://www.joelonsoftware.com/items/2006/09/01b.html

I just contributed http://www-sop.inria.fr/indes/scheme2js/.

I thought about including the fact that Pugs had a JavaScript backend then decided not to because Pugs never was completed (and likely never will be).

Fantom (http://fantom.org/) also compiles to javascript. However this platform is supported via direct AST transformation not runtime bytecode generation as for JVM or CLR.

Any tools that work in the opposite direction? ( e.g., JS -> C )

You can use a JavaScript engine such as V8 to run JavaScript code anywhere, but I don't know of any native compilers.

Rhino does JS -> Java bytecode internally but I don't think you can grab those classes and execute them outside Rhino.

A full compiler would of course always have the problem of dynamically generated JS, i.e eval().

Red Daly has a JavaScript to Parenscript (Common Lisp) translator: https://github.com/gonzojive/js-to-parenscript

The generated code from that won't run without a JS runtime implementation in CL backing the JS-specific Parenscript forms, which currently doesn't exist to my knowledge (it's not hard to write, just not very useful). This is useful by itself for writing JS analysis and transformation tools and moving JS code to Lisp.

There's CL-JavaScript: http://marijnhaverbeke.nl/cl-javascript/

This is a translator/compiler/"simulator" (http://www.cs.aau.dk/~normark/oo-scheme.html) that provides good integration between the two languages.

I didn't see haXe on the list so added it. Seems its often overlooked when people talk about languages which compile to JS.

Reply on news.ycombinator.com