Yet, Microsoft is pushing a lot on that front, particularly in Metro apps where the documentation shows JavaScript examples first. Subjectively, I’m not a big fan of the decision, because it pushes us back a few years and not simply because of the language, but because state of the full JavaScript ecosystem, compared to the .NET counterpart.

JavaScript ?

Arguably, JavaScript is not very good a parallelism (which is very different from asynchrony), mainly because it is single-threaded. There are ways around it, like using Web Workers, but this is bare-metal isolated parallelism, where everything needs to be done by hand. Maybe soon enough, we’ll end up with someone reinventing a .NET Remoting (or DCOM) look alike to address these issues.

We’re going in a multi-core CPU direction, because processors scaling up seems to have slowed down quite a bit, and that scaling out is now the trend. The immutability trend seems to rise here and there to embrace this change, C# hints at taking that route with BCL’s immutable collections, and F# has it at its core.

I foresee JavaScript lagging behind in that regard, but maybe that’s not a problem for now because it is used as an HTML back-end (and used it for this only for the time being). We still need to address a lot of concerns with raw performance, particularly when applications are not just displaying data, but are actually performing a lot of business computation on the client side.

Mixing C# and JavaScript

Fortunately, there is a very good way to do actual parallelism in Metro apps because of two things :

JavaScript can call WinMD files code

C# can expose code as WinMD files

and in C#, there is Rx.NET that excels at mixing both asynchrony and parallelism. It is very easy to share and use immutable data using Rx and its Query based programming which makes it a good fit.

Bridging RxJS and Rx.NET

Microsoft’s preferred way for exchanging messaging is through events. Even in WinMD type definitions, and pretty much all APIs in WinRT expose some sort of .NET like events.

I’m not a big fan of events, for subscription lifetime, memory management, composition, delegation, … I’m transforming them into Rx observable where ever I can, and being able to have a common way for exchanging asynchronous notifications, using multi-valued returning functions, between both worlds seems a pretty good way to go.

Both RxJS and Rx.NET seem to share the same notification grammar, meaning that it is should be very easy to map between the two.

But there is a problem with all this, being that JavaScript objects, as far as I know, cannot be marshaled through to .NET. Only WinMD exposed types, primitives and delegates can. If you try to pass a Javascript object, you’ll be greeted with a Type Mismatch exception…

Exposing an RxJS observable to Rx.NET

The idea is to be able to expose an RxJS observable to an Rx.NET C# observer, and subscribe to it.

To be able to pass this around we need to expose a way to subscribe to that observable inside JavaScript, but allow for C# to provide onNext, onError and onCompleted handlers, but also a way to dispose the created subscription :

The wrapper is created with a delegate that calls subscribe, and the observer is decomposed as three lambdas for the notifications. The subscribe delegate create a delegate that will dispose the subscription on the JavaScript side, when the C# observable will be disposed.

Also note that the class is sealed, and that the AsObservable method is internal, because it exposes .NET only types and will only be used from .NET code.

Next, C# methods can then take ObservableWrapper instances as parameters, which can be subscribed to :

Cloud

About me

My name is Jerome Laban, I am a Software Architect, C# MVP and .NET enthustiast from Montréal, QC. You will find my blog on this site, where I'm adding my thoughts on current events, or the things I'm working on, such as the Remote Control for Windows Phone.