13 comments

[ 4.2 ms ] story [ 54.3 ms ] thread
One problem I notice with both RXJS and even this one is that in reactive programming a lot of (filter - select) is used.

Doing (filter - select) for large views seems an inefficiency - no different than the old way where we walk the DOM trees.

Incremental DOM updates cause layout thrashing which, when comlared to making a few additional passes over a set, is a couple of orders of magnitude more expensive.

The point is, walk/filter the data completely prior to updating the view.

Immutable sets may also 'seem' inefficient but compare-by-reference works a of a lot faster than change propogation with compare-by-deeply-nested-values.

In CompSci terms, multiple passes are still O(n) and the data sets aren't large enough for micro-optimizations to matter. Compared to O(holy shit) of triggering many cascading DOM updates, it's a huge improvement.

'Seems' isn't a good enough metric to justify optimization.

I am curious to know what you mean by Incremental DOM updates.

Are you talking about changing values of DOM elements,etc.

Or are you talking about destroying elements in DOM and creating new ones ?

What's are the benefits of this lib over RxJS, Redux, and Flux.

This isn't a criticism. Raher there are aready some well established FRP libs in JS. What's unique about this offering that would make users want to adopt it?

I don't think either Redux or Flux are related to FRP at all.

That said, your point still stands. RxJS has very smart people behind it and at least one big company that uses it heavily (Netflix). Its newest releases include modularized loading for smaller bundle builds.

RxJS uses the observer pattern and is not really FRP in the Haskell sense of things.