You are suddenly dropped into a world where all people write code in assembly.
There is no "High Level Language", only "Assembly Language". Ther...
For further actions, you may consider blocking this person and/or reporting abuse
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
Are you open to using React?
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.
I was going to recommend React-controlled CSS. Could you describe your animations?
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.
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?
I might be wrong - again I'm learning RXJS - but schedulers seem to be what can be used to control animations on the web, where lower and higher bandwidths enable different framerates. At a high level, this is what Unity is doing for their new tech stack using the jobs scheduler, so I'm following their lead. On a lower level, with RXJS, I'm following the guidance of Ben Lesh (RXJS core team member) on doing advanced animations using RXJS schedulers. All this seems to be to move away from complex stateful OOP to an event-driven time-based synchronized computing model.
If it is what works for you, I recommend you keep using it. Nevertheless, I'd be willing to support something similar in rubico, if desired. What do you mean by bandwidth?
By bandwidth Im referring to using the scheduler to adjust rendering frame rate to user device capabilities. This sort of thing is being explored in the WebXR api spec. But more broadly, it seems the use of a scheduler is needed for real-time streaming interaction. Reactive manifesto readings mentions the idea of a scheduler as central to FRP, though its pretty unexplored in the community, perhaps due to the overall barrier of jargon complexity. For more clarity on FRP, I think discrete event simulation modeling offers clarity on all the concepts. For example, all events incorporate the notion of delay, for future processing and handling in schedulers. So if you could incorporate schedulers in your library that offers a simpler approach to FRP than rxjs, I'd be interested in giving it a try.
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?
Here's a table from one of my archived posts that highlight some differences of rubico and rxjs
Promise.all
on an array of PromisesObservable.prototype.pipe
If you had sync and async functions that you wanted to compose together in a pipe, with rubico it would like something like
rubico pipe and other functions that accept functions all handle promise resolution for you. Conversely,
If no functions are asynchronous, you'll get a synchronous value not wrapped in a Promise
interesting, i will test !