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

21–30 of 40 posts

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

#21

Post by divs1210 »

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…

I'm not a core.async/UI wizard but have a look at this [0]. It's a tutorial for building a reactive ToDo List application using core.async for event processing, crate [1] for rendering and jayq [2] for DOM manipulation and ajax calls.

Interesting, though I use re-frame [3].

[0] http://rigsomelight.com/2013/07/18/clojurescript-core-async-... [1] https://github.com/ibdknox/crate [2] https://github.com/ibdknox/jayq [3] https://github.com/Day8/re-frame

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

#22

Post by mercurial »

grayrest wrote: post #12
mercurial wrote: post #9

Earlier quoted context omitted.

> 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.

I started recently, but I find them fairly decent. And there is not much to it, really.

> I didn't think it had the equvalent of Reagent's reactions until I got towards the bottom of the react-redux page

Is that the subscription mechanism? I have yet to find a use for it...

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

#23

Post by Skywing »

The Clojure, and ClojureScript, hype train is effective. I've been interested in learning Clojure for several years. Every other week, or so, I'll see a tweet or blog post that makes me want to drop JavaScript and move over to ClojureScript. The community looks like a great one to be part of, from an outsider's perspective. With that said, I've never been able to break beyond that learning curve, or have that "ah hah!" moment. I've been able to learn a lot of different languages over the years, and I so want Clojure to be one of them but it just hasn't happened for me, yet. This blog post puts my issue into words very well, it feels like I'm trying to program in mandarin and I struggle to be efficient at what seem like the most basic of tasks. A script that I could knock out in 20 minutes, with C# or JavaScript, will take me hours or days in Clojure because of the lack of muscle memory or something. My excitement always fades back into thoughts of "meh is it really worth the effort", at which point I usually just revert back to JS. :(

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

#24

Post by yrns »

Once I found flyd [0] I never looked back at any of the other streams libraries. It's very simple, easy to jump into, and doesn't have the stream/property split. There's not a lot of code, so it doesn't make debugging any harder.

Also, there is js-csp [1] if you want to use CSP without having to make the jump to ClojureScript. Works great.

[0] https://github.com/paldepind/flyd [1] https://github.com/ubolonton/js-csp

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

#25

Post by davexunit »

WorldMaker wrote: post #20
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…

>RxJS will automatically dispose/unsubscribe in composition scenarios

But it still requires manually unsubscribing from something in the first place. I just think that's the wrong approach to FRP. The graphs are actually static, but dynamic behavior is needed for developing at the REPL.

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

#26

Post by WorldMaker »

davexunit wrote: post #25
WorldMaker wrote: post #20

Earlier quoted context omitted.

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…

>RxJS will automatically dispose/unsubscribe in composition scenarios But it still requires manually unsubscribing from something in the first place. I just think that's the wrong approach to FRP. The graphs are actually static, but dynamic behavior is needed for developing at the REPL.

Thus far I've only had to manually dispose a single RxJS observable, and that turned out to lead me to a better composition strategy and I got rid of the manual dispose.

If I'm working in a REPL I set things up to "naturally complete" with some useful sample set, just as if I were working with potentially infinite enumerables. In RxJS that would typically be something like myObservable.take(5).

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

#27

Post by grayrest »

mercurial wrote: post #22
grayrest wrote: post #12

Earlier quoted context omitted.

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.

I started recently, but I find them fairly decent. And there is not much to it, really. > I didn't think it had the equvalent of Reagent's reactions until I got towards the bottom of the react-redux page Is that the subscription mechanism? I have yet to find a use for it...

> And there is not much to it, really.

The two use the same model but are organized differently so it throws me off a bit.

Re-frame chooses to hide the actual reduction step so instead of the big switch statement you have a bunch of registered event handlers, which are pure functions take the state and event and return the new state. The middleware is HoF around these so it's done per-handler as well as at the base reducer level, which turns out to be really good for code reuse.

> Is that the subscription mechanism? I have yet to find a use for it...

I think they call it selections. Reactions let you transform a normalized data model into a shape that's useful for the components. They also let you build up chains of reusable calculations/conditions to shift complex conditionals out of the components and into the model code so its co-located with the handlers, which are split up by the part of the app they work with (credentials, search, nav, etc).

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

#28

Post by Matthias247 »

My personal experience was that there is not a one-thing-fits-all solution. There are things that can be beautifully implemented with Rx, and there are other things were I found that using Promises (probably in combination with async/await) makes things clearer. My current project (which involes quite a bit of Typescript code) uses everything from Rx, Promises up to plain old node EventEmitters and streams, and I'm actually really happy with all of it.

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

#29

Post by bonobo3000 »

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…

if you don't mind me asking, how do you really learn about the different models of concurrency/parallelism well enough to be able to compare them based not only on API/programming model but also performance and low-level differences?

as an example,i want to build a web crawler. ive worked with akka actors, and that seems like a good fit because the messaging logic for scraping is simple and it gives me remote distribution for free.. but then i see all these other models and wonder - what is the difference in doing it with Rx or futures etc? is there any difference besides choice of programming model in terms of how these things actually map to low level primitives?

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

#30

Post by zackangelo »

The article mentions that async/await functionality hasn't landed in Javascript yet. I wonder if you can get the same functionality today using scala.js [0] and the scala/async [1] library.

I believe it should work. The scala/async library is just a set of macros that transform blocks of code using async/await into for comprehensions.

[0] http://www.scala-js.org [1] https://github.com/scala/async

Post reply on HN