Javascript Alternatives | Hacker News Reader

Javascript Alternatives

jster.net

39 pointsdavert44 comments

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

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.

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

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.

Also http://haxe.org/ which was originally inspired by OCaml (iirc) and complies to JavaScript, Flash, NekoVM, PHP, C++ and C#.

It's pretty cool.

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 ;

I also wrote this response a while ago, which has additional details: http://news.ycombinator.com/item?id=4530903

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

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

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

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

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.

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

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

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?

Hi,

You might want to check out Esprima (http://esprima.org/). You will find a couple of alternatives there. See http://code.google.com/p/traceur-compiler/ as well.

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.

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

Check out https://github.com/matthewrobb/six and https://github.com/jdiamond/harmonizr.

Mascara (http://www.mascaraengine.com) supports a bunch of the proposed ECMAScript extensions, including classes, destructuring assignments, generators, getters/setters and array comprehensions.

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

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.

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

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.

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.

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.

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.

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/

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.

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

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?

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.

The Relooper is good enough that the lack of goto isn't an issue in a practical sense these days.

The Emscripten Relooper algorithm "takes basic blocks of code - chunks of simple code, at the end of which are branches to other blocks of code - and generates high-level structure from that using loops and ifs."

http://mozakai.blogspot.com/2012/05/reloop-all-blocks.html

That's my point. The Relooper does a good job with vast majority of code that you might conceivably want to compile to JS, making the lack of goto not a problem in a practical sense for these compilers.

Hah, sorry, I didn't know what Relooper did, so I posted a comment describing where to find out about it for other people.

A VM is still a specific language, it just has a binary syntax. All VM's make tradeoffs which means they are a better fit for some languages than others. The fully language neutral VM does not exist. Given that, we might as well consider JavaScript a VM which just happen to have a text-based rater than binary source.

A VM is therefore not necessarily an improvement on JavaScript - it has to be a better VM than JavaScript, and nobody have designed that yet.

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.

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

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

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?

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.

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.

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

Reply on news.ycombinator.com