JavaScript: Just say No to “Reactive Programming”

[originally published Jan 28, 2011]

Again we have yet another (software development) term which is very “En Vogue”. And this does not bother me a bit. I stopped being distracted by marketing long time ago.

What bothers me is when these tactics start polluting into the world of software design and development where I live too. Let me give you an very long explanation. Or leave now :)

Microsoft Developers relations department has new “paradigm” to sell. As ever, few “buzz words” are used to package the sell into the right-sized quasi academic wrap-up. What is “Reactive Programming” for Microsoft people hired to keep relations with (Steve Ballmers top priority) developers , warm and fuzzy … in a nutshell?

At least to me, it seems some bright and young developer, inside Microsoft, has one day discovered the Observer/Observable pattern. Everybody around her cubicle, got very excited. And then somehow .NET library called “Rx”, was promptly released. And this “Rx” library is now being sold to Windows Phone 7 and SilverLight developers, with the help of second buzz-word: “Observer, Design pattern”. And in that part of MSFT unverse there are a LOT of MVP evangelists and their blogs. And there is very large following indeed. Here is one explanation from one of them clever blogger ones:

The premise of Reactive Programming is the Observer pattern. This involves a subject and an observer that observes the subject.

Jesse Liberty

And this is where my annoyance starts. When someone is trying to sell me “green bananas”. How and why did we came to “Reactive Programming” as the premise of the Observer pattern is beyond me? And this is the core of this article: My objection to misleading obfuscation around one indeed very simple and useful design pattern and programming idiom.

What exactly is misleading here? Well misleading is leaving out the whole history of OO patterns in general. And Observer pattern in particular. Because this is all left out from the selling pitch, general public is led to believe this is somehow a great invention of Microsoft’s uber-developers. Nobody ever said that, true, but nobody ever said anything to the contrary also. Not a single sentence mentions a seminal work on design patterns “Design patterns : elements of reusable object-oriented software”. Which I think is unforgivable obfuscation. I am sure someone will promptly prove to the contrary with a link to some obscure MVP blog. But why digging for such a necessary information which should be part of each and every general text on “Reactive Programming”?

Then (it seems to me) somebody else in Microsoft decided that “Rx.NET” is “original and awesome”, and is also ideal to be used to promote even more love that is emanating from Microsoft to all developers. As a consequence .NET evangelists are deployed to preach about “Rx.NET”, as yet another proof of the “love” of the Big Kahuna towards “it’s” good developers, who are developing by using Big Kahuna’s tools and technologies, too.

These days we indeed have a lot of (at least to me) annoying blogs full of “reactive programming” and this beautiful “silver bullet” design pattern Observer/Observable. All sounding very much like Observer pattern was invented by clever Microsoft-ees (no,no … not in early 1980’s) and like nobody ever before made any implementation worth mentioning. Pretty much the same “truth economy” approach as with MVC .NET upheaval. MVC pattern is invented in 1970’s (and used in first SmallTalk implementations). But regardless of that it is skilfully (re)packaged and made into the .NET “panacea” in 2010, for good little developers, slurping it up from evangelists and uber-developers. Who naturally are all working inside Microsoft. Because it is best for all of them, I guess.

One eye, one language. Who needs more?

The result is that we can enjoy pearls of wisdom and enlightened discoveries, form hundreds of blogs.msdn.com pages like this “pearl” for example:

As we should know, the model of the web is largely asynchronous in that we shouldn’t block for potentially long running operations. For example, we could have a large and potentially expensive collection to iterate through and process, which is in turn a blocking call. What if we could instead turn from these pull collections to a push model?

(Wysocki)

Wow ?! This guy has hit the nail on it’s head! I can see it now clearly ! Thank You, thank You … ! I must not ever again “iterate” over large collection during page load for example! How brilliant is this!


JavaScript : function call arguments as expressions


Never mind that actually almost nobody ever does this in the JavaScript DOM community. We are all doing this properly for at least last 10 years. Even before the term “AJAX” was invented. With very simple but effective, functional programming constructs based on window.setTimeout() or window.setInterval() , DOM functions. Which are in the DOM , since the day one of the DOM. And yes it is very rare to find a javascript code behind any browser page which does not start from (at least) inside window.onload, event handler function. I do not know about you, but I have never seen anything like this:

What also annoy’s me to no end, is that now we have the .NET “C# brigade” telling us how to do things properly in JavaScript. How? Microsoft has released this rather naive JavaScript implementation, done by C# programmers. And over-engineered beyond belief. Namely “Reactive Extensions for JavaScript” aka RxJS. Believe me: this is not how JavaScript is to be used to make a library or anything else by anybody who understands JavaScript. I looked into the code. It is casual beginners JavaScript. I watched interview with that bright boy author. It is not his fault and name is irrelevant, and he already left Microsoft anyway. But why asking C# developer to write a JavaScript library, in the first place? I know there are at least few very good JavaScript programmer “inside” MSFT right now, who could make this into proper and modern JavaScript, inside one day. Bertrand Le Roy, is just one of them, that springs to mind. (oops, he left too )

Never mind that the whole DOM design and implementation is based on one hierarchical structure which is observable by the script code observing dozens of events emanating from the DOM document tree. Unfortunately (until MSFT came late to the scene) nobody thought it would be “awesome” to give a new name to this old and proven paradigm.

