Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RxJS is great. So why have I moved on?

medium.com

Post reply on HN
Print view View original

11–20 of 40 posts

Re: RxJS is great. So why have I moved on?

#11

Post by curveship »

dustingetz wrote: post #5
Keats wrote: post #3

What do you think of something like http://mweststrate.github.io/mobservable/ ?

That looks to me, a lot more complicated than it needs to be. I think that has combined two separate things - atoms and cursors. Here they are in javascript: https://github.com/cjohansen/js-atom/blob/master/atom.js https://github.com/dustingetz/react-cursor/blob/master/src/C... Vastly less code than https://github.com/mweststrate/mobservable/tree/master/src . Cursor+Atom has nothing to do with Rx or core.async, of co…

It looks like react-cursor is 1300 loc [1], mobservable is 1900 [2]. How is that "vastly less code"?

1 - https://github.com/dustingetz/react-cursor/blob/master/dist/... 2 - https://github.com/mweststrate/mobservable/blob/master/dist/...

Re: RxJS is great. So why have I moved on?

#12

Post by grayrest »

mercurial wrote: post #9
grayrest wrote: post #8

Earlier quoted context omitted.

I wrote a 20k LoC bacon app in 2014 and had the same issue with being able to understand all the pieces individually but having trouble comprehending the whole system. I don't have non-architecture answers for how to organize code since that's pretty much the point of an architecture. Most of the application organization patterns around the React space are only ~200 lines of code and a description of how the pieces f…

> The js version is Redux but I think Redux is missing middleware as a concept. Redux totally has middleware (you actually need middleware for async actions).

Happy to hear that. I'm not actively using it and I find the the docs are fairly good but written from the implementor's perspective so they tend to bury the lede. I didn't think it had the equvalent of Reagent's reactions until I got towards the bottom of the react-redux page, which was the third or fourth time I looked at the docs. I'm not sure if I just missed it or it got added after I last looked.

Re: RxJS is great. So why have I moved on?

#13

Post by tunesmith »

bad_user wrote: post #4

Core.async is not a substitute for Rx. As a disclaimer I'm the author of an Rx-inspired library for Scala [1] and that also works for Scala.js in the browser. Shameless plug aside, Scala also has Future/Promise in its standard library and now due to macros support it got scala/async [2], a library that gives you the "await" keyword in Scala, so in Scala you also get this kind of M:N multithreading that looks like syn…

As soon as OP started talking about Go and Clojure and Core.async, I wondered if Scala.js would give him the same sort of benefits in this case as ClojureScript. But I don't know a lot about Scala.js yet and if you can actually run an actor system on the javascript frontend.

Re: RxJS is great. So why have I moved on?

#14

Post by [deleted] »

curveship wrote: post #11
dustingetz wrote: post #5

Earlier quoted context omitted.

That looks to me, a lot more complicated than it needs to be. I think that has combined two separate things - atoms and cursors. Here they are in javascript: https://github.com/cjohansen/js-atom/blob/master/atom.js https://github.com/dustingetz/react-cursor/blob/master/src/C... Vastly less code than https://github.com/mweststrate/mobservable/tree/master/src . Cursor+Atom has nothing to do with Rx or core.async, of co…

It looks like react-cursor is 1300 loc [1], mobservable is 1900 [2]. How is that "vastly less code"? 1 - https://github.com/dustingetz/react-cursor/blob/master/dist/... 2 - https://github.com/mweststrate/mobservable/blob/master/dist/...

[deleted]

Re: RxJS is great. So why have I moved on?

#15

Post by davexunit »

I don't fully understand the argument against FRP here. It seems like the author has passed on FRP in favor of coroutine-like asynchronous programming. I don't view one as replacement for the other, but as different layers of an asynchronous programming system. Coroutines are great for async and imperative tasks, while FRP is great for async and functional tasks with persistent data. My own FRP implementation [0] in Guile Scheme is built on top of a coroutine implementation [1], which in turn is built on top of Guile's first-class delimited continuations. [2]

That said, the author specifically talks about RxJs and Bacon.js, both of which have two major problems for me:

1) They don't satisfy the closure property. They both have two fundamental data types: event streams and properties. Certain combinators expect streams, and others expect properties. Compare this with API's like Elm's which just have a single type: the signal. The closure property is satisfied here and programming is much more pleasant.

2) They both deal with stream/property life cycles. Objects need to explicitly unsubscribe from other objects, and streams may have a beginning and an end (i.e. they may be marked as having no value or marked as being done producing values). I think this is a mistake that complicates the API. FRP objects should always have a value, have no notion of being done, and not require the equivalent of manual memory management to clean up. My Scheme implementation uses weak references to automatically unsubscribe signals when they are no longer referenced, which is basically only during development when changing things at the REPL. Bacon and RxJS can't do something like this because (and correct me if I'm wrong), no JS standard prior to ES6 has weak data structures. Anyway, after all the hacking, the final program has a static signal graph, just like Elm, which I think is the right way to do things.

