Sorry, your browser is not supported. A simplified version of the presentation follows. To get the full experience, please use a recent version of Chrome, Firefox, or Safari, or contact


Practical Functional Reactive Programming

Functional Reactive Programming is a way of writing interactive software using only pure functions

Pure functions enable equational and local reasoning

Equational reasoning means that we can refactor code safely

x+x ≡ 2*x

Local reasoning means that we can understand code in isolation

If f(x) = 2x, then f(3) ≡ 6

Equational and local reasoning make code maintainable and reusable

This makes Haskell amazing for batch systems, like compilers and web APIs, which mostly consume input at the beginning and produce output at the end

FRP brings the power of pure functions to interactive systems, such as web pages and audio synthesizers, which consume input and produce output over time

Reflex is a semantics for FRP and an implementation of that semantics

Reflex works with GHC and GHCJS

The flagship Reflex toolkit is Reflex.Dom: a library for building cutting edge web apps


Building a Twitter frontend

An input and its value

Adding an attribute

Displaying the length of the input

0 characters

Showing a value when an event occurs

0 characters
Last status:

Clearing the input after tweeting

0 characters
Last status:

Disallowing empty tweets

0 characters
Last status:

Building up a list of tweets

0 characters
Tweet history: []

Authorizing Twitter

0 characters

Making a tweet request

0 characters
Last status:

Showing a stream of tweets

Streaming with style

    Please login

Made with Reflex


This area is missing


Online document negotiation and collaboration


Real-time legal courier geolocation tracking


Powerful and flexible data analysis tools

This presentation

Built with Reflex.Dom, impress.js, and Snap

Try it out!

git clone
cd try-reflex

Practical systems must be expressive, comprehensible, and efficient

Practical FRP should support dynamic data flow

In Reflex.Dom, widgets can be created, laid out, or destroyed within the FRP semantics

Practical FRP should support a variety of concepts of time

Reflex only requires that time is ordered—both continuous and discrete time are possible

Practical FRP should be fully deterministic

All Reflex primitives have well-defined, implementation-independent behavior

Practical FRP should use idiomatic Haskell

Reflex has 10 primitives; 8 are pure and 2 are monadic

Practical FRP should have good performance

In Reflex, overall application size has no impact on event propagation time

Practical FRP should be fully garbage-collected

Reflex uses automatic memory management for all datastructures, even external callbacks


Trivial constructors

Mapping functions

Event distribution

Higher-order combinators


The Future of Reflex

Reflex is ready for production use today

The Reflex API is improving rapidly, so please use upper-bounds

Reflex is available on github and hackage