Difference between revisions of "The JavaScript Problem"

From HaskellWiki
Jump to navigation Jump to search
(14 intermediate revisions by 9 users not shown)
Line 3: Line 3:
 
The JavaScript problem is two-fold and can be described thus:
  
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, 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.
 +
# '''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.
  +
#:
−  
−
# '''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.
 +
# '''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.
   
 
== Updating this page ==
  
== Updating this page ==
Line 22: Line 22:
 
* Doesn't produce an explosion of code, seemingly.
  
* Doesn't produce an explosion of code, seemingly.
 
* Fairly substantial JS/DOM/W3C/HTML5 API.
  
* Fairly substantial JS/DOM/W3C/HTML5 API.
  +
* Currently works.
  +
  +
=== Fay ===
  +
  +
Website: http://fay-lang.org/ Discussion on Reddit: [http://www.reddit.com/r/haskell/comments/11yrpi/fay_slides/ Fay slides]. The package is on [http://hackage.haskell.org/package/fay Hackage]. Fetch with Git:
  +
git clone git://github.com/faylang/fay.git
  +
  +
* Compiles a subset of Haskell, needs more
 
* Currently works.
  
* Currently works.
   
 
=== GHCJS ===
  
=== GHCJS ===
   
−
The Github page is [https://github.com/sviperll/ghcjs here.]
 +
The Github page is [https://github.com/ghcjs/ghcjs here.]
   
 
* Alpha.
  
* Alpha.
Line 35: Line 43:
 
* FFI to JS works, and the author, sviperll is a helpful guy.
  
* FFI to JS works, and the author, sviperll is a helpful guy.
   
−
=== lambdascript ===
 +
=== Haste ===
   
  +
[https://github.com/valderman/haste-compiler Haste on GitHub], [https://github.com/valderman/glosie/tree/hsglosie example application], [http://ekblad.cc/hastereport.pdf thesis paper].
−
The Github page is [https://github.com/valderman/lambdascript/ here.]
  
   
  +
* Work in progress.
−
* Alpha.
 
  +
* Generates relatively small code (in general between 0.9 and 5 times the size of functionally equivalent JS).
⚫
* Not Haskell.
 
  +
* Also generates relatively fast code (run times in general between 0.9 and 8 times that of functionally equivalent JS).
−
* No polymorphism.
 
  +
* Works.
−
* Bad syntax (Haskell-ish, but not quite, should use the haskell-src-exts parser—will do in the future).
 
  +
* Very simple runtime.
⚫
* Maintained.
 
  +
* Accompanying FRP and very basic DOM libraries.
−
* Nice effort.
  
  +
* Calling back into JS via FFI is supported.
  +
* (Supposed to be) relatively easy to install and use.
  +
  +
=== [[JMacro]] ===
  +
  +
On the Haskell wiki (see above) and on [http://hackage.haskell.org/package/jmacro hackage]
  +
  +
* Mature
  +
* Works
  +
* Complete
  ⚫
* Maintained
  ⚫
* Not Haskell
  +
* Syntax is a fusion of Haskell and JavaScript
  +
* Untyped, but with syntactic correctness (at least) enforced at compile-time.
  +
* Embeddable through quasi-quoting
  +
* Support for various forms of code-generation
  +
  +
=== Roy ===
  +
  +
[http://roy.brianmckenna.org/ Roy]: meld JavaScript semantics with functional languages. Experimental, but has many bread-and-butter Haskell features. Probably does not generate efficient code.
   
 
=== Others ===
  
=== Others ===
Line 50: Line 78:
 
* [https://github.com/johang88/haskellinjavascript Haskell interpreter in JS] — An interpreter. Haven't tried but is apparently dead.
  
* [https://github.com/johang88/haskellinjavascript 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 [http://www.haskell.org/haskellwiki/Yhc/Javascript an old wiki page] about Yhc's JavaScript support, but Yhc itself is a dead project.
  
* 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. Hackage package [http://hackage.haskell.org/package/HJScript here.]
 +
* 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.
 +
* hjscript — Beta. EDSL, not Haskell→JS. Works. Not ''very'' annoying to program in, but is JS semantics, not Haskell. Hackage package [http://hackage.haskell.org/package/HJScript 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), but ought to prefer to avoid NIH and hack on GHCJS or UHC.
  
* 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.
  +
  +
== Links ==
  +
  +
* [https://github.com/yesodweb/yesod/wiki/Javascript-Options Yesod - Javascript Options]
  +
* [http://chrisdone.com/tags/javascript.html Chris Done Blog] - Tag: Javascript
   
 
== Footnotes ==
  
== Footnotes ==
Line 61: Line 94:
 
# “Any non-trivial analysis is very difficult due to Javascript’s dynamic nature.” — Berke Durak, Ph.D., author of jsure.
  
# “Any non-trivial analysis is very difficult due to Javascript’s dynamic nature.” — Berke Durak, Ph.D., author of jsure.
 
# Google Inc. thought it necessary to develop a compiler, Google Closure, which does type-checking and limited inference.
  
# Google Inc. thought it necessary to develop a compiler, Google Closure, which does type-checking and limited inference.
  +
  +
  +
[[Category:Web|*]]

Revision as of 13:17, 3 November 2012

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, 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. Coffeescript is the most mainstream javascript alternative. Although it makes many aspects of Javascript sane and convenient, it still suffers from weak-typing.
  2. 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.

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.

Attacks

UHC

Original blog post here. Quickstart guide here. A more in-depth discussion about the current capabilities of the backend here. Blog post of using UHC in a real app here.

  • Beta.
  • Only works for UHC, but promising.
  • UHC 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.

Fay

Website: http://fay-lang.org/ Discussion on Reddit: Fay slides. The package is on Hackage. Fetch with Git: 

 git clone git://github.com/faylang/fay.git
  • Compiles a subset of Haskell, needs more
  • Currently works.

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.

Haste

Haste on GitHub, example application, thesis paper.

  • Work in progress.
  • Generates relatively small code (in general between 0.9 and 5 times the size of functionally equivalent JS).
  • Also generates relatively fast code (run times in general between 0.9 and 8 times that of functionally equivalent JS).
  • Works.
  • Very simple runtime.
  • Accompanying FRP and very basic DOM libraries.
  • Calling back into JS via FFI is supported.
  • (Supposed to be) relatively easy to install and use.

JMacro

On the Haskell wiki (see above) and on hackage

  • Mature
  • Works
  • Complete
  • Maintained
  • Not Haskell
  • Syntax is a fusion of Haskell and JavaScript
  • Untyped, but with syntactic correctness (at least) enforced at compile-time.
  • Embeddable through quasi-quoting
  • Support for various forms of code-generation

Roy

Roy: meld JavaScript semantics with functional languages. Experimental, but has many bread-and-butter Haskell features. Probably does not generate efficient code.

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.
  • 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), but ought to prefer to avoid NIH and hack on GHCJS or UHC.

Links

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.
Retrieved from "https://wiki.haskell.org/index.php?title=The_JavaScript_Problem&oldid=54592"