Skip to content
Adam Bergmark edited this page Nov 8, 2013 · 68 revisions

Build Status

A proper subset of Haskell that compiles to JavaScript.

Fay has the following properties:

Quick Start

Install Fay from hackage

cabal install fay fay-base

Write awesome software

module Hello where

import FFI
import Prelude

alert :: String -> Fay ()
alert = ffi "alert(%1)"

setBodyHtml :: String -> Fay ()
setBodyHtml = ffi "document.body.innerHTML = %1"

addWindowEvent :: String -> Fay () -> Fay ()
addWindowEvent = ffi "window.addEventListener(%1, %2)"

main :: Fay ()
main = do
  putStrLn "Hello Console!"
  alert "Hello Alert!"
  addWindowEvent "load" $ do
    putStrLn "The document has loaded"
    setBodyHtml "Hello HTML!"   

Compile it

fay Hello.hs --html-wrapper

--html-wrapper generates Hello.html that includes the compiled JavaScript.

open Hello.html

More information

Details on features

Misc

Contact and contributions

Fay in the Wild

Fay Packages

  • happstack-fay: Fay integration for Happstack hackage
  • snaplet-fay: Fay integration for Snap github, hackage
  • yesod-fay: Fay integration for Yesod github, hackage
  • fay-jquery: JQuery bindings github, hackage
  • fay-text: Data.Text interface represented by JavaScript strings github, hackage
  • fay-uri: FFI wrapper for jsUri, github, hackage
  • circle-packing: Given a number of circles with their radii, this package tries to arrange them tightly, without overlap and forming a large circle. Works with Fay, GHC, and Haste fay demo, hackage

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

More here

Comparisons to other methods

CoffeeScript and LiveScript

CoffeeScript is a syntactic layer above JavaScript that does not change semantics. It adds some additional syntactic constructs, but makes no fundamental changes, you are still essentially working in JavaScript, but with more convenient syntactic features.

Fay on the other hand is a different language to JavaScript entirely, with a different semantics. It is lazy, it has partial application and currying, pattern matching for all data types, all expressions are pure and only statements in the Fay monad can be impure.

LiveScript is also a similar approach in the wave of compile-to-JS projects that have developed in recent years. LiveScript's translation is also quite readable and predictable, this is also the only thing in common with Fay.

Roy and Elm

Roy is an approach to bring functional programming to JavaScript, it has lots of interesting features but it has different syntax and type-system semantics to Haskell.

Elm, equally, is an approach to bringing functional programming to the web, and is less generic than Roy, as it specifically focuses on web programming. It, too, borrows from Haskell and looks a bit like it, but is (consciously) different in syntax and semantics.

Both of these languages are very interesting and promising approaches. What Fay offers is to keep the existing compiler, GHC, for its battle-tested type checking and code analysis, and to use existing parsers for Haskell to support a subset of its syntax. This way, one does not have to replace the tooling infrastructure and workflow that one is used to. With the exception of actions in the Fay monad, pure functions can be type checked and run within GHCi.

Additionally, because all Fay code is Haskell code, certain modules can be shared between the ‘native’ Haskell and ‘web’ Haskell, most interestingly the types module of your project. This enables two things:

The enforced (by GHC) coherence of client-side and server-side data types. The transparent serializing and deserializing of data types between these two entities (i.e. over AJAX).