Yes, same as you, I am wondering too, who the hell has this much enthusiasm and energy to spend it all in the wrong direction? And the very good example of “One Wrong Direction” would be Rx.NET (C#) transcoding into the RxJS. C# to JavaScript straight. That single fact on it’s own, reveals deep misunderstanding of JavaScript. And deep misunderstanding of C# too. Which OK , might not be that deep, but perhaps a simple consequence of working for MSFT.

Yesterday (somehow) I stumbled upon Jesse Liberty’s article (mainly on Windows Phone 7 + Silverlight) where he got very hot and excited on something that is called “Reactive Programming”. And yes, naturally, Jesse reveals to his fateful flock, there is .NET library for it called “Rx”. And yes, you guessed it, it is very easy to use Jesse says, especially from C#, because C# has all this brilliant features, like “lambdas”. Lambdas are invented in early 1960’s .. but never mind … let’s not disappoint just to disappoint. Although I have to say I enjoy exactly that, and I can’t explain why? And always when crushing some C# champions beliefs.

Where was I? Ok. I am still wondering what the excitement is all about when the core .NET “achievement” of this “programming paradigm” is quite easy and natural to understand and use, and to implement in any good functional language? This kind of design and programming is in regular use all the time in that “functional universe” too. Which I am sure must appear like “dark matter” universe to Jesse. I mean, I understand perfectly well why is it hard in C#, and thus looks very strange when a simple functional language solution is presented.

Let me show You some code now if I may. But in which language, in order to prove the point? The point being that it is very simple to implement “Reactive Programming” mechanisms in functional languages. Microsoft itself has released and (even more strangely ?), is actually promoting it’s own very good functional language: F#. But alas, I can not claim I am proficient in F#/ So, I will sadly revert back to JavaScript, if nobody minds too much?

Promoted as the good design and supported with unquestionable foundations in OO patterns, namely Observer/Observable, is the idea that every collection (yet another unnecessary abstraction) can be “observed”. That is: become “observable” by one or more “observers”. In the C# case “methods”. Nothing to dis-approve of, besides the MSFT sneeky “packaging” which makes it all sound like it was invented in there.

The further claim is that the immediate goody coming from that idea is that Observable can be seen as a place from where event’s are flying to observers. Thus one has a structure and workers working on that structure. All apparently working together, but in an asynchronous manner. This is all true. But please do understand, this is all already seen 30+ years ago; and is in widespread use in functional languages community since then. To you and me this is clearly Python or Erlang territory from early 1990’s. (Erlang: 1980’s)

But, OK then, I have promised I will be gentle with the C# generation. Enough of “rubbing it in”. Show us the code, now! Even if it is in the JavaScript!

What? That’s it !? Well .. Yes, 90% of it at least. I warned you: it is simple when not thinking C#. But, hey wait a minute “pardner” ! How can above minuscule peace of scripting language be a solution in providing “reactive programming” idioms? Well, it simply can and it simply is.

Beside showing us the power of functional programming, this little piece provides us with the ability to asynchronously operate on a single structure (array) by one or more callbacks. Jesse (and others) says :

The three key points to “walk away with” are:

  • Reactive Programming is a Push model rather than an “ask for” model
  • Reactive Programming follows the Observer Pattern
  • Reactive Programming shows its true value with asynchronous event handling

Here I have presented a JavaScript solution addressing all the points above.

  • Push model : callbacks (C# delegates) are called and information is “Pushed” to them.
  • The Observer Pattern : array is observable and callbacks are observers
  • Asynchronous event handling: callback are called in async manner. Events are information they are called with.

Sorry but we have “callbacks” in here as the only “fancy” term. No “observers”. And no “collections” either. Only arrays and objects, which are btw more or less the same in JavaScript. And proven as enough to do anything. With a little help of a “function” object, of course. In this solution instead of using “asObservable()” as in Rx .NET library

Instead, I have implemented a function on the Array.prototype that sort-of-a “does it all”. It simply allows every JavaScript array to dispatch asynchronous calls to callbacks. There is no need for a compiled C# mumbo-jumbo in the back that will auto-magically call the observers when things are added to, or removed from “observable collection” … Simply prepare the callback and give it to Array’s dispatch() function. As a result callback will be called asynchronously for each member of the array given. As shown in the example above.

But what about the objects, sharp C# zealot might ask? Here is the (somewhat naive ) addition for objects:

Just add the above inside the closure and enjoy.

Instant “Reactive programming” for active javascripter’s. Although it has to be said that in the JavaScript universe it is a big No-No to extend Object.prototype with anything. JavaScript purists would either implement Object.dispatch( obj, callback ) or would mandate object literals with property called “length” so that they can be also made into “observable” arrays. But that is way out of scope of this article, I am sure.

The point I am making here is that “Reactive Programming” terminology is not necessary in the JavaScript/DOM world. Folks in that world do everything that is covered in there, for at least, last 10+ years. And, equally importantly, they do it it in a much simpler but equally effective way.

Just say No to “RxJS” :)

31 thoughts on “JavaScript: Just say No to “Reactive Programming””

Comments are closed.