Ok, I can follow along with your examples. But I still don't get the "why" of it. Initially it kind of seems like extra mental gymnastics and wrapping your code in an extra level of abstraction. I'm not sure what the point is.

Just as some extra background, I've read the README with the parent library this comment thread is based on. I've read the linked Stack Overflow question and answer linked from it about reactive programming. I worked my way partly through the 1998 article with the bouncing kids heads. I recently did some work with Knockout for a client. I've had some exposure to reactive programming, but I still haven't had a light bulb moment that demonstrates why this style is better.

With Knockout, I find having a variable automatically update its value interesting. I like the pub/sub concept of having a variable publish its changes to any subscribers. This is useful in many frameworks including Knockout, Backbone, and more. I think in Knockout simply executing an observable inside a function makes that function subscribe to the variable is cute. But just in my opinion, it feels like to much magic and magic is fragile.

But to ask the most pertinent question, can you provide a real-world situation of at least moderate complexity where using a programming model like your "attr" is going to be better than a more traditional way of solving it?

Thanks in advance! I'm looking forward to learning something new.

We're[1] using reactive programming in our web framework to simplify UI programming. If you've done UI programming before you know it's all about event handlers. If you have multiple inputs and outputs, and a complicated graph of what inputs affect what outputs (either directly or indirectly) then it gets extremely messy to try to track all that with event handlers. Often you end up having one big function that takes all the inputs and updates all the outputs, and trigger that big function whenever any of the inputs change--but that's inefficient if not all of the outputs would have been affected by a particular input change. None of this is a problem with reactive programming (at least not the kind of RP practiced by reactor.js and our framework, as well as Meteor which is where we drew our inspiration from).

So for us the benefits boil down to 1) almost no UI event-handler boilerplate, 2) more robust because the relationships between these different components don't have to be declared separately and can't get out of sync, and 3) much easier to do partial recalculation.

See [2] for an example that is coded up in one "traditional" UI framework, one UI DSL, and one reactive UI framework. The relationships here are very simple but you can at least see how little boilerplate you need and how much more direct the relationships between the UI widgets are.

[1] http://rstudio.com/shiny, http://rstudio.github.io/shiny/tutorial [2] http://www.r-statistics.com/2012/11/comparing-shiny-with-gwi...

Thanks for reply. The power of this concept is simplicity. It's based on a very simple API: publish/subscribe.

Anything that has these methods can be easily binded to DOM and can easily interact with data structures like new-list and new-object.

Frameworks are monopolistic. They don't let you take advantage of the open source at all. You can't replace the a core mechanism or data structure of a framework but if you use something built from small independent modules, you'll be able to optimize more, create more, reuse more, extend more, fork more.

This simplicity, the two methods interface, lets you create your own data structures that can be binded to new-reactive. Since your all dependency is publish/subscribe methods, you can easily replace each part of your code if you need to move on to another direction. But frameworks will force you to use or depend on only their own abstractions. That can be very expensive and dangerous your monopolistic framework gets out of fashion or starts implementing ideas that suck.

Ok, you're just talking about plug and play. That's a separate topic about micro frameworks. What I'm asking about is a real world example where reactive programming solves a problem better than traditional techniques.

As an example, look at Promises. At first glance it seems like overkill to structure your code to return objects that get resolved later. But when you use examples of deeply nested asynchronous callback functions and how they get cleaned up with Promises, it's obvious why they are better.

What is an equivalent real-world problem where reactive programming is better?

reactive programming is nothing except abstracting more. think about how would you define a variable and bind it to HTML. Here is my reactive way;

  JAVASCRIPT

      today = attr("Thursday")

      bind('.today', today)

      after('1s', function(){
 
        attr('Friday')

      })

  HTML

      <div class="today"></div>
      

  OUTPUT

      <div class="today">Thursday</div>

  AFTER 1S

      <div class="today">Friday</div>

This is the simplicity level I would like to achieve with minimalistic and independent modules.