Personal tools

The JavaScript Problem

From HaskellWiki

Revision as of 18:19, 27 January 2012 by Chrisdone (Talk | contribs)

Jump to: navigation, search

Contents

1 The problem

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

  1. JavaScript sucks. The depths to which JavaScript sucks is well-documented and well-understood. Its main faults are: its lack of module system, 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.
  1. 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.

2 Updating this page

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.

3 Attacks

3.1 UHC

Original blog post here. Quickstart guide here. Blog post of using UHC in a real app here.

  • Beta.
  • Only works for UHC, but promising.
  • HC compiles enough of Hackage to be very useful.
  • Doesn't produce an explosion of code, seemingly.
  • Fairly substantial JS/DOM/W3C/HTML5 API.
  • Currently works.

3.2 GHCJS

The Github page is here.

  • Alpha.
  • Works.
  • Incomplete.
  • Nicely designed.
  • Compiles most pure Haskell libraries no problem.
  • FFI to JS works, and the author, sviperll is a helpful guy.

3.3 lambdascript

The Github page is here.

  • Alpha.
  • Not Haskell.
  • No polymorphism.
  • Bad syntax (Haskell-ish, but not quite, should use the haskell-src-exts parser—will do in the future).
  • Maintained.
  • Nice effort.

3.4 Others

  • Haskell interpreter in JS — An interpreter. Haven't tried but is apparently dead.
  • 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. Hackage package here.
  • hjscript — Beta. EDSL, not Haskell→JS. Works. Not very annoying to program in, but is JS semantics, not Haskell.
  • 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.

4 Footnotes

  1. Its support for closures is commonly noted as being one of JavaScript’s redeeming features.
  2. 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.
  3. There are several hinting libraries, which developers insist are indispensable tools when developing JavaScript seriously, such as JavaScript lint, JSLint, and JSure.
  4. “Any non-trivial analysis is very difficult due to Javascript’s dynamic nature.” — Berke Durak, Ph.D., author of jsure.
  5. Google Inc. thought it necessary to develop a compiler, Google Closure, which does type-checking and limited inference.