

Javascript Alternatives - davert
http://jster.net/blog/js-alternatives-coffeescript-dart-typescript

======
jashkenas
For the _big_ list of Compile-to-JS langs, folks keep a pretty good wiki page
here: [https://github.com/jashkenas/coffee-script/wiki/List-of-
lang...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages-
that-compile-to-JS)

------
bazzargh
Would be as well pointing to <http://altjs.org/> \- the linked article is a
much shorter list, and doesn't really offer much insight; the content for each
language is a copy-and-paste of the opening paragraph from each of the 9
language's websites. e.g. if you're going to mention Roy, then why not compare
and contrast it with <http://fay-lang.org/>?

altjs isn't much better on the content front, but lists dozens more of these
languages, and points you to an irc channel where you can talk about them.

~~~
bebraw
Excellent point! I added a comment about that so people will know where to
look for extra info. :)

------
tikhonj
I personally recommend looking at OCaml, which has a JavaScript compiler
called js_of_ocaml[1]. Using OCaml is a great way to give your projects
structure without sacrificing expressiveness--I think it's a much better bet
for large projects than something like Dart which reeks too much of Java. The
JavaScript compiler is also very good. It compiles down from OCaml bytecode.
I've also found the mechanisms for interacting with existing JavaScript
libraries relatively easy to use and understand, although admittedly most of
what I did with it did not do much DOM manipulation.

[1]: <http://ocsigen.org/js_of_ocaml/>

