# '''JavaScript sucks.''' The depths to which JavaScript sucks is well-documented and well-understood. Its main faults are: its lack of module system, weak-typing, verbose function syntax¹, late binding², which has led to the creation of various static analysis tools to alleviate this language flaw³, but with limited success⁴ (there is even a static type checker⁵), finicky equality/automatic conversion, <code>this</code> behaviour, and lack of static types. Coffeescript is the most mainstream javascript alternative. Although it makes many aspects of Javascript sane and convenient, it still suffers from weak-typing.

+

# '''JavaScript sucks.''' The depths to which JavaScript sucks is well-documented and well-understood. Its main faults are: its lack of module system, weak-typing, verbose function syntax¹, late binding², which has led to the creation of various static analysis tools to alleviate this language flaw³, but with limited success⁴ (there is even a static type checker⁵), finicky equality/automatic conversion, <code>this</code> behaviour, and lack of static types.

−

#:

+

−

# '''We need JavaScript.''' Using it for what it is good for, i.e. providing a platform for browser development, but not using the language ''per se'', is therefore desirable, and many are working to achieve this, in varying forms. There various ways to do it, but we ought to opt for compiling an existing language, Haskell, to JavaScript, because we do not have time to learn or teach other people a new language, garner a new library set and a new type checker and all that Haskell implementations provide.

+

−

== Updating this page ==

+

# '''We need JavaScript.''' Using it for what it is good for, i.e. providing a platform for browser development, but not using the language ''per se'', is therefore desirable, and many are working to achieve this, in varying forms. There are various ways to do it, but we ought to opt for compiling an existing language, Haskell, to JavaScript, because we do not have time to learn or teach other people a new language, garner a new library set and a new type checker and all that Haskell implementations provide.

−

Please update and expand this page with the various attacks on this problem and their progress. The question of The JavaScript Problem comes up every so often and this should be the page to link people to.

+

== Mainstream alternatives ==

−

== Attacks ==

+

=== Coffeescript ===

+

It makes many aspects of Javascript sane and convenient, and you get a compilation check that verifies syntax, however it still suffers greatly from weak-typing.

+

+

=== TypeScript ===

+

+

Structural typing with traditional generics on top of Javascript.

+

Of all the alternatvies, TypeScript's advantage is that it makes no changes to Javascript. Existing javascript code that passes jshint is valid Typescript code. TypeScript also adds features from the latest javascript standards that it can compile down to older versions of javascript. TypeScript is by far the easiest javascript variant to learn. The downside is that one might desire a better language then just javascript + types.

+

+

TypeScript defaults to dynamic typing when it can't figure the type out. However, it now has a noImplicitAny setting that will give a compilation error if it can't figure out the type.

+

+

Structural sub-typing seems a good fit for JavaScript.

+

Perhaps Typescript's biggest problem is that null is a valid value for any type.

+

+

== Haskell -> JS ==

=== UHC ===

=== UHC ===

−

