This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-16
Channels
- # beginners (7)
- # boot (63)
- # capetown (1)
- # cider (20)
- # clara (15)
- # cljs-dev (5)
- # clojure (195)
- # clojure-austria (2)
- # clojure-dev (46)
- # clojure-dusseldorf (9)
- # clojure-germany (6)
- # clojure-greece (36)
- # clojure-italy (5)
- # clojure-nl (4)
- # clojure-russia (173)
- # clojure-sg (1)
- # clojure-spec (93)
- # clojure-uk (65)
- # clojure-ukraine (2)
- # clojured (9)
- # clojureremote (1)
- # clojurescript (52)
- # core-async (14)
- # core-logic (5)
- # cursive (21)
- # data-science (8)
- # datomic (60)
- # emacs (83)
- # jobs (9)
- # jobs-discuss (7)
- # juxt (6)
- # klipse (2)
- # leiningen (1)
- # lumo (24)
- # mount (4)
- # numerical-computing (1)
- # off-topic (18)
- # om (37)
- # om-next (5)
- # onyx (13)
- # pedestal (1)
- # perun (44)
- # proton (2)
- # rdf (3)
- # re-frame (24)
- # reagent (4)
- # remote-jobs (3)
- # spacemacs (3)
- # testing (6)
- # vim (10)
- # yada (2)
I don't mean to ask the dumbest question in the universe, but what is Om Next relative to Om?
@kamuela Both Om and OmNext use react to try an build a framework in clojurescript to shuttle data in a clean way between a central "app-state" and many components. Om, which dnolen developed first, did this with a clever "black box" type mechanism that worked great, but was hard to reason about, and which didn't work well for many edge cases. OmNext uses a much cleaner mechanism that involves every component explicitly stating a query that describes its data needs and can handle many more difficult data cases (but arguably has a steeper learning curve) Also, OmNext offers a solution for client<->server communication.