The JavaScript blog.


libraries functional modules reactive

most.js: Monadic Reactive Streams

Posted on .

Nick Ts. sent in most.js (GitHub: cujojs/most, License: MIT, npm: most), a reactive programming library designed for working with streams of values and events. You can use it with WebSocket, DOM events, and it should work with fantasy land and Promises/A+.

Let's say you've got an HTML fragment that you want to make dynamic. It should update in real-time based on user input. Here's a snippet:

  <input class="x"> + <input class="y"> = <span class="result"></span>

The goal is to make the form sum two numbers. Given a simple add function, and a function to cast the form's strings to numbers, a reactive most.js implementation could look like this:

var most = require('most');

var xInput = document.querySelector('input.x');  
var yInput = document.querySelector('input.y');  
var resultNode = document.querySelector('.result');

exports.main = function() {  
  // x represents the current value of xInput
  var x = most.fromEvent('input', xInput).map(toNumber);

  // y represents the current value of yInput
  var y = most.fromEvent('input', yInput).map(toNumber);

  // result is the live current value of adding x and y
  var result = most.combine(add, x, y);

  // Observe the result value by rendering it to the resultNode

function add(x, y) {  
  return x + y;

function toNumber(e) {  
  return Number(e.target.value);

function renderResult(result) {  
  resultNode.textContent = result;

The API is different to React and Knockout, but you should be able to follow it. There's a method called fromEvent that can map DOM events to JavaScript functions, then a method called combine that creates a new stream based on the streams from the two inputs. What's cool about this is you could further process the streams with to do things like throttling or tailing the results.

The people behind most.js have made sure it performs well, and there are some promising benchmarks. The library itself is from cujoJS, which is described as a toolkit for building web applications. The most.js readme has some functional and ES6 generators, so if you're interested in seeing what most.js looks like with generators then take a look there.

You can use most.js without worrying too much about what things like monads and functors are, but if you're interested in functional programming in JavaScript then you should try out Fantasy Land Specification.


functional libraries reactive

ADT Streams

Posted on .

More libraries are starting to blend ideas from functional programming, streams, and reactive programming. Yassine Elouafi sent in ADT Streams (License: MIT, npm: adtstream), a library that offers a stream API using promises and algebraic data types. It has methods for wrapping other streams, like Stream.fromReadable for use with Node's Readable streams, Stream.fromEmitter for objects that extend EventEmitter, and Stream.fromDomEvent for working with DOM events in the browser.

There are utility methods, like Stream.seq for yielding elements from a sequence over time. The blog post, Promises + FP = Beautiful Streams explains each of the library's methods with examples first in Haskell and then in JavaScript. It also has some background on streams and reactive programming:

The basic idea is that you can represent different asynchronous data like events or http responses by an unifying concept called observable collections. Then you can manipulate those collections by standard array operations like map, filter, reduce, forEach ...etc.

By using Yassine's library, you can compose streams with different sources: you can mix events and readable streams with the same API.

The author also wrote From callback to (Future -> Functor -> Monad), which argues why callbacks are not composable and alternative solutions:

With composition, you never hit a wall, because you must always ask yourself "What is the return value of this function?", or put another way "What is the meaning of this thing?"

I don't mind using callbacks in my code. In fact, callbacks are great for things such as representing side effects or event notification, but once your start using them to manage your control flow, you're trapped, why? because they do not compose.

Both of these posts will be of interest to you if you're a JavaScript programmer without much functional or reactive programming experience.


functional node browser modules libraries reactive

Flyd: Reactive Functional Programming

Posted on .

When I see yet another reactive programming library, I think to myself "that's just not functional enough!" And the libraries that keep me interested in JavaScript are almost always pushing functional practices or static type checking.

Therefore I was interested to see Flyd (GitHub: paldepind/flyd, License: MIT, npm: flyd) by Simon Friis Vindum in my DailyJS inbox today. This project aims to model values that change over time using reactive and functional concepts without adding too much extra baggage.

Flyd is more functional than existing FRP libraries. Instead of methods it gives you curried functions with arguments in the order suitable for partial application. This gives more expressive power and modularity.

The building block in Flyd is streams. You can plug them in wherever a function is expected:

var clicks = flyd.stream();  
document.getElementById('button').addEventListener('click', clicks);  
var messages = flyd.stream();  
webSocket.onmessage = messages;  

Streams can depend on other streams, which is where the functional composition of Flyd comes in.

The author has provided some nice interactive examples that make the library easier to visualise. Take a look at the sum example to get started. And if you're interested in comparing to RxJS, then compare this Flyd code to functionally equivalent RxJS code.


libraries functional modules

Simplifying Conditional Statements with Is

Posted on .

Is (GitHub: jumpkick-studios / Is, License: MIT) by Alex Bogartz cuts down conditional statements with a more declarative API. It's inspired by the Maybe monad pattern.

The author compares a lengthy, nested conditional statement to his chainable alternative:

new Is(foo)  
  .then(() => {
  .catch(() => {
    throw new Error('bad foo');

The main library's source and tests are written with TypeScript, which means it looks very similar to standard JavaScript with the addition of type hints and succinct lambda expressions. You don't have to use TypeScript to use it, but I think it reads quite nicely that way.

One nice feature of this library is you can avoid the need for checking for undefined values. For example, given var foo = { bar: undefined }:

new Is(foo.bar)  
  .catch(() => {
    console.log('Please provide "bar"');

The code in catch will run even if foo.bar is undefined.


functional ui mvvm data-binding

Why Ramda?, Two-Way Data Binding Review

Posted on .

Why Ramda?

Scott Sauyet sent in Why Ramda?, a post that attempts to explain the Ramda library:

To those not used to functional programming, Ramda seems to serve no purpose whatsoever. Most of its major capabilities are already covered by libraries like Underscore and LoDash.

These folks are right. If you want to keep coding with the same imperative and object-oriented styles you've been using, Ramda does not have much to offer you.

However, it does offer a different style of coding, a style that's taken for granted in purely functional programming languages: Ramda makes it simple for you to build complex logic through functional composition. Note that any library with a compose function will allow you do functional composition; the real point here is: "makes it simple".

The article builds on the functional composition idea and leads up to the kind of data-focused programming that Ramda makes possible.

Two-Way Data Binding Review

Two-Way Data Binding by Nikita Vasilyev is a review of two-way data binding in Backbone, React, Angular, Meteor and plain JavaScript.

It highlights an issue that some libraries might have if they change fields at the wrong time:

The problem is that data flows from an input field to a model, and then back to the same input field, overriding the current value even if it's exactly the same.

React.js doesn't have Backbone's problem with moving the cursor position. Its virtual DOM, a layer between the actual DOM and React's state, prevents React from unnecessary DOM changes.

There's also an informative comment by Leo Horie about the effort required to learn each framework:

Something that strikes me about the framework versions is the amount of framework-specific knowledge required to get these examples working. It's one thing to say "here's a version in framework X", and it's quite another to actually write the code (from the standpoint of someone who's still considering framework options and who is not familiar with the lingo and caveats for any of them.)