On Mon, Dec 1, 2014 at 9:45 AM, Nikita Dudnik <[email protected]> wrote: > Nothing fundamentally wrong about Om. > It’s more about it enforcing an opinion and conflating the solution.
Om doesn't actually enforce anything, it does provide defaults because eventually you bottom out at "taste". > Om gives you a protocol for component’s implementation. Yes. > Om controls application state. No, there are protocols and it provides a default implementation. > Om components have local state. Again no, it provides protocols and provides a default implementation. > There is a good alternative if all you need is rendering immutable values to > HTML: > https://github.com/levand/quiescent > > It’s rationale is highly relevant to our discussion. 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. 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. David -- 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.
