List of languages that compile to JS

gordonguthrie 12 years 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 12 years 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

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

lucaspiller 12 years 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 12 years 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.

nickik 12 years ago | | |

On a browser you would also want 1000 process maybe. There can be tons of different inputs you need to monitor and then you might do a lot of transformation on them.

Supervision and restart are not only useful if a application is long running, if you implement a game, a user might to spend many hours on a page. They might leave it open in a different tab for a long time and expect it to work when they get back.

I know more about CSP and not Actors but there you use many of the same tricks (I think). And I really don't see why one would constrain the browser side.

See for example this project: http://www.infoq.com/presentations/pedestal-clojure

gordonguthrie 12 years ago | | |

I don't agree.

The mission is to be a dom-scripting language http://luvv.ie/mission.html

I didn't just pluck 9 out of the air, it comes from thinking about how I would structure applications that I have written.

Take for instance our online spreadsheet - very complex GUI - 2,500 divs - but when you ask what are is the concurrency - what are the discrete functional data models that I need to manipulate - the number is low:

    * a menu bar
    * a toolbar
    * a tabs bar
    * a grid
    * the cell input overlay
    * 5 or 6 dialog boxes

The grid is endless scrolling set of spreadsheet cells and behind the scenes it is pre-built panels of 20x20 which are 'next-but-one' assembled on the fly for smooth scrolling.

Even if you break the grid out for max concurrency - you only add another 8 or 9 concurrent data models.

9 - 29 Web Worker processes for a page sounds liveable with.

With regard to restart and supervision I really do mean the Operational Supervision that Erlang/OTP supervision does in terms of handling errors. I don't see how the sophisticated restart and fail-over strategies that you might have in a 50-node server cluster will ever work. The user is the consumer, and they are in front of their device, failing over to another browser is not an option. Page refresh covers most of what you might ever need.

I don't know what CSP is, so I can't really comment. I also don't really have any knowledge or desire to support gaming.

gaoprea 12 years 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-nat...

[2] https://github.com/kripken/emscripten/wiki

kreek 12 years ago |

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

parallelist 12 years ago |

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

rubiquity 12 years 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 12 years 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 12 years 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.

nickik 12 years ago | | |

> programmers used to the server-side implementation, which defeats the purpose of using the same language for both

I would actually disagree. In the Clojure world, we try to embrace the platform, meaning that we do not try to make all source compatible.

The goal is to have the basic comparable and then make all the more algorithmic library work everywhere. I think this has worked out pretty well so far.

Things like core.logic, core.match, core.typed and so on work on both sides with relatively small adjustments.

chc 12 years ago | | |

Clojure is odd in this way. Java was created as a cohesive, self-sufficient platform. Clojure was always envisioned as sort of a passenger — something to be grafted on to an existing platform. From the very early days, it already lived in two different environments simultaneously (the JVM and CLR), so the culture and the practices were already there, and it wasn't too jarring when they added JavaScript.

courtewing 12 years 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).

josteink 12 years ago | |

Indeed. I was coming here expecting the list to be long, and I was still surprised at how much bigger it was than I initially imagined.

saurik 12 years 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 12 years ago | |

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

diminoten 12 years 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.

speg 12 years 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 12 years ago | |

Welcome to heaven, then.

http://bolinfest.com/coffee/features.html

or

https://github.com/Steida/este/

embwbam 12 years 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.

Mikeb85 12 years 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++).

babby 12 years 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.

nickik 12 years 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/

acjohnson55 12 years 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.

jgalt212 12 years ago |

JS + lodash is good enough for me.

joubert 12 years 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) to that page.

joemaller1 12 years ago |

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

Grue3 12 years ago |

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

auvi 12 years ago |

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

steveklabnik 12 years ago | |

asm.js (which is JavaScript) is the assembly language of the web. ;)

_random_ 12 years ago | |

Exactly. It should be hidden away from you and you shouldn't have to deal with it.

mahadazad 12 years ago |

Wow thats a never ending list.

zem 12 years ago |

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

Fasebook 12 years ago |

This shows us how useful JS really is.

rubiquity 12 years 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.

Touche 12 years ago | | |

That's the glass-half-empty look at it. I look at it the opposite: it's rather easy to write a web application in any language you want. Unlike the native platforms (especially on mobile). In fact, the web community puts a lot of effort into making it easy for you to use an altjs language.

soganess 12 years ago | | |

Or, more simply, a good indirect indicator of how desirable a common vm for the web really is.

rubiquity 12 years ago | | |

That would be a dream come true.

lostcolony 12 years 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.

acjohnson55 12 years ago | | |

What's wrong with the DOM? I feel like jQuery abstracts away most of the pain. Do you mean the API itself, or in the abstract sense of laying out web apps like documents?

buckbova 12 years ago | | |

It goes the other way too, see rhino:

https://developer.mozilla.org/en-US/docs/Rhino/Overview

_random_ 12 years ago | |

Dirt is useful for growing plants, but you don't want to touch it ;)