Reagent takes pretty much exactly the opposite approach - even if the goal of 
freeing the world of everything DOM is the same :)

Here's an attempt at explaining what I mean:

In Reagent, the thing that components return isn't just syntactic sugar, it's 
the fundamental building block. The entire UI is handled as unmodified EDN 
until it absolutely has to be rendered by React. And even then the conversion 
is only one level deep. Otherwise, components happily just pass EDN around, 
without even caring that their data may later become something DOM-like. 

For example, if you have:

[:div
  [my-component
    [:span "foo"]]]

my-component is passed the span thing as a normal vector, and is free to do 
whatever it likes with it (replace every :span with :blink, translate "foo" to 
Swedish, animate it, store it somewhere else for later use, etc). If the UI 
definition is opaque (as in plain vanilla React), there's much less you can 
actually do with it (basically either render all the children, or don't).

/dan

On 6 mar 2014, at 21:01, David Nolen <[email protected]> wrote:

> To perhaps clarify a bit more, Om just considers even the React DOM to be a 
> fairly uninteresting implementation detail. This is why I've shied away from 
> any sugar around the DOM bits and haven't had any qualms about breaking away 
> from React calling conventions. In my opinion, if you're really going to do a 
> close mapping from data to UI - Kovas Boguta's declarative symbolic UI work 
> over Om is closer to the mark: 
> http://github.com/kovasb/yantra/blob/master/src/cljs/yantra/test.cljs. And 
> now with :instrument the door is open to doing a properly generic 
> Mathematica-style manipulate over this first class declarative representation 
> - the DOM is nowhere to be seen - as it should be :)
> 
> 
> On Thu, Mar 6, 2014 at 2:23 PM, Dan Holmsand <[email protected]> wrote:
> I think would be quite doable to add "advice" for Reagent components as well 
> (whether it would be useful in the context of Reagent is another question).
> 
> Anyway, I (quite predictably, I'm afraid :)) think it is also very useful to 
> be able to handle the entire UI definition as first-class data, using exactly 
> the same tools as with any other kind of data.
> 
> /dan
> 
> On 6 mar 2014, at 18:08, David Nolen <[email protected]> wrote:
> 
>> Om components cannot be constructed with the same convention as React DOM 
>> components. So we tradeoff uniformity for the capability of intercepting all 
>> component construction calls - which IMO is far more useful property for a 
>> UI toolkit. For more details - 
>> http://swannodette.github.io/2014/02/27/taking-off-the-blindfold/.
>> 
>> David
>> 
>> 
>> On Thu, Mar 6, 2014 at 12:02 PM, Jonas Enlund <[email protected]> wrote:
>> On Tuesday, March 4, 2014 9:15:09 PM UTC+2, Leon Talbot wrote:
>> > Why would I choose one or the other?
>> >
>> > Thanks!
>> 
>> If I read the sablono README[1] correctly you can't currently write an Om 
>> component and use it with sablonos hiccup syntax. Only pre-defined html tags 
>> are supported. Is this correct?
>> 
>> [1] https://github.com/r0man/sablono#html-tags
>> 
>> --
>> 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.
>> 
>> 
>> -- 
>> 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.
> 
> 
> -- 
> 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.
> 
> 
> -- 
> 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.

-- 
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.

Reply via email to