Skip to content

What is the difference between PromiseKit and RxSwift? #484

@rlam3

Description

@rlam3

What is the difference between PromiseKit and RxSwift?

Activity

nathanhosselton

nathanhosselton commented on Aug 3, 2016

@nathanhosselton
Contributor

I've not looked into ReactiveX/RxSwift, but our brief on Reactive Cocoa is probably relevant (from our docs):

Reactive Cocoa is amazing, but requires a large shift in the way you program. PromiseKit is a happier compromise between the way most people program for iOS and a pure reactive paradigm. However, reactive programming is probably the future of our art.

mxcl

mxcl commented on Aug 3, 2016

@mxcl
Owner

In RxSwift terms, Promises are a reactive pattern for asynchronicity.

PromiseKit take the good parts of reactive programming and apply them to the hardest part of pure Swift development.

RxSwift requires you to commit fully to a paradigm shift in how you program. If you do it right your code will be more robust, but you may have trouble finding other developers experienced with reactive paradigms to work on the project.

Promises make code that is pretty clear to most developers.

sahandnayebaziz

sahandnayebaziz commented on Aug 3, 2016

@sahandnayebaziz

@rlam3 at a higher level too, Promises (and PromiseKit) are just a tool you can use to write code that needs to go off and do some stuff and return at some unknown time.

Where a simple line print("hello world") executes immediately, something like fetchWeatherIn(state: California) doesn't execute immediately because it makes an HTTP request, and then waits for a response, and then parses the response, (etc, etc, etc). So if you wanted to have something happen after fetchWeatherIn was all done, you'd have to write some tricky code yourself to wait for it to finish, or keep checking to see if it's finished, or something even more clever. Promises are a well-accepted way for writing code like this, and saying "this runs, at some point it comes back when it's finished, and then ..... do the next thing!". Promises also exist in the other big languages, so learning how to use them is valuable for the world outside of Swift.

So with Promises, you can write code that "waits" for things to happen and yet is easy to read. It's possible to do everything you can do with Promises without using Promises, but you'll end up writing a lot of code to do very basic things that have nothing to do with what your app is actually trying to accomplish.

RxSwift is a much bigger idea and promotes a different way of writing apps in general. PromiseKit is great to include in any project that does asynchronous stuff (stuff that does not execute immediately), regardless of whether or not you are using RxSwift.

mxcl

mxcl commented on Aug 4, 2016

@mxcl
Owner

Closing due to stagnation.

theladyjaye

theladyjaye commented on Feb 24, 2017

@theladyjaye

This might seem like a silly thing, so I definitely want the critique if it is. Seems to me that mixing the 2 provides some benefit. I know from looking at my Rx code there tends to be a lot of chaining for different streams. Sometimes though it's nice to only surface up the:

()
.then{}
.catch{}

I know you can do the something similar with Rx and mixing things is including 2 libs that overlap in functionality. But if done in a disciplined way I think there are some benefits when viewing the code:

Rx

service.register(for: registation)
.subscribe(onNext: {
    value in
},
onError: { err in

})
.addDisposableTo(disposeBag)

Promise

service.register(for: registation)
.then(
    value -> () in
}
.catch {
    err in
}

I think the Promise handling looks cleaner at the call site than the Rx version. To be sure, behind the scenes the Promise could be totally coordinated by an Rx Pipeline and resolved or rejected via onNext onError of an Observable. Maybe I'm crazy on this but aside from the added weight to the final distribution, why else am I crazy?

Obviously one of the downfalls of this is that you would get people mixing paradigms throughout a code base, which would definitely be bad. Again though, with a little discipline I think it's a problem that can be worked around.

For things like input validation etc, Rx will really shine by being exposed at the call site and provide the reader a nice way to capture what's happing to the data. On simple async calls though, I think the Promise provides a cleaner call site implementation.

Of course I could just be holding it upside down and not even know it. I'm not SUPER 100% expert at the Rx paradigm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @mxcl@theladyjaye@sahandnayebaziz@rlam3@nathanhosselton

        Issue actions

          What is the difference between PromiseKit and RxSwift? · Issue #484 · mxcl/PromiseKit