DEV Community

rubico simplifies asynchronous code

Richard Tong on May 30, 2020

You are suddenly dropped into a world where all people write code in assembly. There is no "High Level Language", only "Assembly Language". Ther...

Read full post

MikeJMontgomery • Jul 15 '20

Hey thanks for putting this library together. It looks very promising. No pun intended. Can you advise on the use of schedulers? I want to use for making web animations, and schedulers seems to be the way to do it with lots of async. I know schedulers have been used for some RXJS animations, and Unity has a job scheduler in their Data-Oriented Design Tech Stack. Thanks

Richard Tong • Jul 15 '20

Are you open to using React?

MikeJMontgomery • Jul 16 '20

From my research, React isn't good for animation because its diffing algorithm renders in batches. You cant precisely control time like you can with Rxjs. I found your article on Stop tryin to learn Rxjs - as I'm trying to learn it now - and resonate with your thinking. I'm aiming for a stateless reactive streaming approach, using time to synchronize everything.

Richard Tong • Jul 16 '20

I was going to recommend React-controlled CSS. Could you describe your animations?

MikeJMontgomery • Jul 16 '20

I'm interested in making information visualization interfaces, kind of like what you see in sci-fi movies, like Minority Report. So this would include a combination of css animations (for elastic UI transitions) and webgl (for data visualizations, using libraries such as E-Charts). From what I can tell, using schedulers like in Rxjs would enable me to control these animations without complex state management.

Richard Tong • Jul 16 '20

Hmm I see. Actually I hope one day we can all interact with computers like in Minority Report heheh. What do you like about schedulers currently?

Daniel Richter • Jul 15 '20

I really liked that style of writing, although the first few sentences at first glance had nothing to do with javascript like the title promised the storytelling kept me reading.

But how is this different from rxjs, I feel like I could acomplish the same task with the same level of readability with rxjs, which I and probably others know well from working with angular? Is it that it's truely functional and can be used with other functional libraries like lodash/fp or ramda which rxjs cannot?

Indeed it looks promising because Promises are great and way better than callback hell but still somewhat cumbersome to work which. Recently I needed to compose sync and async functions together and ended up wrapping the sync function in Promise.resolve() and then compose them with Promise.all() which worked but looked a bit silly. How would this look like with rubico?

Richard Tong • Jul 15 '20

Here's a table from one of my archived posts that highlight some differences of rubico and rxjs

Features of RxJS	Features of rubico
special asynchronous stream datatype, the Observable - wraps built-in types for reactive operations down the line	no special data types: rubico works out of the box for built-in types; this includes async iterables
familiar design pattern: the Observer pattern - plugs into Observables	no design pattern lock-in: rubico composes your functions together. You choose the design pattern
interop with Promises	fully managed Promises: rubico stops you from having to manually resolve Promises, for example having to call `Promise.all` on an array of Promises
functional programming style via Operators + `Observable.prototype.pipe`	functional programming style by design

Roadblocks for RxJS	More Features of rubico
async iterables undermine the need for rxjs's core datatype: the Observable.	async iterables make rubico great; the async iterable is a core rubico (and JavaScript) datatype
multitude of concepts	simple foundational concept: just pipe functions together
large API surface	small, cohesive API surface
RxJS is hard to learn	rubico is easy to learn

If you had sync and async functions that you wanted to compose together in a pipe, with rubico it would like something like

pipe([
  syncFnA,
  asyncFnA,
  syncFnB,
  asyncFnB,
])(someValue) // Promise { someOutput }

rubico pipe and other functions that accept functions all handle promise resolution for you. Conversely,

pipe([
  syncFnA,
  syncFnB,
])(someValue) // someOutput

If no functions are asynchronous, you'll get a synchronous value not wrapped in a Promise

NOPR9D ☄️ • Dec 3 '20

interesting, i will test !