Reactive DOM engine based on AsyncRx?

[fradav]

Do you think we can take AsyncRx directly into the DOM stuff and make our own Reactive view engine like solidjs ? Should the transpiling of rx stuff add too much overhead ?

[dbrattli]

Very interesting. I haven't seen anything like that before. I had some ideas of bringing Reaction to JS by perhaps just using RxJS instead of AsyncRx. I don't think there's much overhead with AsyncRx as WebPack will tree-shake so you only get the functions you actually use.

[fradav]

It's not about tree-shaking. I realize this is more related to how fable optimize immutable structures when transpiling to js objects. solidjs provides an immutable API over js (mutable) objects, directly wiring reactive stuff into the DOM. Doing the same sort of thing for fable should be at lower level than AsynRx.
There is two posibilities :

1. writing "a DOM expression" engine directly in fable, reimplementing basically what solidjs does but in f#/fable
2. Offering a simple but efficient Interop for solidjs (or similar UI framework)

Actually,

1. is very appealing but should be challenging and taken as a long term project (solidjs author, a seasoned js dev, confessed that it took 4 years to mature the "fine-grained reactive" paradigm into actual JS framework, so the difficulty shouldn't be underestimated)
2. should be feasible in short time frame if we focus only on the "view engine" and delegate the model handling to elmish/asyncrx like it is done actually. Moreover, solidjs offer almost the same hook API than react, so porting Fable.Reaction should be relatively straightforward. An interesting side project would to provide "switchable view engine" like Seview, in order to have the choice between different view engines like react, preact, mithril, solidjs and so on.

[fradav]

Syme, D. (2006). Initializing mutually referential abstract objects: The value recursion challenge. Electronic Notes in Theoretical Computer Science, 148(2), 3-25.
In fact it is already deep in the core, but not that much highlighted by f# community. I'm convinced there is raw untapped power to handle precisely this paradigm. The whole "reactive engine" thing is a glorified let rec 😃