Home

A proper subset of Haskell that compiles to JavaScript.

Fay has the following properties:

• A proper syntactic and semantic subset of Haskell
• Statically typed
• Lazy
• Pure by default
• Compiles to JavaScript
• Has fundamental data types (Double, String, etc.) based upon what JS can support, and compound data types (ADTs and GADTs)
• Outputs minifier-aware code for small compressed size
• Has a trivial foreign function interface to JavaScript
• Supports cabal installation of Fay packages
• Can automatically transcode values to/from JSON using the FFI
• Provides an API to transcode on the server side as well
• Lets you call Fay code from JavaScript
• Has the Fay monad for side effects (think of it like IO)

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

• Installing and running
• Contributing to Fay
• Package management with Cabal
• Changelog

Details on features

• Calling Fay from JavaScript
• Foreign Function Interface
  • Minimal FFI Example: alert
  • FFI Example: fay-uri
• What is not supported?
• Using fay-text/OverloadedStrings

Misc

• Why Fay does not currently support type-classes
• Fay Status Update September 2013: ZuriHac, typeclasses, haskell suite, and strictness wrappers
• Generated code
• Reducing output size

Contact and contributions

• File an issue on github
• IRC: #fay @ irc.freenode.net
• Twitter: @FayHaskell
• The Fay tag on StackOverflow

Fay in the Wild

• Calcudoku Solver/Tutorial
• Cinder: A nice SVG/DOM manipulation library
• Yesod Blog: Yesod, AngularJS and Fay
• Happstack Blog: Happstack, Fay, & Acid-State: Shared Datatypes are Awesome
• Fun with Fay - A Ring Oscillator
• CodeWorld and the Future
• A Fay IDE written in Fay (needs an update for recent fay versions)

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

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).