Original blog post [https://github.com/atzedijkstra/javascript-runtime-for-UHC here.] Quickstart guide [http://chrisdone.com/posts/2012-01-06-uhc-javascript.html here.] A more in-depth discussion about the current capabilities of the backend [http://www.norm2782.com/improving-uhc-js-report.pdf here.] Blog post of using UHC in a real app [http://alessandrovermeulen.me/2012/01/26/getting-rid-of-javascript-with-haskell/ here.]

+

Original blog post [https://github.com/atzedijkstra/javascript-runtime-for-UHC here.] Quickstart guide [http://chrisdone.com/posts/2012-01-06-uhc-javascript.html here.] A more in-depth discussion about the current capabilities of the backend [http://www.norm2782.com/improving-uhc-js-report.pdf here.] For an example of using the JavaScript compilation for a real app see this [http://alessandrovermeulen.me/2012/01/26/getting-rid-of-javascript-with-haskell/ blog post], there is also a port of wxAsteroids to the browser (see [http://uu-computerscience.github.io/js-asteroids/ github] or a [http://www.rubendegooijer.nl/posts/2013-04-06-haskell-oop.html blog post]).

* YHC JS backend — Beta-ish. Apparently works, but I was unable to compile YHC, so haven't tried yet. I would be interested in anyone's experience using it. There's [http://www.haskell.org/haskellwiki/Yhc/Javascript an old wiki page] about Yhc's JavaScript support, but Yhc itself is a dead project.

+

* Emscripten — not Haskell→JS, but compiles LLVM/Clang output to JavaScript. Could possibly be used for GHC→LLVM→JS compiling, which I tried, and works, but would have to also compile the GHC runtime which is not straight-forward (to me) for it to actually run.

* Some have also tried writing a Haskell→JS compiler to make a more direct JS-aware translation of code (to not have huge code output a la GHCJS, YHC, Emscripten).

+

+

+

== FP -> JS ==

+

+

== Ur/Web ==

+

+

http://www.impredicative.com/ur/

+

+

Perhaps the problem with Ur is that they are selling both a backend and a frontend together. Being a new language, the backend is lacking in libraries to be practical for many tasks. However, there is an RSS reader that is using Ur for the front-end and Haskell for the backend: https://bazqux.com/

+

+

+

=== OCaml ===

+

+

The OCaml -> JS compiler is supposed to be good, it is now used at facebook for an internal in-browser code editor.

+

http://ocsigen.org/js_of_ocaml/

+

+

=== GorrilaScript ===

+

+

http://ckknight.github.io/gorillascript/

+

+

immutable by default, global type inference, macros, what coffeescript should have been. The syntax is similar to coffeescript

+

=== [[JMacro]] ===

=== [[JMacro]] ===

Line 39:

Line 99:

On the Haskell wiki (see above) and on [http://hackage.haskell.org/package/jmacro hackage]

On the Haskell wiki (see above) and on [http://hackage.haskell.org/package/jmacro hackage]

* YHC JS backend — Beta-ish. Apparently works, but I was unable to compile YHC, so haven't tried yet. I would be interested in anyone's experience using it. There's [http://www.haskell.org/haskellwiki/Yhc/Javascript an old wiki page] about Yhc's JavaScript support, but Yhc itself is a dead project.

+

−

* Emscripten — not Haskell→JS, but compiles LLVM/Clang output to JavaScript. Could possibly be used for GHC→LLVM→JS compiling, which I tried, and works, but would have to also compile the GHC runtime which is not straight-forward (to me) for it to actually run.

* Some have also tried writing a Haskell→JS compiler to make a more direct JS-aware translation of code (to not have huge code output a la GHCJS, YHC, Emscripten), but ought to prefer to avoid NIH and hack on GHCJS or UHC.

1 The problem

The JavaScript problem is two-fold and can be described thus:

JavaScript sucks. The depths to which JavaScript sucks is well-documented and well-understood. Its main faults are: its lack of module system, weak-typing, verbose function syntax¹, late binding², which has led to the creation of various static analysis tools to alleviate this language flaw³, but with limited success⁴ (there is even a static type checker⁵), finicky equality/automatic conversion, this behaviour, and lack of static types.

We need JavaScript. Using it for what it is good for, i.e. providing a platform for browser development, but not using the language per se, is therefore desirable, and many are working to achieve this, in varying forms. There are various ways to do it, but we ought to opt for compiling an existing language, Haskell, to JavaScript, because we do not have time to learn or teach other people a new language, garner a new library set and a new type checker and all that Haskell implementations provide.

2 Mainstream alternatives

2.1 Coffeescript

It makes many aspects of Javascript sane and convenient, and you get a compilation check that verifies syntax, however it still suffers greatly from weak-typing.

2.2 TypeScript

Structural typing with traditional generics on top of Javascript.
Of all the alternatvies, TypeScript's advantage is that it makes no changes to Javascript. Existing javascript code that passes jshint is valid Typescript code. TypeScript also adds features from the latest javascript standards that it can compile down to older versions of javascript. TypeScript is by far the easiest javascript variant to learn. The downside is that one might desire a better language then just javascript + types.

TypeScript defaults to dynamic typing when it can't figure the type out. However, it now has a noImplicitAny setting that will give a compilation error if it can't figure out the type.

Structural sub-typing seems a good fit for JavaScript.
Perhaps Typescript's biggest problem is that null is a valid value for any type.

3 Haskell -> JS

3.1 UHC

Original blog post here. Quickstart guide here. A more in-depth discussion about the current capabilities of the backend here. For an example of using the JavaScript compilation for a real app see this blog post, there is also a port of wxAsteroids to the browser (see github or a blog post).

3.5 Others

YHC JS backend — Beta-ish. Apparently works, but I was unable to compile YHC, so haven't tried yet. I would be interested in anyone's experience using it. There's an old wiki page about Yhc's JavaScript support, but Yhc itself is a dead project.

Emscripten — not Haskell→JS, but compiles LLVM/Clang output to JavaScript. Could possibly be used for GHC→LLVM→JS compiling, which I tried, and works, but would have to also compile the GHC runtime which is not straight-forward (to me) for it to actually run.

hjscript — Beta. EDSL, not Haskell→JS. Works. Not very annoying to program in, but is JS semantics, not Haskell. Hackage package here.

Some have also tried writing a Haskell→JS compiler to make a more direct JS-aware translation of code (to not have huge code output a la GHCJS, YHC, Emscripten).

4 FP -> JS

5 Ur/Web

Perhaps the problem with Ur is that they are selling both a backend and a frontend together. Being a new language, the backend is lacking in libraries to be practical for many tasks. However, there is an RSS reader that is using Ur for the front-end and Haskell for the backend: https://bazqux.com/

6 Links

7 Footnotes

Its support for closures is commonly noted as being one of JavaScript’s redeeming features.

Early binding allows for static verification of the existence of method-signature pairs (e.g. v-tables). Late binding does not give the compiler (or an IDE) enough information for existence verification, it has to be looked up at run-time.

There are several hinting libraries, which developers insist are indispensable tools when developing JavaScript seriously, such as JavaScript lint, JSLint, and JSure.