Add more guidance to README

[briancavalier]

See this comment. Can we provide a bit more guidance in the README about the characteristics that distinguish most.js, and for which use cases someone might choose to use it.

[kylecordes]

Here are some possible axes along with the person might be considering different libraries of this nature.

• Runtime performance
• Deployment code size (RxJS has challenges here, for example)
• Consistency of API, which relates to ease of learning
• Standards compliance, to the extent there are relevant or upcoming standards
• Pre-existing adoption, for example maybe you are looking closely at MotorCycle just need to be convinced that Most is a good choice for its layer in that stack
• Compatibility: does it work well with some other popular things that a person might be thinking of using when they encounter Most?
• Quality and completeness; is it a low-attention hobby project that will become obsolete before reaching stability? Is it extracted from serious production software and therefore well-proven even in the very first release? Or somewhere in between?

[texastoland]

Ping. #3 thing in computer science is picking JS libraries. From the perspective of React I see the prominent alternatives as RxJS (recently endorsed by Recompose), xstream (in Cycle.js), and Bacon.js (in Calmm). Except xstream all have been around 5+ years. Do they have philosophical differences? Like I assume Most.js is more "correct" (in the algebraic sense), RxJS has more functions, xstream is streamlined to drive Cycle.js, and Bacon.js has specialized streams called "properties" and buses". The latter 2 are hot-only, I assume Most.js handles cold observables more intuitively, and each library does the #2 hard thing differently namely naming things. What am I missing?

[briancavalier]

@texastoland Thanks for the twitter poke as well. I mentioned a few things there, which I'll add below for posterity. Primarily, though, I'll point folks to the most/core docs. @most/core is the future of mostjs, and we're trying to incorporate this kind of info into its docs.

To be up front, while I do think it's important to have more info about mostjs's philosophy, strengths/weaknesses, and use cases, I don't feel a strong need to compare mostjs to any other particular library.

Specifically, most/core aims for:

• small code size
• small-ish declarative API surface
• a minimal, modular architecture that makes it easy for the community to implement new features or integrate with other libs outside of the core.

We can certainly always do better surfacing this kind of thing in docs.