14 ms·

Javascript Alternatives

39 points by davert 14y ago

bazzargh 14y ago
Would be as well pointing to http://altjs.org/ 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/ 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 14y ago
  Excellent point! I added a comment about that so people will know where to look for extra info. :)
CJefferson 14y ago
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?
- bebraw 14y ago
  Hi, You might want to check out Esprima (http://esprima.org/ http://esprima.org/). You will find a couple of alternatives there. See http://code.google.com/p/traceur-compiler/ http://code.google.com/p/traceur-compiler/ as well.
- camus 14y ago
  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 14y ago
    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).
- quarterto 14y ago
  Check out https://github.com/matthewrobb/six https://github.com/matthewrobb/six and https://github.com/jdiamond/harmonizr https://github.com/jdiamond/harmonizr.
- olavk 14y ago
  Mascara (http://www.mascaraengine.com http://www.mascaraengine.com) supports a bunch of the proposed ECMAScript extensions, including classes, destructuring assignments, generators, getters/setters and array comprehensions.
daigoba66 14y ago
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).
- leephillips 14y ago
  No, Clojure, for example, has nothing to do with JavaScript. There just happens to be a compiler that translates a large subset (ClojureScript) to JavaScript, so it can use the web browser as a platform.
- w0utert 14y ago
  >> [..] 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.
- olavk 14y ago
  There are no realistic alternative to JavaScript which is not based on JavaScript in the end. Some of them provide very powerful abstractions on top of JavaScript though. There is nothing weird about abstractions. All modern languages are based on multiple levels of language abstractions.
jashkenas 14y ago
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-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
flyinRyan 14y ago
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 14y ago
  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/ http://www.dartlang.org/articles/why-not-bytecode/
  - flyinRyan 14y ago
    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 14y ago
      You might be interest in Portable NaCL (aka PNaCL). http://www.chromium.org/nativeclient/pnacl http://www.chromium.org/nativeclient/pnacl
- phpnode 14y ago
  Honest question - what can you do with bytecode that you can't do with javascript? Modern javascript is fast and ubiquitous and is clearly not going away anytime soon. Isn't the human readable nature of javascript more suitable for debugging anyway?
  - olavk 14y ago
    Some features typical of VM languages, like "goto" makes it more appropriate as a compilation target, because lots of higher-level control structures kan be compiled to gotos. Of course goto could also be added to the JavaScript language as is, but then we have a conflict since goto is nice in a low-level language, but discouraged in higher level languages. This conflict of interest in language design does not exist when the user language is seperate from the VM-language. I agree with your point though.