[0] https://git.dthompson.us/sly.git/blob/HEAD:/sly/signal.scm

[1] https://git.dthompson.us/sly.git/blob/HEAD:/sly/coroutine.sc...

[2] https://www.gnu.org/software/guile/manual/html_node/Prompts....

Re: RxJS is great. So why have I moved on?

#16

Post by WorldMaker »

disantlor wrote: post #2

Discovering and mastering bacon.js/FRP completely changed the way I think about programming. It hugely increased the quality and stability of my code in ways that continue to surprise and amaze me. I cannot recommend it enough, but this article definitely has me curious about ClojureScript. In the meantime, the biggest issue I've had with bacon is figuring out what are the best practices in organizing the code. One d…

CycleJS, which is based on RxJS and smaller than most of the "full blown" frameworks and SPAs, I think has a good approach to code organization in its MVI (Model-View-Intent) documentation:

http://cycle.js.org/model-view-intent.html

For a couple of projects I'm working on I've been slowly iterating towards one sort of deeper formalization of Cycle's MVI, but I haven't published any of that work yet.

Re: RxJS is great. So why have I moved on?

#17

Post by bad_user »

tunesmith wrote: post #13
bad_user wrote: post #4

Core.async is not a substitute for Rx. As a disclaimer I'm the author of an Rx-inspired library for Scala [1] and that also works for Scala.js in the browser. Shameless plug aside, Scala also has Future/Promise in its standard library and now due to macros support it got scala/async [2], a library that gives you the "await" keyword in Scala, so in Scala you also get this kind of M:N multithreading that looks like syn…

As soon as OP started talking about Go and Clojure and Core.async, I wondered if Scala.js would give him the same sort of benefits in this case as ClojureScript. But I don't know a lot about Scala.js yet and if you can actually run an actor system on the javascript frontend.

You can run an actor system in Javascript of course and there are partial ports of Akka available, but are not meant for production use. I wouldn't use Akka in the browser though, as it's too heavy and I feel that the kind of tasks meant for Akka do not happen in the browser, though for Node.js that would be another story.

Re: RxJS is great. So why have I moved on?

#19

Post by dustingetz »

curveship wrote: post #11
dustingetz wrote: post #5

Earlier quoted context omitted.

That looks to me, a lot more complicated than it needs to be. I think that has combined two separate things - atoms and cursors. Here they are in javascript: https://github.com/cjohansen/js-atom/blob/master/atom.js https://github.com/dustingetz/react-cursor/blob/master/src/C... Vastly less code than https://github.com/mweststrate/mobservable/tree/master/src . Cursor+Atom has nothing to do with Rx or core.async, of co…

It looks like react-cursor is 1300 loc [1], mobservable is 1900 [2]. How is that "vastly less code"? 1 - https://github.com/dustingetz/react-cursor/blob/master/dist/... 2 - https://github.com/mweststrate/mobservable/blob/master/dist/...

The essential idea of a cursor can be implemented in about 10 lines, and because I actually looked through the source code of mobservable, I understand what they are essentially doing and how it requires a couple hundred lines. Since we're talking ideas here and not implementations, measuring artifacts is not helpful.

Re: RxJS is great. So why have I moved on?

#20

Post by WorldMaker »

davexunit wrote: post #15

I don't fully understand the argument against FRP here. It seems like the author has passed on FRP in favor of coroutine-like asynchronous programming. I don't view one as replacement for the other, but as different layers of an asynchronous programming system. Coroutines are great for async and imperative tasks, while FRP is great for async and functional tasks with persistent data. My own FRP implementation [0] in…

RxJS will automatically dispose/unsubscribe in composition scenarios: for instance, if you flatMap from one "underlying" observable to a sequence of observables, when you unsubscribe from the "underlying" observable it will observe any remaining (if any) hot observables that were kicked off by the flatMap.

RxJS also automatically disposes resources when an observable completes and maybe that's a part of what you are missing in the observable lifecycle and part of why you've felt that RxJS has an equivalent of "manual memory management"?

Yes, lots of streams are effectively infinite in nature, but that doesn't mean that all of them are, and a completion signal can still be useful and informative, including in lifecycle management. (It also helps keep the duality between Enumerable/Iterator worlds and Observable/Observer worlds.)

One obvious case that I see a lot in applications where finite streams/observables show up in great number is that Promise (Task/Future) is essentially an observable that produces one result and completes.

Post reply on HN