There are also some cool frameworks for using OCaml on the server (although I
haven't used them myself). So with OCaml you can use the same language for the
frontend and the backend, which is always nice.

~~~
sethladd
OK, I'll bite. In what ways does Dart reek of Java?

* Dart has top-level variables and functions, Java does not. * Dart has optional static types, Java does not. * Dart programs start at main(), Java does not (see static initializers) * Dart has factory constructors, Java does not. * Dart has true lexical scope and nested functions, Java does not. * Dart doesn't need to be compiled into bytecode, Java does. * Dart's classes have implicit interfaces, Java does not. * Dart has auto generated getters and setters for fields, Java does not. * Dart has one-line function syntax, Java does not. * Everything in Dart is an object, Java has primitives. * Dart has only library privates, Java has public/protected/package/private. * Dart starts quicker than Java.

In all fairness, both Dart and Java and JavaScript use { } and ;

------
olavk
The list forgot Mascara (<http://www.mascaraengine.com/>) which adds features
like classes, type inference, array comprehensions and so on, but is backwards
compatible with JavaScript. (Disclosure: I made it. Hope it's not considered
spam to post here anyway?)

It is probably closest to TypeScript on the list, but is IMHO more mature and
have more features (like generics).

------
TheHippo
The list is missing Haxe. (<http://haxe.org>)

~~~
macspoofing
Poor Haxe. A pretty good project that just can't seem to generate widespread
excitement. Probably because syntax is too close to AS3.

~~~
jdonaldson
It's weird this is would even be seen as a negative. AS3's ecmascript-based
language isn't even bad. It just had some brain dead runtime decisions
(untyped arrays), and a horrible editor. Most people I know would gladly work
with the AS3 _language_ over javascript. Haxe _looks_ closely related to AS3,
but trust me, it is far easier to work with.

Also just wanted to mention that Haxe3 is just around the corner...

~~~
macspoofing
I know. AS3, save for some 'interesting' design decision, isn't that bad. The
problem is that the trend is for more dynamic, loosely-typed languages. If
Haxe went with a Ruby-like syntax originally, and placed less emphasis on
Flash compilation - it probably would have become more popular.

Again, Haxe doesn't have as much traction as others, not because it's bad, but
because it isn't fashionable. At least that's the only reason I can come up
with why it hasn't resonated.

------
RyanZAG
Surprisingly left out one of the best and most used to-javascript compilers?
<https://developers.google.com/web-toolkit/>

------
olalonde
Shameless plug: if you want to start using one of those languages right away
on Node.js, I've written a Node.js module that lets you require() files
written in most of those languages: <https://github.com/olalonde/better-
require>

------
CJefferson
Rather than a Javascript 'Alternative', out of interest what is the best way
of using Current / Future Javascript?

Looking at wikipedia (and I may be getting misinformed here) the most recent
version of 'Javascript Extensions' is 1.8.1, and EMCA is on edition 5. However
support for both of these seems patchy.

I often see mentions of all kinds of polyfills, but is there a nice library
and/or compiler, which gives me access to the "Javascript of the future", on
browsers which do not yet support it? Is this even a sensible thing to ask
for?

~~~
camus
some features cannot be "polyfilled".

You cant magically make proxies , weakmaps ,let , or generators , or even
modules(the python way) work just by adding a library to Javascript. You cant
change inner workings of the language with functions.

If you could there would be no point creating a future version of the
language.

All transpilers that compile down to javascript are basically syntaxic sugar
generators , but do not add semantic like ES6 does.

~~~
masklinn
Technically you can absolutely implement most of them (the most problematic
are probably weakmaps, as weakref require GC cooperation, and "true
generators"), since you can implement all of them on e.g. C.

However implementing them means a more complex compiler, more low-level
resulting JS, and potentially a runtime within the JS runtime (essentially
coding a VM in javascript, within which your language runs).

------
daigoba66
Shouldn't a JavaScript "alternative" not involve JavaScript? These are all
just JavaScript abstractions (which in my personal opinion is just weird and
probably unnecessary most of the time).

~~~
w0utert
>> _[..] which in my personal opinion is just weird and probably unnecessary
most of the time_.

If an alternative language that compiles down to JavaScript is much cleaner
and safer, and isn't compromised by the myriad of idiosyncrasies that bug
JavaScript, then I think it definitely has its merits.

I really, honestly and adamantly despise JavaScript, probably because I used
to write lots of JavaScript years ago in the IE4 age. Back then, nobody would
even think about using JavaScript for anything but simple scripts embedded on
webpages, that was what the language was designed for, and about the only
thing it was capable of. It was slow, badly documented, lacking in features
and it promoted terrible program design. A lot has changed in the mean time
and while I haven't been writing any JavaScript since somewhere around the
year 2000, I recognize that the language is now pretty capable and fast. But
it still lugs around a hideous legacy that -as far as I'm concerned- can't die
soon enough to be replaced by something better, running on the same VM.

Any alternative that hides the ugly wart that modern JavaScript grew out of,
while we're waiting for a real and native replacement, is more than welcome.

------
paduc
These were cool and useful when javascript was hard to learn and each browser
had a different version of it.

Now it's one of the most widespread programming language in the world and
there are thousands of great tutorials to learn it.

Take the time to do vanilla JS, it's not that hard and it's a very decent
language to use daily.

~~~
exit
i'm far more productive with compile time type checking (especially optional
typing), so i use typescript for a lot of my larger javascript projects.

------
flyinRyan
But all of these just compile to Javascript in the end, right? I long for the
day where we just have a "Browser VM" that we can all compile to instead of
compiling to a high level language.

~~~
jashkenas
Here's an article by the Dart team that describes why the JavaScript VM (or
the Dart VM) may already be the "Browser VM" you're looking for:
<http://www.dartlang.org/articles/why-not-bytecode/>

~~~
flyinRyan
All of their justifications seem to have a language specific VM like the JVM
in mind. If you made a strategy of a "platformless x86" approach you might be
able to overcome a lot of this stuff.

~~~
sethladd
You might be interest in Portable NaCL (aka PNaCL).
<http://www.chromium.org/nativeclient/pnacl>

------
kyllo
I've tried Coffeescript a little and didn't really care for it, but I haven't
experienced any of the others. From reading the list, Opal is by far the most
interesting of these because rather than forcing me to learn yet another new
language syntax, it compiles a language I already know into Javascript.

The XHR implementation looks pretty no-brainer as well:
HTTP.get("/users/1.json") do |response| puts response.body end

This might be worth a go, but I suspect I will probably just keep using JS
with jQuery directly. But at least it's cool to know that I can now do a full-
stack Rails app including client-side scripting entirely in Ruby if I want to.

------
macspoofing
I really like the idea of TypeScript. Very close to Javascript, future-proof
(ES6 classes) and sane compiler support.

~~~
olavk
Can you elaborate on what you mean with sane compiler support in this context?

------
usablebytes
I fail to see a point! JavaScript alternatives that each of it ultimately
boils down to JavaScript. Why not just write JavaScript which looks like
JavaScript and behaves like JavaScript?

May be we shouldn't call them 'alternatives' but just 'wrappers' - JavaScript
Wrappers. But again, that's not the point. Why?

~~~
jeremiep
I don't know about the alternatives, but CoffeeScript often expands to twice
the lines of code to JavaScript, without comments and longer lines.

Not having to track braces, optional parenthesis, not having to type
'function' and others quickly add up. The result is very elegant and clean
code. Having less code also means its quicker to identify bugs.

~~~
usablebytes
Ok, I see your point and @jiggy2011's, too. But I still love JavaScript as it
is :)

