- lack of module system (only pre-ES6),
- verbose function syntax1 (pre-ES6),
- late binding2, which has led to the creation of various static analysis tools to alleviate this language flaw3, but with limited success4 (there is even a static type checker5),
- finicky equality/automatic conversion,
- and lack of static 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.
Haskell -> JS
- 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.
git clone git://github.com/faylang/fay.git
- Compiles a subset of Haskell, needs more
- Currently works.
The GitHub page is here.
- Nicely designed.
- Compiles most pure Haskell libraries no problem.
- FFI to JS works, and the author, sviperll is a helpful guy.
- Seamless, type-safe single program framework for client-server communication
- Generates small, fast, minifiable code.
- Lightweight concurrency, Cabal integration, FFI and GHC extensions supported.
- Cross platform.
On the Haskell wiki (see above) and on Hackage
- Mature, Maintained
- Not Haskell but an EDSL _in_ Haskell nonetheless.
- JMacro Panels provides a purely Haskell combinator library that generates dynamically updating html and js with asynchronous client-server communication.
- Untyped, but with syntactic correctness (at least) enforced at compile-time.
- Embeddable through quasi-quoting
- Support for various forms of code-generation
- Haskell interpreter in JS — An interpreter. Haven't tried but is apparently dead.
- 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).
- I've tried compiling via JHC and Emscripten a while ago, which worked, but IIRC the output was rather slow.
- It's also possible to compile Hugs via Emscripten, which works (with minor tweaks), but again, it's too slow.
FP -> JS
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/
Similar to Ur/Web, write one language in the front-end and backend: http://opalang.org/ Haven't tried it. No idea what its type-system is like.
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/
immutable by default, global type inference, macros, what coffeescript should have been. The syntax is similar to coffeescript
- Full dependent types with dependent pattern matching where clauses, with rule, simple case expressions, pattern matching let and lambda bindings
- Dependent records with projection and update
- Type classes
- Monad comprehensions
- Syntactic conveniences for lists, tuples, dependent pairs do notation and idiom brackets
- Indentation significant syntax
- Extensible syntax
- Tactic based theorem proving (influenced by Coq)
- Cumulative universes
- Totality checking
- Simple foreign function interface (to C)
- Hugs style interactive environment
- Website idris-lang.org
- Dependent Type in haskell wiki
- WP (en) Dependent type (with Idris listed under language comparison)
Elm is a reactive pure functional programming language implemented in Haskell, which takes heavy inspiration from Haskell's syntax. It's considered a direct competitor to PureScript, since it's basically a more beginner-friendly yet pared down "Haskell for the web". Unfortunately, this desire to be beginner-friendly has left Elm without Higher Kinded Types. It has a simple foreign function interface for JS interop, called "ports".
- 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.
- Google Inc. thought it necessary to develop a compiler, Google Closure, which does type-checking and limited inference.