8 ms·

List of languages that compile to JS

95 points by gaoprea 13y ago

speg 13y ago
I'm torn between CoffeeScript and TypeScript. If there was a language that had the syntax sugar of CoffeeScript plus static typing, I would be in heaven.
- jashkenas 13y ago
  Welcome to heaven, then. http://bolinfest.com/coffee/features.html http://bolinfest.com/coffee/features.html or https://github.com/Steida/este/ https://github.com/Steida/este/
- embwbam 13y ago
  Typescript was worth the sacrifice for me and those I work with. The benefits easily outweigh those of coffee script. It is painful though at first.
kreek 13y ago
I was going to make snarky comment about writing JavaScript in JavaScript until I saw the language extensions section, very useful!
joemaller1 13y ago
And I expect most of these can be compiled via a Grunt task. JavaScript is the Borg.
saurik 13y ago
This seems to be a "gave up on website, replaced with GitHub" version of altjs.org (which now rediects here). (This website used to have Cycript listed, but now doesn't.)
- jashkenas 13y ago
  Interesting historical note — AltJS.org was originally taken from a version of this page, and then forked off from there.
zem 13y ago
if you're interested in the topic, altjs.reddit.com could use some love
gordonguthrie 13y ago
Boy am I glad I added LuvvieScript (Erlang dialect) to it last week. Its sits a bit lonely, the last transpile-to-javascript language to come in. Robert Virding of Lisp-Flavoured-Erlang pointed out that once I get it working all the other compile-to-Erlang languages (Elixir, LFE, Joxa) will also run in the browser (so no pressure then).
- gordonguthrie 13y ago
  If you fancy developing your own transpile-to-js language I have written up the actual process in some detail: http://luvv.ie/toolchain.html http://luvv.ie/toolchain.html Erlang (via Erlang Core) is actually quite a sweet example. Erlang (which is small) is transformed into Erlang Core (a language targetted at machines not humans) which has a very small set of primitives (21 in all). That Language is turned into a compact AST which is then transpiled to a Javascript AST and transformed back up to Javascript using standard JS syntax tools. I have also written up the thinking about how to make an OTP-ish Erlang dialect in the browser work as part of Erlang/OTP's 'span of control' in the server-side cluster: http://luvv.ie/mission.html http://luvv.ie/mission.html
  - lucaspiller 13y ago
    Wow, I thought at first this was just making an Erlang-style syntax compile to JS, but this is much more than that. Very nice! Does it run on BeamJS? :D
    - gordonguthrie 13y ago
      No. The client and the server are such different environments. In the server you want 10s of 1,000s of processes, with long lifes (years, months) and hot code loading and supervision/restart. None of this is needed/available in the browser. So the key goal is low-impedance - the developer has a mental model where this is say a server-side process and the business rule is 'send the user a message' so they write code like: call_user("gordon@vixo.com", modal, {"Did you brush your teeth?", {"yes", "no"}}) and the 'modal' process in my browser gets some message like: {msg, {"Did you brush your teeth?", {"yes", "no"}) It pops a yes/no dialog box and send "yes" back to the calling process on the server.
parallelist 13y ago
Can’t believe how long this list is. Would be great to have some kind of maturity rating system for each item.
- courtewing 13y ago
  While by no means a definitive system, the order in which they're listed within each section tends to reflect their maturity to a degree (at least amongst the top few in each section).
- rubiquity 13y ago
  From my experience, CoffeeScript seems to be running away from the pack. ClojureScript, Dart and TypeScript all are probably leaders of the second tier, which is far and away more popular than the rest.
  - chc 13y ago
    CoffeeScript was never part of the pack. It's older than most of these and introduced most people to the idea of languages that compile to JavaScript.
    - nostrademons 13y ago
      CoffeeScript showed up in 2009. GWT has been around since 2006 and got widespread publicity when it launched. A number of the other options also came out well before CoffeeScript - Python's Pyjamas came out in 2007. What CoffeeScript did introduce people to was the idea of a language that compiled to only Javascript. And as such, it didn't have a pre-existing language community to point out the shortcomings of the JS implementation. The problem with most compile-to-JS languages is that you never get the semantics exactly right; things like float semantics, string encodings, prototype chains etc. usually make the JS version just different enough to hold surprises for programmers used to the server-side implementation, which defeats the purpose of using the same language for both (Rhino had the same problem, which is why it took V8 before Node could really catch on). CoffeeScripters have no such preconceptions, though - it's a completely new language, so it's adopted on its own merits as a browser-side language by those who like what it provides.
Fasebook 13y ago
This shows us how useful JS really is.
- rubiquity 13y ago
  More like: "This shows us how desirable it is to try and circumvent writing JavaScript, despite how important the Web is." I'm not saying JavaScript is good or bad. Just saying that there is certainly a strong desire to not write it, as evidenced by this long list of transpile languages.
  - buckbova 13y ago
    It goes the other way too, see rhino: https://developer.mozilla.org/en-US/docs/Rhino/Overview https://developer.mozilla.org/en-US/docs/Rhino/Overview
    - deleted 13y ago
      [deleted]
  - soganess 13y ago
    Or, more simply, a good indirect indicator of how desirable a common vm for the web really is.
    - rubiquity 13y ago
      That would be a dream come true.
      - lostcolony 13y ago
        Provided it ran the same across browsers. My main gripe isn't Javascript (though I agree, argh), it's the DOM. So yeah, I could choose to write X instead of Javascript, but I still have the most painful of the pain points to deal with.
        13y ago
gaoprea 13y ago
I expect an increasingly larger C/C++ codebase to be ported with emscripten and asm.js with decent enough performance (especially dev tools). Currently C++ code compiled with emscripten runs in Firefox only 1.5x slower than natively compiled code [1]. Notable ports can be found at emscripten wiki page [2]. [1] https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-nat... [2] https://github.com/kripken/emscripten/wiki https://github.com/kripken/emscripten/wiki
TempleOSV2 13y ago
I wonder if Holy C will become popular. Maybe, only in God's temple can Holy C be used. God says... epic_fail stuff hard_working Angel I_donno happy happy_happy_joy_joy freak cracks_me_up fool look_buddy I_didn't_do_it prosperity scorning try_again do_not_disturb You_can_count_on_that commanded once_upon_a_time Moses Zap I'm_done look_out BRB relax ---- Dance, nigger angel, entertain me. I have expensive tastes -- only the best angels get to dance for me.
auvi 13y ago
I want to say that JavaScript is the "Assembly Language" of the web.
- steveklabnik 13y ago
  asm.js (which is JavaScript) is the assembly language of the web. ;)
- _random_ 13y ago
  Exactly. It should be hidden away from you and you shouldn't have to deal with it.
babby 13y ago
I've had this discussion in other threads; but, how wise it is to use these instead of vanilla JS in a project you want contributed to? I personally find CoffeeScript very useful, and believe it's sufficiently widespread and mature as to be viable. All of these others though, I can only see it as increasing the learning curve on a project. I want to use IcedCoffeeScript (Oh, am I tired of Promises) and some of the JS extensions but I can't justify it. It's like a cake that I know I can't eat.
- deleted 13y ago
  [deleted]
- nickik 13y ago
  > instead of vanilla JS in a project you want contributed to Not sure what this means? If there is a existing project, it would probably be better to do JS. If you start a new project, or you want to change the language then you move forward with the new language and slowly replace or just keep using the old JS. > (Oh, am I tired of Promises) Insted of just adding Await and Defer, when you switch to ClojureScript, you will get full CSP semantics, full first class channels, essentially what Go offers on the server. Check out this blog, it mostly talks about the difference between different ways of front end programming, callbacks, CSP and so on: http://swannodette.github.io/ http://swannodette.github.io/
- acjohnson55 13y ago
  The one limitation I see with using await-defer or generators for async code, instead of promises, is that you lose the ability to specify multiple continuations to your async call. With a promise, you can always continue your synchronous work after setting your `then` handler.
deleted 13y ago
[deleted]
jgalt212 13y ago
JS + lodash is good enough for me.
mahadazad 13y ago
Wow thats a never ending list.
diminoten 13y ago
How is async.js a language extension? If it's a "language extension", then isn't it arguable that every library is a "language extension"? At the very least I'm unsatisfied with the rationale provided in the page. Other items generally explain what makes them worthy of this list, but async.js is just, "Async utilities for node and the browser" which is, while immensely useful, doesn't change JavaScript in a way that is shared by other items on the list.
Mikeb85 13y ago
I think the reason so many languages compile to JS, is that you essentially get to play with and learn a new language, and it's guilt free. Usually you need to choose between technologies - JVM or .NET, Python or Ruby, HTML5/Canvas or Flash, etc... With compile to JS languages, you're never forced to make that choice, if you ever get bored of a language you just compile it into JS and continue with your life. Right now I'm having a lot of fun playing with Haxe and OpenFL/Lime (formerly NME). Being able to create an app with the Flash-like API and compile it, without modifications for HTML5/Flash/Windows/Linux/Mac/Android/iOS/Tizen natively (!!) feels like some sort of unholy hack. Not to mention it's other abilities (compile to everything from JS to Java, C# and C++).
Grue3 13y ago
A rare instance where compiled code is actually slower than before "compilation".
joubert 13y ago
Nice. I am currently working on providing primitives in JavaScript for writing async code without callbacks or chained functions. Added a link (http://jspipe.org http://jspipe.org) to that page.

95 points by gaoprea 13y ago

speg 13y ago

I'm torn between CoffeeScript and TypeScript. If there was a language that had the syntax sugar of CoffeeScript plus static typing, I would be in heaven.

jashkenas 13y ago
Welcome to heaven, then. http://bolinfest.com/coffee/features.html http://bolinfest.com/coffee/features.html or https://github.com/Steida/este/ https://github.com/Steida/este/
embwbam 13y ago
Typescript was worth the sacrifice for me and those I work with. The benefits easily outweigh those of coffee script. It is painful though at first.

kreek 13y ago

I was going to make snarky comment about writing JavaScript in JavaScript until I saw the language extensions section, very useful!

joemaller1 13y ago

And I expect most of these can be compiled via a Grunt task. JavaScript is the Borg.

saurik 13y ago

This seems to be a "gave up on website, replaced with GitHub" version of altjs.org (which now rediects here). (This website used to have Cycript listed, but now doesn't.)

jashkenas 13y ago
Interesting historical note — AltJS.org was originally taken from a version of this page, and then forked off from there.

zem 13y ago

if you're interested in the topic, altjs.reddit.com could use some love

gordonguthrie 13y ago

Boy am I glad I added LuvvieScript (Erlang dialect) to it last week. Its sits a bit lonely, the last transpile-to-javascript language to come in. Robert Virding of Lisp-Flavoured-Erlang pointed out that once I get it working all the other compile-to-Erlang languages (Elixir, LFE, Joxa) will also run in the browser (so no pressure then).

gordonguthrie 13y ago
If you fancy developing your own transpile-to-js language I have written up the actual process in some detail: http://luvv.ie/toolchain.html http://luvv.ie/toolchain.html Erlang (via Erlang Core) is actually quite a sweet example. Erlang (which is small) is transformed into Erlang Core (a language targetted at machines not humans) which has a very small set of primitives (21 in all). That Language is turned into a compact AST which is then transpiled to a Javascript AST and transformed back up to Javascript using standard JS syntax tools. I have also written up the thinking about how to make an OTP-ish Erlang dialect in the browser work as part of Erlang/OTP's 'span of control' in the server-side cluster: http://luvv.ie/mission.html http://luvv.ie/mission.html
- lucaspiller 13y ago
  Wow, I thought at first this was just making an Erlang-style syntax compile to JS, but this is much more than that. Very nice! Does it run on BeamJS? :D
  - gordonguthrie 13y ago
    No. The client and the server are such different environments. In the server you want 10s of 1,000s of processes, with long lifes (years, months) and hot code loading and supervision/restart. None of this is needed/available in the browser. So the key goal is low-impedance - the developer has a mental model where this is say a server-side process and the business rule is 'send the user a message' so they write code like: call_user("gordon@vixo.com", modal, {"Did you brush your teeth?", {"yes", "no"}}) and the 'modal' process in my browser gets some message like: {msg, {"Did you brush your teeth?", {"yes", "no"}) It pops a yes/no dialog box and send "yes" back to the calling process on the server.

parallelist 13y ago

Can’t believe how long this list is. Would be great to have some kind of maturity rating system for each item.

courtewing 13y ago
While by no means a definitive system, the order in which they're listed within each section tends to reflect their maturity to a degree (at least amongst the top few in each section).
rubiquity 13y ago
From my experience, CoffeeScript seems to be running away from the pack. ClojureScript, Dart and TypeScript all are probably leaders of the second tier, which is far and away more popular than the rest.
- chc 13y ago
  CoffeeScript was never part of the pack. It's older than most of these and introduced most people to the idea of languages that compile to JavaScript.
  - nostrademons 13y ago
    CoffeeScript showed up in 2009. GWT has been around since 2006 and got widespread publicity when it launched. A number of the other options also came out well before CoffeeScript - Python's Pyjamas came out in 2007. What CoffeeScript did introduce people to was the idea of a language that compiled to only Javascript. And as such, it didn't have a pre-existing language community to point out the shortcomings of the JS implementation. The problem with most compile-to-JS languages is that you never get the semantics exactly right; things like float semantics, string encodings, prototype chains etc. usually make the JS version just different enough to hold surprises for programmers used to the server-side implementation, which defeats the purpose of using the same language for both (Rhino had the same problem, which is why it took V8 before Node could really catch on). CoffeeScripters have no such preconceptions, though - it's a completely new language, so it's adopted on its own merits as a browser-side language by those who like what it provides.

Fasebook 13y ago

This shows us how useful JS really is.

rubiquity 13y ago
More like: "This shows us how desirable it is to try and circumvent writing JavaScript, despite how important the Web is." I'm not saying JavaScript is good or bad. Just saying that there is certainly a strong desire to not write it, as evidenced by this long list of transpile languages.
- buckbova 13y ago
  It goes the other way too, see rhino: https://developer.mozilla.org/en-US/docs/Rhino/Overview https://developer.mozilla.org/en-US/docs/Rhino/Overview
  - deleted 13y ago
    [deleted]
- soganess 13y ago
  Or, more simply, a good indirect indicator of how desirable a common vm for the web really is.
  - rubiquity 13y ago
    That would be a dream come true.
    - lostcolony 13y ago
      Provided it ran the same across browsers. My main gripe isn't Javascript (though I agree, argh), it's the DOM. So yeah, I could choose to write X instead of Javascript, but I still have the most painful of the pain points to deal with.
      - 13y ago

gaoprea 13y ago

I expect an increasingly larger C/C++ codebase to be ported with emscripten and asm.js with decent enough performance (especially dev tools). Currently C++ code compiled with emscripten runs in Firefox only 1.5x slower than natively compiled code [1]. Notable ports can be found at emscripten wiki page [2]. [1] https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-nat... [2] https://github.com/kripken/emscripten/wiki https://github.com/kripken/emscripten/wiki

TempleOSV2 13y ago

I wonder if Holy C will become popular. Maybe, only in God's temple can Holy C be used. God says... epic_fail stuff hard_working Angel I_donno happy happy_happy_joy_joy freak cracks_me_up fool look_buddy I_didn't_do_it prosperity scorning try_again do_not_disturb You_can_count_on_that commanded once_upon_a_time Moses Zap I'm_done look_out BRB relax ---- Dance, nigger angel, entertain me. I have expensive tastes -- only the best angels get to dance for me.

auvi 13y ago

I want to say that JavaScript is the "Assembly Language" of the web.

steveklabnik 13y ago
asm.js (which is JavaScript) is the assembly language of the web. ;)
_random_ 13y ago
Exactly. It should be hidden away from you and you shouldn't have to deal with it.

babby 13y ago

I've had this discussion in other threads; but, how wise it is to use these instead of vanilla JS in a project you want contributed to? I personally find CoffeeScript very useful, and believe it's sufficiently widespread and mature as to be viable. All of these others though, I can only see it as increasing the learning curve on a project. I want to use IcedCoffeeScript (Oh, am I tired of Promises) and some of the JS extensions but I can't justify it. It's like a cake that I know I can't eat.

deleted 13y ago
[deleted]
nickik 13y ago
> instead of vanilla JS in a project you want contributed to Not sure what this means? If there is a existing project, it would probably be better to do JS. If you start a new project, or you want to change the language then you move forward with the new language and slowly replace or just keep using the old JS. > (Oh, am I tired of Promises) Insted of just adding Await and Defer, when you switch to ClojureScript, you will get full CSP semantics, full first class channels, essentially what Go offers on the server. Check out this blog, it mostly talks about the difference between different ways of front end programming, callbacks, CSP and so on: http://swannodette.github.io/ http://swannodette.github.io/
acjohnson55 13y ago
The one limitation I see with using await-defer or generators for async code, instead of promises, is that you lose the ability to specify multiple continuations to your async call. With a promise, you can always continue your synchronous work after setting your `then` handler.

deleted 13y ago

[deleted]

jgalt212 13y ago

JS + lodash is good enough for me.

mahadazad 13y ago

Wow thats a never ending list.

diminoten 13y ago

How is async.js a language extension? If it's a "language extension", then isn't it arguable that every library is a "language extension"? At the very least I'm unsatisfied with the rationale provided in the page. Other items generally explain what makes them worthy of this list, but async.js is just, "Async utilities for node and the browser" which is, while immensely useful, doesn't change JavaScript in a way that is shared by other items on the list.

Mikeb85 13y ago

I think the reason so many languages compile to JS, is that you essentially get to play with and learn a new language, and it's guilt free. Usually you need to choose between technologies - JVM or .NET, Python or Ruby, HTML5/Canvas or Flash, etc... With compile to JS languages, you're never forced to make that choice, if you ever get bored of a language you just compile it into JS and continue with your life. Right now I'm having a lot of fun playing with Haxe and OpenFL/Lime (formerly NME). Being able to create an app with the Flash-like API and compile it, without modifications for HTML5/Flash/Windows/Linux/Mac/Android/iOS/Tizen natively (!!) feels like some sort of unholy hack. Not to mention it's other abilities (compile to everything from JS to Java, C# and C++).

Grue3 13y ago

A rare instance where compiled code is actually slower than before "compilation".

joubert 13y ago

Nice. I am currently working on providing primitives in JavaScript for writing async code without callbacks or chained functions. Added a link (http://jspipe.org http://jspipe.org) to that page.