olavk 14y ago
The list forgot Mascara (http://www.mascaraengine.com/ 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).
paduc 14y ago
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 14y ago
  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.
kyllo 14y ago
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.
TheHippo 14y ago
The list is missing Haxe. (http://haxe.org http://haxe.org)
- macspoofing 14y ago
  Poor Haxe. A pretty good project that just can't seem to generate widespread excitement. Probably because syntax is too close to AS3.
  - jdonaldson 14y ago
    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 14y ago
      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 14y ago
Surprisingly left out one of the best and most used to-javascript compilers? https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/
olalonde 14y ago
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 https://github.com/olalonde/better-require
usablebytes 14y ago
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?
- jiggy2011 14y ago
  You could apply that to C and assembler. I remember back in the late 80s to early 90s is was not uncommon for developers to write code in raw asm presumably because C didn't give them the "power" they needed. I think that perhaps JS has not yet reached the point that asm has.
- jeremiep 14y ago
  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 14y ago
    Ok, I see your point and @jiggy2011's, too. But I still love JavaScript as it is :)
tikhonj 14y ago
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/ 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.
- glomph 14y ago
  Also http://haxe.org/ http://haxe.org/ which was originally inspired by OCaml (iirc) and complies to JavaScript, Flash, NekoVM, PHP, C++ and C#. It's pretty cool.
- sethladd 14y ago
  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 ;
- sethladd 14y ago
  I also wrote this response a while ago, which has additional details: http://news.ycombinator.com/item?id=4530903 http://news.ycombinator.com/item?id=4530903
killitwithfire 14y ago
What's wrong with regular javascript? Teses things seem neat - but must be impossible to debug. Why can't people build alternatives to javascript that run IN the browser themselves?
macspoofing 14y ago
I really like the idea of TypeScript. Very close to Javascript, future-proof (ES6 classes) and sane compiler support.
- olavk 14y ago
  Can you elaborate on what you mean with sane compiler support in this context?

39 points by davert 14y ago

Would be as well pointing to http://altjs.org/ 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/ 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 14y ago
Excellent point! I added a comment about that so people will know where to look for extra info. :)

CJefferson 14y ago

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?

bebraw 14y ago
Hi, You might want to check out Esprima (http://esprima.org/ http://esprima.org/). You will find a couple of alternatives there. See http://code.google.com/p/traceur-compiler/ http://code.google.com/p/traceur-compiler/ as well.
camus 14y ago
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 14y ago
  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).
quarterto 14y ago
Check out https://github.com/matthewrobb/six https://github.com/matthewrobb/six and https://github.com/jdiamond/harmonizr https://github.com/jdiamond/harmonizr.
olavk 14y ago
Mascara (http://www.mascaraengine.com http://www.mascaraengine.com) supports a bunch of the proposed ECMAScript extensions, including classes, destructuring assignments, generators, getters/setters and array comprehensions.

daigoba66 14y ago

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

leephillips 14y ago
No, Clojure, for example, has nothing to do with JavaScript. There just happens to be a compiler that translates a large subset (ClojureScript) to JavaScript, so it can use the web browser as a platform.
w0utert 14y ago
>> [..] 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.
olavk 14y ago
There are no realistic alternative to JavaScript which is not based on JavaScript in the end. Some of them provide very powerful abstractions on top of JavaScript though. There is nothing weird about abstractions. All modern languages are based on multiple levels of language abstractions.

jashkenas 14y ago

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-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

flyinRyan 14y ago

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 14y ago
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/ http://www.dartlang.org/articles/why-not-bytecode/
- flyinRyan 14y ago
  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 14y ago
    You might be interest in Portable NaCL (aka PNaCL). http://www.chromium.org/nativeclient/pnacl http://www.chromium.org/nativeclient/pnacl
phpnode 14y ago
Honest question - what can you do with bytecode that you can't do with javascript? Modern javascript is fast and ubiquitous and is clearly not going away anytime soon. Isn't the human readable nature of javascript more suitable for debugging anyway?
- olavk 14y ago
  Some features typical of VM languages, like "goto" makes it more appropriate as a compilation target, because lots of higher-level control structures kan be compiled to gotos. Of course goto could also be added to the JavaScript language as is, but then we have a conflict since goto is nice in a low-level language, but discouraged in higher level languages. This conflict of interest in language design does not exist when the user language is seperate from the VM-language. I agree with your point though.

olavk 14y ago

The list forgot Mascara (http://www.mascaraengine.com/ 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).

paduc 14y ago

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 14y ago
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.

kyllo 14y ago

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.

TheHippo 14y ago

The list is missing Haxe. (http://haxe.org http://haxe.org)

macspoofing 14y ago
Poor Haxe. A pretty good project that just can't seem to generate widespread excitement. Probably because syntax is too close to AS3.
- jdonaldson 14y ago
  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 14y ago
    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 14y ago

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

olalonde 14y ago

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 https://github.com/olalonde/better-require

usablebytes 14y ago

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?

jiggy2011 14y ago
You could apply that to C and assembler. I remember back in the late 80s to early 90s is was not uncommon for developers to write code in raw asm presumably because C didn't give them the "power" they needed. I think that perhaps JS has not yet reached the point that asm has.
jeremiep 14y ago
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 14y ago
  Ok, I see your point and @jiggy2011's, too. But I still love JavaScript as it is :)

tikhonj 14y ago

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

glomph 14y ago
Also http://haxe.org/ http://haxe.org/ which was originally inspired by OCaml (iirc) and complies to JavaScript, Flash, NekoVM, PHP, C++ and C#. It's pretty cool.
sethladd 14y ago
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 ;
sethladd 14y ago
I also wrote this response a while ago, which has additional details: http://news.ycombinator.com/item?id=4530903 http://news.ycombinator.com/item?id=4530903

killitwithfire 14y ago

What's wrong with regular javascript? Teses things seem neat - but must be impossible to debug. Why can't people build alternatives to javascript that run IN the browser themselves?

macspoofing 14y ago

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

olavk 14y ago
Can you elaborate on what you mean with sane compiler support in this context?