Why React?
1. Reuseable & Testable - React Component
2. Performance - Virtual DOM
3. Build UI with data changes over time -
One-way data flow
Challenges in Traditional Approach
1. No business logic in templates- Need more flexibility than {{#each}} and {{#if}}Poor
- Separation of Concerns
Server(Rails)
ERB template
Client (Backbone)
Handlebars template
React Components React ComponentsIsomorphic!
JSX - XML-like syntax extension to JavaScript
Note: - class is discouraged as XML attribute, use className instead- JSXTransformer to JS
Virtual DOM
● Diff - the new one from the old one
● Reconciliation - knows to only update the
changed parts
● Minimal DOM manipulation
● Put in queues, batched reads & writes
Benchmarks - @ 25 items
Key-Value Observing(Ember/Meteor)
Virtual DOM
Initial render ~ 5 ms ~ 6 ms
Warm updates ~ 2 ms ~ 2 ms
Steady state memory
(force CG)
~ 11.8 mb ~ 7.8 mb
Benchmarks - @ 10k items
KVO(Ember/Meteor)
Virtual DOM
Initial render ~ 540 ms ~ 18 ms
Warm updates ~ 215 ms ~ 4.5 ms
Steady state memory
(force CG)
~ 30 mb ~ 9 mb
Complexity (perf) comparison
KVO(Ember/Meteor)
Virtual DOM(React)
CPU(on update)
O(1) O(v)
Memory(steady state)
O(m)size of your model
O(v)size of your view
m >> v
3. Complicated two-way data binding
Challenges in Traditional Approach
model 1
model2
model3
view 2
view 3
view 1
Unidirectional Data Flow
- State is mutable vs Prop is immutable
(Idempotence)
Parent Component
Children Components
- manage the state
- Pass its state down via props
Why React?
1. Reusable & Testable - React Component
2. Performance - Virtual DOM
3. Build UI with data changes over time -
One-way data flow
Recommended