I attended Luke VanderHart’s (@levanderhart) ReactJS landscape talk.



  • your code renders virtual DOM
  • react DOM diffing (reconcilation) commits it to the real DOM efficiently
  • the real DOM generates events that are received by your code, etc.

Virtual DOM

  • React element - element node in the Virtual DOM
  • React component - custom elements


  • you write a component specification
  • instances are react elements
  • give us encapsulation and control
  • have properties (set at construction time) that specify look and behaviour
  • have state (updated by the component itself)
  • has a render method and is responsbile for rendering it’s own children
  • has a shouldComponentUpdate method that looks at properties and state and calculates whether the changes need to do anything
  • has lifecycle hooks

ReactComponent.render() vs React.render(element,container)

ReactComponent.render() - renders the virtual DOM React.render(element,container) - apply the virtual DOM to the real DOM

ClojureScipt + React

  • can be much more performant because equality checks on immutable objects are fast in ClojureScript
  • f(data) -> view - React lets you think about the world this way

Om vs Reagent vs Quiescent

See Quantum Tic Tac Toe reference implementations.


  • you want to stay clore to React’s component model
  • you want the full power of React
  • you want immutable data
  • you want the good parts of OO
    • encapsulation
    • modulatiry
    • reuse


  • how Om manages it’s underlying state (via an atom)
  • used to update the application state
  • local access to application state (for encapsulation)
  • behave as values in render context

Application State vs Component State

  • you have both
  • application state is global to your application
  • component state directly maps to React’s concept of component local state (for local transient things)
  • all updates to application state are via a cursor. E.g. (om/transact! my-cursor the-new-value) - similar to swap.


  • use it only for front-end rendering (don’t write controllers and models as Om components)
  • keep components simple (don’t use lifecycle methods or object local state unless you really have to)


  • you want things to be clean and easy (in a good way)
  • you still want the hard things to possible (but within a simpler paradigm)

Reactive atoms

  • defines it’s own atom
  • they track dereferences
  • the act of dereferences establishes a reactive link
  • you can have as many atoms as you want (atoms can be shared across components or not)


  • don’t use too many atoms - i.e. don’t use lots of top level global atoms (this ends up as being a large collection of global variables)
  • don’t deref your atoms in every component - deref in a component and pass the values to the child component (otherwise you’ll end up rerendering all components)


  • is written by the present. Disclaimer!
  • you like functional, value-oriented programming
  • you want to do your own app state management
  • component state is bad
  • all rendering is top-down


  • it’s lower level
  • choose good higher-level idioms
  • you may have to abandon it at some point


  • you can use Kioo with Om, Reagent, or Quiescent for HTML template rendering

My summary

Reagent looked the most appealing based on the material of the talk.