
List of languages that compile to JS - gaoprea
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
======
gordonguthrie
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
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
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
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
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](http://www.infoq.com/presentations/pedestal-clojure)

~~~
gordonguthrie
I don't agree.

The mission is to be a dom-scripting language
[http://luvv.ie/mission.html](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.

~~~
nickik
> The mission is to be a dom-scripting language
> [http://luvv.ie/mission.html](http://luvv.ie/mission.html)

If that is your goal then I dont want to clame that you have not achived it.
This looks quite good for many things, my point is however that I mayself
would not want to restrict myself this way.

In the future we be able to directly go from one browser to another, we might
query or get messages from tons of diffrent servers, the OS might send us
events and so on. More and more, the browser becomes a application deployment
target.

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

The question is not really if I can live with, the question is if I want to.

It just seamst to me that, when light weight concurrency is good on the server
we should also use it in the browser. Seams to me this would help with the
idea of using simular programming models on both ends.

> 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.

I can imagen many things. Lets say a you inplment some game or simulation
where you have threads of executuion doing some calculation and maybe
rendering themselfs on the screen. Now it would be nice to have some sort of
fail-over system that might monitor all these and can potentially restart
them, maybe get some information from the server or internal data store, maybe
it is required to shut down all the other threads and restart them as well.

Maybe you stop getting messages from the server, and you have to restart the
server or go and search for another server. Maybe you have to get a message
from the server, informing you that it is shuting down and internal storage
should be used.

I can image lots of things, and I dont know why I should restrict myself by
design.

> 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.

CSP is what Go implments (or core.async library in clojure).

~~~
gordonguthrie
The concurrency issue is not mine to fix. Javascript provides native
concurrency by Web Worker which (compared to Erlang processes is a very heavy-
weight, no-shared code environment. LuvvieScript is just realising that (given
those prior contraints) an OTP-ish Erlang dom-script language can be created.

The alternative (a light-weight process language) involves building a
scheduler in Javascript - which is a very different beast to a transpiler with
a message-consuming/emitting runtime built with existing JS libraries.

To be brutally honest, the later is beyond my competancies.

~~~
nickik
Fortunately somebody has already made a implementation and you could try to
use it as a base layer for your own system. I don't how easy it is to
interface with Clojures core.async, but I guess its probably possible.

Here somebody has already did a mini-actor implementation:
[https://github.com/halgari/clojure-conj-2013-core.async-
exam...](https://github.com/halgari/clojure-conj-2013-core.async-
examples/blob/master/src/clojure_conj_talk/core.clj#L458)

It might be a interesting exercise to implement Erlang Actors on top of this
and then expose it to a JS interface. This might be a good idea in general and
not just for your OTP-ish langauge.

Also I want to say that I came a across as very negative, I just wanted to say
that LuvvieScript is quite cool and useful. WebWorkers are a much better
primitive for Erlang style stuff because its shard nothing even on the server
(I think). In really the browser should really provide a API for either shard
memory threads or proper Erlang/Go Style threads.

~~~
gordonguthrie
Yeah, Erlang is proper shared nothing. With modern multicore phones I think
low-number concurrency in Web Workers should be enough.

My problem with using Clojure libraries is that I don't really know JS very
well :( I really am all Erlang...

------
gaoprea
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...](https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-
performance-gets-even-narrower-with-float32-optimizations)

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

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

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

~~~
rubiquity
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
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
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
> 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
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.

------
saurik
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
Interesting historical note — AltJS.org was originally taken from a version of
this page, and then forked off from there.

------
diminoten
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
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
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/)

------
Mikeb85
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
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
> 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/)

------
jgalt212
JS + lodash is good enough for me.

------
joubert
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.

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

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

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

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

------
mahadazad
Wow thats a never ending list.

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

------
Fasebook
This shows us how useful JS really is.

~~~
rubiquity
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.

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

~~~
rubiquity
That would be a dream come true.

~~~
lostcolony
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
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?

