> Om doesn't actually enforce anything, it does provide defaults because > eventually you bottom out at "taste".
I absolutely haven’t hit the bottom yet and I really appreciate you sharing your experience. > I work with Luke and I'm a big fan of Quiescent's minimal approach. > But this is not what I consider a good rationale. A good rationale > focuses on *problems*. > > As of yet no one in this thread has pointed out that React based > solutions actually introduce new *problems*. The Flux architecture is > a solution to some of these problems. Om provides a different set of > solutions than Flux. > > Quiescent simply throws its hand up about the large set of fundamental > issues you encounter when architecting larger React programs. Can you elaborate on those problems, please? > It is absolutely inevitable that React based programs will encounter > the problems that Flux & Om attempt to address. You can either adopt a > well maintained solution or forge your own path but there no getting > around the issues. Do you see Om as universal solution? Are there any benefits using FRP + Quiescent at least for some particular kinds of projects? — Nikita -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
