 Order is important here. If the [tick] patterns had been written
 first, this would have been tried first, and preferred at each tick.
 
-For for EventStreams join patterns are indeed a generalization of zip, and zip
-is equivalent to a single-rule join pattern. The following observables have
-the same output.
-
-```js
-Bacon.zipWith(stream_a, stream_b, stream_c, combine)
-Bacon.when([stream_a, stream_b, stream_c], combine)
-```
-
-The difference is that `zip` treats Properties as EventStreams and synchronizes
-each change of property with events from other streams, while `when` just
-takes current value.
+Join patterns are indeed a generalization of zip, and zip is
+equivalent to a single-rule join pattern. The following observables
+have the same output.
+
+```js
+Bacon.zipWith(a,b,c, combine)
+Bacon.when([a,b,c], combine)
+```
 """
 
 doc.fn "Bacon.update", """

Atomic updates are limited to Properties only, meaning that simultaneous
events in EventStreams will not be recognized as simultaneous and may
cause extra transitional states to Properties. But as long as you're
just combining Properties, updates will be atomic.
"""

doc.subsection "For RxJs Users"

the stream is not a function.

The idea in using a function instead of a plain value is that the internals on Bacon.js take
advantage of [lazy evaluation](#lazy-evaluation) by deferring the evaluations of values
created by [`map`](#observable-map), [`combine`](#combining-multiple-streams-and-properties).
"""

