
In my time, I've done a number of side projects — some [serious](https://agripongit.vincenttunru.com), some [decidedly less so](https://makeapoint.vincenttunru.com). My latest side project is quite definitely in the latter category: trying to win a game show on national television.

## Lingo

The show in question is [Lingo](https://en.wikipedia.org/wiki/Lingo_(Dutch_game_show)), a show that ran in the Netherlands for 25 years and, after a 5-year hiatus, returned on air this year. Roughly speaking, it can be described as [Mastermind](https://en.wikipedia.org/wiki/Mastermind_(board_game)) with words.

The goal is to guess a five- or six-letter word in at most five guesses. The first letter is given, and after every guess players are told which letters their guess shares with the actual word, and which of those are also in the correct position. An example should clear things up.

![](/img/hacking-a-gameshow/aspect.png)

Let's say it's my turn. The word to find is _aspect_ — but of course, I don't know that yet. All I know is that the word is six characters long, and starts with the letter _a_. My first guess is 'actors' which, although not the word we're looking for, does share the letters 'c', 't' and 's' with the one we _are_ looking for, albeit in different positions.

Still clueless about the actual word, my next guess is 'assume'. Now, not only is the letter 'e' part of the word we're looking for, but the first 's' is actually in the same place! Given that I now know that the first two letters are an 'a' and an 's', and that the rest of the word contains a 'c', a 't' and an 'e', I can make a reasonably informed guess that the word we're looking for is, in fact, _aspect_.

Two teams take turns guessing a word. Roughly, the team that guesses most words correctly wins.

## Our strategy

One way to win at Lingo is to have a large vocabulary and a keen eye. I teamed up with my brother, and although we both speak Dutch just fine, we are certainly not good enough to win this game — we barely even made it through the qualifiers.

So we started working on a strategy to increase our odds of winning. Of course, we're not the first ones to try to do so: a commonly adopted strategy is to memorise a list of words that cover most of the vowels. Using those words as the first guesses increases the likelihood of letters overlapping with the word you're looking for. However, we felt there was still room for improvement to this strategy.

By focusing on vowels, you are pretty much guaranteed to find at least one of the target word's letters, and maybe one or two more if you're lucky. But if we were to focus not just on the vowels, but on the most common letters for every possible first letter, we might be able to push that number up quite a bit!

So I set to work. The first step was to find a list of all the possible words in the Dutch language. Luckily, Wikipedia's fantastic sister project [Wiktionary](https://www.wiktionary.org) has carefully [documented](https://en.wiktionary.org/wiki/Wiktionary:Frequency_lists) their efforts to determine which words they should focus on. That led me to the fantastic work by [Hermit Dave](https://invokeit.wordpress.com), who parsed a large number of subtitles to compile [Frequency Word Lists](https://github.com/hermitdave/FrequencyWords/) for many languages, including Dutch.

Word list in hand, I wrote a script to count the most frequently occurring letters for every starting letter, for both five- and six-letter words. For example, it enumerated all six-letter words that start with an `s`, then tallied how many of them contained an 'a', how many of them contained a 'b', etc.

![](/img/hacking-a-gameshow/tally.svg)

Then, for each of those words, it considered how often the letters of those words were used in the entire list, and gave me one of the words that cover most occurrences.

![](/img/hacking-a-gameshow/topword.svg)

It then went on to select the word that contained the most frequently occurring of the remaining letters _not_ covered by the selected word.

![](/img/hacking-a-gameshow/secondword.svg)

That was repeated once more to end up with a list of three words that show significant overlap with most six-letter words starting with an 's'.

The entire process was repeated for every letter in the alphabet, over both five- and six-letter words. By memorising all of them, my brother and I could spend our first three guesses covering as many relevant letters as possible, and then have two more guesses remaining to find the correct word.

(Fun fact: my brother [is a comedian](https://www.andriestunru.nl), and in one part of his latest show he asks members of the audience to prompt him with letters, to which he'll respond by rattling off the words we memorised. He's still got it!)

## Practice makes perfect

While it wasn't feasible for us to significantly expand our vocabulary in preparation for the show, we could certainly improve our ability to find the right words given a set of letters. Thus, I wrote [a small practice application](https://lingo.vincenttunru.com) ([source code](https://gitlab.com/vincenttunru/lingo/)) that would serve us words from the word lists, take our guesses, and then rate them.

![](/img/hacking-a-gameshow/app.webm)

This was a great help not only in memorising words, but also to help us detect and internalise patterns. For example, we learned that often, if only few letters were covered by our initial three words, the gaps would be repeat occurrences of the letters we _did_ already find.

Additionally, since the words were also selected from the list, it gave a more realistic picture of the words we'd encounter in practice: we'd be more likely to encounter words starting with an 's' that those that start with a 'z'.

## So, how did it go?

Pretty well! Although the game still involves quite a bit of luck, we were certainly aided by our far too extensive preparations in achieving a winning streak lasting a week. But of course, given the incredible geekiness of it all, the most important thing is that [we had a lot of fun doing it](https://www.sbs6.nl/programmas/lingo/videos/Vk9EpXSlwas/lingo/).

![](/img/hacking-a-gameshow/on-the-show.png)

(And for the Dutch readers: yes, the [word that went viral](https://www.dumpert.nl/item/7803325_e71d8b7e) was actually one of the best three.)

[![License](//i.creativecommons.org/l/by/4.0/80x15.png)](//creativecommons.org/licenses/by/4.0/)

_This work by [Vincent Tunru](https://vincenttunru.com/) is licensed under a [Creative Commons Attribution 4.0 International License](//creativecommons.org/licenses/by/4.0/)._


My latest side project involved writing software that helped me win a game show on national television.

How I spent way too much effort to win a game show on national television



This post is a summary of a talk I gave today, in which I made the case for Functional Reactive Programming in Javascript using libraries such as [RxJS](http://reactivex.io/rxjs/).

## Bugs, bugs, bugs

> If debugging is the process of removing bugs, then programming must be the process of putting them in. —Edsger W. Dijkstra

All else being equal, software with fewer bugs is better than software with more bugs. To minimise the amount of bugs we ship, we spend a considerable amount of effort on debugging. A more time-efficient way of achieving this same goal, of course, is to prevent us from writing these bugs in the first place.

To find out how we can avoid writing bugs, let's consider what a bug is: software doing things the programmer did not expect it to do. In other words: the harder it is for us to understand the code we work on, the more likely it is to contain bugs.

So what makes our code hard to follow? Consider the following example code:

```js
let counter = 0;

function increment(){
  counter++;
}

function decrement(){
  counter--;
}
```

It looks rather innocent: we have a counter with an initial value of 0, and the functions `increment` and `decrement` to respectively increase and decrease its value by 1. It exhibits a problematic property described by three words: **shared mutable state**.

In short, the _state_ of the application is located in `counter`, which holds the current value of the counter at any point during the lifetime of the application. Both functions _share_ access to `counter`, and both can modify ("_mutate_") its value.

Looking at the code above, my earlier claim that this is hard to follow seems absurd. Consider, however, any non-trivial codebase, where functions consist of more than one line, and `increment`, `decrement` and `counter` might all be located in different files. In that case, anyone who wants to edit either of those will have to keep the rest of the codebase in mind, because bugs might be lurking there when you modify the code here.

## Our saviour: pure functions

The way around this is by using _pure functions_: functions that do not modify anything outside of themselves (in other words: they don't rely on _side effects_). Instead, they receive everything they need as input, apply some transformations, and provide the result as output. With this in mind, the `increment` function might receive a number representing the current counter value, and return a new number that is 1 higher than that:

```typescript
function increment(counter){
  return counter + 1;
}
```

And of course, likewise for `decrement`.

So how would we use functions written in this way? Well, rather than simply calling the function and hoping for something to happen, we have to pass it the correct input and then use the output to update the counter:

```js
let counter = 0;
counter = increment(counter);
```

But of course, this is not what we usually do. Rather, we increment the counter in response to e.g. the user clicking a button. So we'd actually write a handler for the click event:

```js
let counter = 0;

function onClick(){
  counter = increment(counter);
}
```

…but now we're back in the land of shared mutable state: `onClick` changes a value outside of its own scope! Does this mean we're stuck now? Of course not!

## Functional Reactive Programming to the rescue!

Using the principles of Functional Reactive Programming, we can write the largest part of our application using nothing but pure functions. We can do so by pushing side effects to the "edge" of our application, where it interacts with the "outside world", such as responding user input or receiving HTTP responses. We convert those into Observables as soon as possible, [which we can manipulate using nothing but pure functions](https://vincenttunru.com/3-metaphors-that-show-the-power-of-the-Observable/#metaphor-3-observables-as-a-way-around-shared-mutable-state).

For our counter example, this would look somewhat like this:

```js
// Convert user input to Observables
const incrementButton = document.getElementById('incrementButton');
const decrementButton = document.getElementById('decrementButton');

const incrementClick$ =
  Observable.fromEvent(incrementButton, 'click');
const decrementClick$ =
  Observable.fromEvent(decrementButton, 'click');

// Convert this input to an Observable producing counter values,
// using nothing but pure functions
const counter$ =
  Observable.merge(
    incrementClick$.map(() => 1),
    decrementClick$.map(() => -1)
  )
  .startWith(0)
  .scan((accumulator, value) => accumulator + value);

// Subscribe to counter values, and display them to the user
counter$.subscribe(counter => {
  document.getElementById('counter').innerHTML = counter.toString();
});
```

As you can see, we need a few lines of side effects at the top and bottom where we deal with the outside world. The meat of our application, however, consists only of pure functions that do not share state. The challenge here is to [understand Observables](https://vincenttunru.com/3-metaphors-that-show-the-power-of-the-Observable/), but once you've got that down FRP code is relatively easy to follow. Which means we'll write fewer bugs!

(And that's even without considering how easy it is to write unit tests for pure functions.)

## Summing up

As we saw, code that is hard to follow has more bugs. Code becomes hard to follow when it contains shared mutable state. Pure functions avoid this, but it can be a challenge to use them extensively.

That is where Functional Reactive Programming comes in. FRP allows us to represent changing state, while allowing us to keep (most of) our application logic pure.

If this captured your interest, I would encourage you to [read more about Functional Reactive Programming](https://vincenttunru.com/Javascript-reactive-programming/).

[![License](//i.creativecommons.org/l/by/4.0/80x15.png)](//creativecommons.org/licenses/by/4.0/)

_This work by [Vincent Tunru](https://vincenttunru.com/) is licensed under a [Creative Commons Attribution 4.0 International License](//creativecommons.org/licenses/by/4.0/)._


The case for Functional Reactive Programming


There's a lot of excitement about reactive programming in the front-end community:

- Angular [ships](https://angular.io/docs/ts/latest/guide/server-communication.html#rxjs-library) RxJS with Angular 2
- There's a [draft proposal](https://github.com/tc39/proposal-observable) to add an Observable to Javascript proper
- There's [a framework](https://cycle.js.org/) built entirely around the Observable
- React is most commonly used in [a reactive application structure](https://vincenttunru.com/Javascript-reactive-programming/#frp-today) together with [Redux](http://redux.js.org/)
- …and if not with Redux, then with the Observables of [MobX](https://mobxjs.github.io/mobx/)

Reactive programming is everywhere, so it's time we took a look at its primary concept: the Observable. What problems does it solve for us?

To answer this question, I will present three different metaphors that highlight situations that Observables can deal with elegantly. After this article, you should have a good idea of when to use Observables, and for what.

## Metaphor 1: Observables as special Promises

A [Promise](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Promise) is a data structure that represents a value that might not be immediately available. This is very useful when you want to perform some action as soon as that value does become available. An example use case is when you have made an HTTP request: at a certain moment, the response is going to come in, at which point you will want to perform some action. A Promise can then represent that eventual response.

A Promise could be described as such:

![A long arrow pointing to the right. At the far end at the right-hand side, a circle labeled "3" is located on the arrow, on top of a vertical line.](/img/3-metaphors-that-show-the-power-of-the-Observable/promise_marbles.png)

The arrow represents the passage of time; at a certain point, the promise is resolved with the value `3`.

### What can Observables do for me?

A Promise is useful if you're waiting for a single value, and want to perform an action when that value comes in. But what if you're waiting for multiple values? For example, what if you're waiting for user input, where you're waiting for multiple keypresses that drip in one by one?

This is where Observables come in. They can be seen as _Promises that can return multiple values_:

![A long arrow pointing to the right. On top of the arrow are, from left to right, three circles labeled "1", "2" and "3", respectively, followed by a vertical line.](/img/3-metaphors-that-show-the-power-of-the-Observable/observable_marbles.png)

The above is an Observable that, at different moments in time, delivers the values `1`, `2` and then `3`. Some time after that, it "completes": no more values are to be expected. This is indicated by the vertical line.

## Metaphor 2: Observables as a Design Pattern

Design Patterns are best practice approaches to common problems in software design. For example, the _Iterator_ pattern is a common approach to dealing with containers with multiple elements, e.g. lists of users. Your code can use an Iterator to get access to the container's elements, without needing to care about the container's implementation. 

![Schematic representation of an Iterator: a block of code with three arrows pointing to an Iterator. The arrows represent method calls to access elements from the container.](/img/3-metaphors-that-show-the-power-of-the-Observable/iterator.png)

Likewise, the _Observer_ pattern is a common approach when you have code that needs to become active when something happens elsewhere in the code. In this pattern, your code (the Observer) can register itself with a Subject, which will then notify it when the change has occurred.

![Schematic representation of an Observer: a block of code (the Observer) with an arrow pointing to it from a Subject. The arrow represents a method call on the Observer to notify it of an update.](/img/3-metaphors-that-show-the-power-of-the-Observable/observer.png)

### What can Observables do for me?

Whereas an Iterator is useful when you have a container with multiple elements readily available, an Observable shines when these elements might not yet be available. For example, when you need to call several REST APIs to collect all profile data related to a user, the different elements of the profile might arrive at different moments. Using an Observable, you can construct the full profile as the data rolls in.

Observables can be seen as a combination of the Iterator pattern and the Observer pattern. Whereas the Iterator is _pull_-based (your code "pulls" values out of the Iterator), an Observable is _push_-based: the Observable "pushes" values to your code as they arrive. 

![Schematic representation of an Observable: a block of code with three arrows pointing to it from an Observable. The arrow represents method calls on your code to provide it with new elements as they arrive.](/img/3-metaphors-that-show-the-power-of-the-Observable/observable.png)

## Metaphor 3: Observables as a way around shared mutable state  

Consider two functions that increment and decrement a counter, respectively:

```js
let counter = 0;

function increment(){
  counter++;
}

function decrement(){
  counter--;
}
```

In this example, both functions (shared) can change (mutable) the value of `counter` (state). This setup has some disadvantages, the most important of which is that it can make your code hard to follow. For example, you cannot simply look at the `increment` function in isolation: you have to keep track of every line of code that refers to `counter` and keep in mind how they can affect the function's code and vice versa. In the toy example above this is not a problem, but as your codebase grows, your code will become harder and harder to maintain.

A common approach to deal with this is to write your functions in a way that they do not depend on anything outside that function — so-called _pure_ functions. Rather than relying on the application being in a certain state, everything the function needs will have to be passed in as an argument. This results in functions that look like this:

```js
function increment(previousValue){
  return previousValue + 1;
}

function decrement(previousValue){
  return previousValue - 1;
}
```

The question then is: how we can know what the present value of the counter is, e.g. to show it to the user? You could store it in a variable which could then be updated like this:

```js
let counter = 0;
counter = increment(counter);
```

…but then we're back in the land of mutating state! If we want to show this value to the user, we still have to be aware of every line of code that references `counter` and might require updating the view.

### What can Observables do for me?

Observables provide a way to deal with changing values without having to resort to shared mutable state. Instead, you explicitly describe the way the value can change using pure functions. So to take our use case of showing the counter value to the user, we could simply subscribe to an Observable that delivers the new value of the counter as it changes, and use that to update the view.

![An application window showing a 3, the current value of the counter. An arrow pointing to the window is delivering the new values 2, 1 and 2, respectively.](/img/3-metaphors-that-show-the-power-of-the-Observable/mutation.png)

Let's say we have two buttons for incrementing and decrementing our counter, respectively:

```html
<button type="button" id="increment">Increment</button>
<button type="button" id="decrement">Decrement</button>
```

An Observable delivering the value `1` everytime the Increment button would look like this:

```js
const incrementClick$ =
  Rx.Observable.fromEvent(document.getElementById('increment'), 'click')
  .map(ev => 1);
```

Likewise for decrementing, but with the value `-1`. An Observable delivering counter values would then be constructed as such:

```js
const counter$ =
  // Create an Observable delivering 1 and -1 on
  // their respective button clicks:
  Rx.Observable.merge(incrementClick$, decrementClick$)
  // Emit a 0 before any button is clicked:
  .startWith(0)
  // Then add whatever is emitted (1, -1 or 0) to
  // whatever we had before:
  .scan((accumulator, value) => accumulator + value);
```

You can then subscribe to that Observable to update the view with the latest counter value:

```js
counter$.subscribe(counter => {
  document.getElementById('counter').innerHTML = counter.toString();
});
```

(You can view [the full working example at JSFiddle](https://jsfiddle.net/43me829w/).)

It should be noted that there are nothing but pure functions in the above example. There is no explicit variable holding the state, yet we are still able to display a dynamic counter value.

## What's next?

We've seen three different metaphors that helps us think about Observables:

- As Promises that can return multiple values
- As a Design pattern for containers that will have multiple elements, eventually
- As a way to represent mutable values without requiring shared mutable state

These metaphors provide insight into how Observables can be useful. As a next step, I'd recommend reading up on what you can do with Observables, and how they can help you structure your application. Coincidentally, I've written [another article](https://vincenttunru.com/Javascript-reactive-programming/) that deals with exactly that!

[![License](//i.creativecommons.org/l/by/4.0/80x15.png)](//creativecommons.org/licenses/by/4.0/)

_This work by [Vincent Tunru](https://vincenttunru.com/) is licensed under a [Creative Commons Attribution 4.0 International License](//creativecommons.org/licenses/by/4.0/)._


3 metaphors that show the power of the Observable



Previously, [I took a look at the current state of Javascript frameworks](https://vincenttunru.com/2016-javascript-framework-overview/). Today, I will take a look at what I think will be the next frontier of front-end programming: functional reactive programming.

## (Functional) Reactive Programming

Reactive Programming revolves around the use of a data structure representing asynchronous data, called _observables_ or _streams_. You could compare them to [Promises](http://www.html5rocks.com/en/tutorials/es6/promises/).

![A promise returning the value 3](/img/Javascript-reactive-programming/promise.png)

(Diagrams are courtesy of [RxMarbles.com](http://rxmarbles.com). The arrows represent time.)

Roughly speaking, promises represent a value that might not be known when they are first used, but might arrive any moment. Observables are similar, except that they represent the potential arrival of multiple values.

![An observable returning the values 1, 2 and 3, in that order](/img/Javascript-reactive-programming/stream.png)

Observables are great for representing related values arriving asynchronously, such as characters entered into an input field.

When we use functions that take observables as input and produce a new observable as output (i.e. [pure functions](https://en.wikipedia.org/wiki/Pure_function)), we are doing what is commonly referred to as _Functional Reactive Programming_. There are many Javascript libraries providing commonly used operators, such as [RxJS](https://github.com/Reactive-Extensions/RxJS), [Bacon.js](https://baconjs.github.io/) and [Kefir](https://rpominov.github.io/kefir/).

These can be simple operators like [`delay`](http://rxmarbles.com/#delay), that simply returns a new stream that produces the same values as the input stream, only with a slight delay.

![Example of `delay`](/img/Javascript-reactive-programming/delay.png)

The operators might use the actual values produced like [`map`](http://rxmarbles.com/#map), which returns a new stream that produces the values of the input stream after being passed through a given function.

![Example of `map`](/img/Javascript-reactive-programming/map.png)

Previous values could also be used, like in [`scan`](http://rxmarbles.com/#scan), which produces an accumulator using a given function (similar to the [`reduce`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce) function you might know already).

![Example of `scan`](/img/Javascript-reactive-programming/scan.png)

They might even combine multiple streams like [`merge`](http://rxmarbles.com/#merge), which returns a stream that produces all the values produced by its input streams.

![Example of `merge`](/img/Javascript-reactive-programming/merge.png)

One you get used to them, observables can greatly simplify dealing with asynchronous data. For example, consider a situation where you have two input fields, and you want to check whether both of them have a value. When you have observables `field1$` and `field2$` (convention is to denote observables by appending a `$`), you can use RxJS to create a stream that emits a new boolean every time the form changes validity:

```js
const isValid$ =
  Rx.Observable.combineLatest(field1$, field2$)
  .map(fields => fields.every(field => field.length > 0));
```

(You can see it in action in [this fiddle](https://jsfiddle.net/vhb4jcw9/).)

This might be difficult to parse the first time you read it, but once it clicks, working with asynchronous data becomes far easier with observables in our toolbox. Note that the above approach easily scales to however many form fields you have.

An additional benefit is that it steers you away from a whole class of bugs. To illustrate: consider trying to do the above using a more traditional approach. We would likely [create an event listener to check the validity of the form](https://jsfiddle.net/tn32yvmm/) when the user enters input:

```js
function checkValidity(){
  return document.getElementById('field1').value.length > 0 &&
         document.getElementById('field2').value.length > 0;
}
```

We wouldn't be the first to attach the event listener to the final form field and be done with it. We fill in the form, see the validity update, and conclude that it works. After deployment, however, some users will fill out the form, and then go back to the first field and clear its contents. Surprise: our form will still claim that it's valid. We forgot that the event handler also had to be attached to the other form field.

Obviously, what with you being the perfect programmer, this wouldn't happen to you. But by using observable, such errors would be really easy to spot. When your less gifted colleague adds is tasked with adding a form field, there's only one place it needs to be added: the combined form stream. It will then just work, validation included, as the data flows directly from the form fields into the validation.

There is much more to Functional Reactive Programming than this, and fully wrapping your head around it might take some time. If you're interested, you might want to try [Getting Started with RxJS](https://github.com/Reactive-Extensions/RxJS/tree/master/doc#getting-started-with-rxjs).

## FRP today

If you're as excited about FRP as I am, you're in luck: it's already gaining a lot of headway.

Consider, for example, the combination of React and Redux I touched upon in [my previous post](https://vincenttunru.com/2016-javascript-framework-overview/). With Redux, you describe how your application's state evolves in response to user actions with a function of the form `(currentState, action) => newState`. You then use React to describe what view that state should result in with a function of the form `state => view`.

Wait a minute... If you squint hard enough, that looks just like manipulating an observable with the [`scan()`](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/scan.md) and [`map()`](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/select.md) methods!

![React/Redux's architecture modelled](/img/Javascript-reactive-programming/react_architecture.png)

This is a very limited reactive system. In essence, all asynchronous input to your application will have to be converted to that one observable for actions. This can get quite awkward for asynchronous input that isn't exactly a user action, such as HTTP requests. This often leads to workarounds such as [emitting multiple actions](http://redux.js.org/docs/advanced/AsyncActions.html), e.g. one when a request is sent, and another when the response comes in. [Several libraries have arisen](https://twitter.com/dan_abramov/status/689639582120415232) that claim to make it easier, but all of them are bound to that single stream.

A Redux alternative called [MobX](https://mobxjs.github.io/mobx/) is also gaining ground, providing an implementation of observables to model component state. I haven't looked into it too deeply yet, but it appears to distinguish itself from Redux mainly by enabling components' local state to be modelled as observables as well, whereas Redux only supports a single place to hold all your application state.

On the Angular side, the developers have decided to [endorse and use RxJS](https://angular.io/docs/ts/latest/guide/server-communication.html#!#rxjs) for the major rewrite that they are currently completing. They're using it for HTTP requests, the planned router [is using it as well](http://blog.thoughtram.io/angular/2016/06/14/routing-in-angular-2-revisited.html), and you can pass them to your view templates [for more efficient rendering](http://victorsavkin.com/post/110170125256/change-detection-in-angular-2). That said, user input is still handled through callbacks, and in practise, many Angular apps will likely apply none or few transformations on their observables before passing its values back to regular callback- and promise-based code.

## A glimpse of the future: Cycle.js

The first steps toward wider adoption of FRP have been taken, and they don't seem to be stopping any day soon. So where will this bring us?

One framework that is worth looking into in this regard is [Cycle.js](http://cycle.js.org/). Cycle applications are conceptually simple: all they do is convert a series of input streams (_sources_, in Cycle terminology) to a series of output streams (_sinks_). These input streams are provided by what Cycle dubs _drivers_, and the output streams are fed back into those drivers. The values emitted to the output streams are descriptions of the [side effects](https://en.wikipedia.org/wiki/Side_effect_(computer_science)) you want to happen, and the drivers actually execute them, looping potential results back into the input streams. These drivers are usually small, separate libraries tailor-made to perform a specific side-effect in response to incoming observables, and to deliver any potential outside values through observables as well. A consequence is that the app itself is side-effect free, making it easy to reason about and easy to test.

Let's illustrate this with a very simple example application.

![](/img/Javascript-reactive-programming/cycle_lifecycle_app.png)

To be able to show something to the user, we output a description of what we want the DOM to look like onto the DOM driver's output stream. The DOM driver will then apply those changes to the DOM.

![](/img/Javascript-reactive-programming/cycle_lifecycle_render.png)

Likewise, the DOM driver also provides input streams that contains user input. Which can, in turn, be a trigger to push new DOM descriptions onto the output stream and thus update the view.

![](/img/Javascript-reactive-programming/cycle_lifecycle_input.png)

User interaction is only one type of side effect though. Another commonly used driver is the HTTP driver. By pushing values onto the output stream to the HTTP driver, apps can send HTTP requests, and the accompanying responses will be pushed onto the corresponding input stream.

![](/img/Javascript-reactive-programming/cycle_lifecycle.png)

The DOM and HTTP drivers are just the tip of the iceberg. There are plenty more drivers imaginable, such as the [history driver](https://github.com/cyclejs/history) for the browser's [History API](https://developer.mozilla.org/docs/Web/API/History_API), a [storage driver](https://github.com/cyclejs/storage) for interacting with [localStorage](https://developer.mozilla.org/docs/Web/API/Window/localStorage), [and more](https://github.com/cyclejs-community/awesome-cyclejs#drivers). Of course, you can also [write your own](http://cycle.js.org/drivers.html).

## Wrapping up

As we saw, the combination of observables and functional programming principles can greatly simplify working with asynchronicity such as often abundant in web applications, and that is still difficult to deal with in [the current crop of Javascript frameworks](https://vincenttunru.com/2016-javascript-framework-overview/). It's been getting more and more uptake as React developers slowly get familiar with a reactive programming style, and Angular developers set to have the full power of RxJS available in version 2. Cycle.js shows, however, that observables can be used far more extensively, for all that is asynchronous, in an elegant application architecture.

[![License](//i.creativecommons.org/l/by/4.0/80x15.png)](//creativecommons.org/licenses/by/4.0/)

_This work by [Vincent Tunru](https://vincenttunru.com/) is licensed under a [Creative Commons Attribution 4.0 International License](//creativecommons.org/licenses/by/4.0/)._


Up-and-coming: Reactive programming in Javascript


André Staltz recently argued that [all Javascript libraries should be authored in TypeScript](http://staltz.com/all-js-libraries-should-be-authored-in-typescript.html) -- which turned out to be rather [controversial on reddit](https://www.reddit.com/r/javascript/comments/4ankfi/all_js_libraries_should_be_authored_in_typescript/). I think that a lot of the resistance originates in the expectation that TypeScript is a completely new language that compiles to Javascript, comparable to the likes of CoffeeScript. In this post I'll try to clear up this misconception.

## It's not a different language?

Of course it _does_ differ from Javascript - not much room for nuance in short and catchy headlines. That said, you could consider the TypeScript compiler to be somewhat like an advanced Javascript linter. You can add it to your build process, and it will tell you when you're doing something in your code you probably did not mean to do. It differs from a normal linter, however, in that you add instructions to your code that help the compiler help you.

## Helping TypeScript help you

Let's say we're writing a Javascript utility library that ensures strings are at least of a certain length by padding them with spaces on the left if necessary. Let's call this utility function `leftpad`. The code might look something like this:

```javascript
function leftpad (str, len) {
  str = String(str);

  var i = -1;

  len = len - str.length;

  while (++i < len) {
    str = ' ' + str;
  }

  return str;
}
```

Typically when publishing a library, you include some documentation on how to use it. In this case, it should mention that the second argument (`len`) should be a number for this function to work.

But while properly documented code is good, self-documenting code is better. It's less work to maintain, and cannot get outdated. Since all valid Javascript is also valid TypeScript, the above code _already_ is valid TypeScript. However, we can also extend it as follows:

```typescript
function leftpad (str, len: number) {
  str = String(str);

  var i = -1;

  len = len - str.length;

  while (++i < len) {
    str = ' ' + str;
  }

  return str;
}
```

(In case it's hard to spot the difference: I added `:number` after the `len` argument.)

When you feed this code to the TypeScript compiler, it will simply strip away `:number`. Before doing that, however, it will check the rest of your code, and warn you when you call `leftpad` with something other than a number for `len`.

## How does TypeScript help your library's users?

If your library's users _also_ use TypeScript, your type annotations enable the compiler to warn them when they pass arguments of the wrong type. Note that the user can still write plain Javascript: simply feeding it to the TypeScript compiler will generate the warnings.

Furthermore, [if their editor supports reading your library's type annotations](http://www.typescriptlang.org/index.html#download-links), it can use those to provide better autocompletion features.

Even without requirements on the tools used by your users, TypeScript libraries have an advantage of being able to generate better documentation. In the past, people tried to [add type annotations using JSDoc](http://usejsdoc.org/tags-param.html):

```javascript
/**
 * …
 * @param {number} len
 * …
 */
function leftpad (str, len) {
  // …
}
```

A significant disadvantage of comments is that they can easily become outdated. With TypeScript, however, your code will fail to compile if the type annotation becomes incorrect. Thus, if you generate your documentation using something like [TypeDoc](http://typedoc.io), your documentation will always include up-to-date type information.

## So: should all Javascript libraries be authored in TypeScript?

Of course not. André, too, simply needed a catchy headline. However, if you're writing a Javascript library, already have a build pipeline, and want to provide a great experience to your library's users, seriously consider adding type annotations in your code. And since TypeScript currently has the largest following, you might as well use that to add them.

[![License](//i.creativecommons.org/l/by/4.0/80x15.png)](//creativecommons.org/licenses/by/4.0/)

_This work by [Vincent Tunru](https://vincenttunru.com/) is licensed under a [Creative Commons Attribution 4.0 International License](//creativecommons.org/licenses/by/4.0/)._


TypeScript is just Javascript

This post is for people running into the following error when running a [Protractor](https://www.protractortest.org) test for their Angular apps:

> Error: Error while waiting for Protractor to sync with the page: {}

Many search results on the internet tell you that you can solve it by adding `browser.ignoreSynchronization = true;` to your code, with [a remark like](https://stackoverflow.com/questions/20059943/running-into-error-while-waiting-for-protractor-to-sync-with-the-page-with-basic):

> the key is to browser.sleep(3000) to have each page wait until Protractor is in sync with the project

Unfortunately, this usually is not what you actually want.

## How to solve it

Most of the time, the issue will be that you've added `ng-app` to a different element than the `<body>`, which is where Protractor guesses that your Angular app is located in the page.

You can use a different element, but you will have to tell Protractor which one. You can do so by specifying a [CSS selector](https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Getting_started/Selectors) referring to the element to the `rootElement` property of your [Protractor configuration file](http://www.protractortest.org/#/api-overview#config-files). A selector that will work most of the time is

```js
  rootElement: '*[ng-app]',
```

In other words, this tells Protractor to find Angular on the element with the attribute `ng-app`.

## Why does _ignore synchronization_ work?
Protractor runs on top of [WebDriverJS](https://code.google.com/p/selenium/wiki/WebDriverJs). WebDriverJS is a Javascript interface that let's you control browsers programmatically, which is useful for e.g. automatic tests.

So then... What does Protractor add? The problem in testing Angular apps using WebDriverJS is that [Angular has its own event loop](https://docs.angularjs.org/guide/scope#integration-with-the-browser-event-loop) separate from the browser's. This means that when you execute WebDriverJS commands, Angular might still be doing its thing.

One could work around this by telling WebDriverJS to wait for an arbitrary amount of time (i.e. 3000ms in the example above) and hope that Angular has settled down during that time. Of course, that wasn't pretty. Thus, Protractor was created to synchronize your tests with Angular's event loop, by deferring running your next command until after Angular has finished processing the previous one.

This is very nice and all, but becomes problematic when you're testing a website of which some pages are written in Angular, and some pages aren't. In the latter case, no matter how long Protractor waits, there is no Angular to complete its cycle -- in which case it will terminate with the error above.

Thus, *for non-Angular pages*, you can tell Protractor _not_ to look for Angular by setting `browser.ignoreSynchronization = true` -- which in practical terms will mean that you're just using WebDriverJS.

So by adding that to your configuration when Protractor cannot find Angular on your page, you're giving up on all that makes testing Angular apps easier than plain WebDriverJS. And yes, adding `browser.sleep` after all your commands will likely work, but it's cumbersome, will break as soon as Angular takes longer than the pause you set, and makes your tests take excessively long.

## The bottom line

- Use the [rootElement](https://github.com/angular/protractor/blob/master/docs/referenceConf.js#L187) property in your Protractor configuration.
- Only use `browser.ignoreSynchronization = true` when testing a page that does not use Angular.

[![License](//i.creativecommons.org/l/by/4.0/80x15.png)](//creativecommons.org/licenses/by/4.0/)

_This work by [Vincent Tunru](https://vincenttunru.com/) is licensed under a [Creative Commons Attribution 4.0 International License](//creativecommons.org/licenses/by/4.0/)._
