
From Backbone to React: Our Experience Scaling a Web Application - akbarnama
http://www.techsonian.net/2014/09/from-backbone-to-react-our-experience-scaling-a-web-application/
======
antihero
I've still yet to figure out how to easily update nested datastructures with
this immutable stuff.

Say we have a try of data, Rows -> Row{name, id}

Say we have a component, <Row row={row} />

On the Row, component, we want to update our "own" name, so with mutable
stuff, (ignoring state updates), we could set this.props.name = "potato".

Say the structure of rows was managed by a statemanager, then how do we get
that to do it?

Does rows do something like this.props.updateRowName(this.props.row.id,
newName), then the statemanager "queries" the rows and somehow replaces the
entire dataset tree with a new one where that specific row's name has been
changed?

Really fascinated to know, as I'd love to move to this model.

Om seems lovely, but I'm not comfortable enough with Clojure(script) to move
to it, let alone force it upon others in a team.

~~~
asolove
You've hit on the core idea, which is to make all data flow in one direction.
Data passes down from the state manager to individual components, and then
from those components back through the state manager to then go back and
update the UI, etc. The hypothesis is that this is better than a style where
you do pervasive two-way binding because you have a single point for managing
all your data, validations, errors, undo/redo, etc. which are hard to manage
if data changes occur at lower levels and have to be synced.

As for how you get the change request from your low-level component to that
one place, there are a few options.

\- Pass callbacks down to lower-level components in their props, as you show.

\- Pass lower-level components a data structure that knows how to update
itself within the larger data structure (a cursor, as used in Om)

\- Allow components to issue change requests that get interpreted by the state
manager. (See this article on how you can do typed change requests in Elm:
[https://gist.github.com/evancz/2b2ba366cae1887fe621](https://gist.github.com/evancz/2b2ba366cae1887fe621))

~~~
prapam2
If a user is editing a model then temporary changes would be stored in
statemanger as well? If the user then decides to cancel the changes how would
the app revert back to previous changes?

------
capkutay
That's interesting the author brought up marionette[0]. Marionette nudges
developers to make all their views modular, reusable components. Also, instead
of having a vanilla dispatcher object, they've added some more inter-app
communication protocols[1]. I've had a decent experience so far. Has anyone
else used marionette?

0: [http://marionettejs.com/](http://marionettejs.com/)

1:
[http://marionettejs.com/docs/marionette.application.html#the...](http://marionettejs.com/docs/marionette.application.html#the-
application-channel)

~~~
ben336
I've really enjoyed Marionette as a more (but still not very) opinionated
approach to Backbone development. You mentioned the messenger protocols,
definitely checkout Backbone.Radio [1], it's being created to replace Wreqr,
the current event implementation and has a much cleaner API. The plans seem to
be to bundle it with Marionette 3.0 when it gets there, but its usable with
the current version.

[1]:
[https://github.com/marionettejs/backbone.radio](https://github.com/marionettejs/backbone.radio)

~~~
thejameskyle
Backbone.Radio is awesome (Bias Disclaimer: I helped write it with James
Smith). It's definitely going to replace Wreqr in Marionette 3.0, and we'll be
integrating with it much more.

There is also a lot of other cool things coming in 3.0. We're very focused on
the architectural pieces and theres some really great ideas there. See:
[https://github.com/marionettejs/backbone.marionette/issues/1...](https://github.com/marionettejs/backbone.marionette/issues/1796)

------
cmaher
While I appreciate another look at React, I have to disagree with the
article's conclusion that React is "objectively better" than other frameworks.
The summary article of the story is basically "we completely re-architected
our application and things are better now". There's nothing in Backbone that
makes you construct the initial architecture on display, and you can use
Backbone to build the final architecture as well. So, moral of the story: re-
architecting an application you know more about than you did at the beginning
is probably a good thing.

~~~
progx
That is right.

But an architecture that is newer and learned from other architectures is
probably a good thing too.

And React / Backbone / or whatever will not be the last architecture.

------
misiti3780
This article is interesting - I have been building large-scale backbone
applications for a while and agree with a lot of this. Does anyone know of any
good examples of open-source apps built with React ?

~~~
compedit
Khan Academy uses Backbone & React, checkout out their github.

ex. [https://github.com/Khan/perseus](https://github.com/Khan/perseus)

React's blog usually has some open source projects featured as well -
facebook.github.io/react/blog

------
nchuhoai
I ask this in like every React thread that comes up:

What is everyones experience with just using Backbone Models as your data
source. We currently just pass the backbone models as props, but include a
mixin that forces re-renders by listening to the model's change event.

I can see how at very large scales you'd want to move away from that, but for
us it works great so far as we don't have to think that much about events,
components are still just simply representations of the model in a functional
way.

~~~
jonkho
This is a legit. The concept comes down to if you know the diff of your
models/collections, do you really need to do all the work that React does with
diff-ing the virtual DOM to know what to render? If you know the diffs of the
models/collections, and the logic of handling the diffs is bound via one-way
binding through the mix-in then I do believe this is efficient and viable. I
also would like others to discuss about this.

------
swalsh
I never played with React, I like the idea though... however when I looked at
the github I pretty much closed the tab after seeing the javascript directly
rendering HTML.

Does anyone know if its possible to seperate that in such a way that Angular
or knockout works?

Or am I just not "enlightened" about the way it works? Which is also certainly
possible.

~~~
rakoo
Your reaction is expected, because common experience among ui developers is
that you should separate HTML from Javascript. This is supposedly called
"separation of concerns".

I invite you to watch "Rethinking best practices", an introduction of what
React is and why it was built so:
[https://facebook.github.io/react/docs/videos.html](https://facebook.github.io/react/docs/videos.html)

You learn that separation of concerns is a good thing, but separating HTML and
Javascript is _not_ separation of concerns; it's just an arbitrary separation
of technologies.

The mindset of React is that you build independent components, where each one
contains everything to render information for the user. Whether you use 1, 2
or 3 technos (HTML+CSS+Javascript) for this component is not an issue and
there's no reason to separate them.

~~~
crimsonalucard
Although I never used React, Angular has something similar to "components"
called directives which you can configure into something similar to a
component. The one issue I have with it is that if you want CSS
compartmentalized into the directive it has to be inlined in styles attribute
of your template string.

~~~
jessaustin
Maybe I'm misunderstanding; I'm not familiar with Angular. Surely with the
right classes and ids you can put css anywhere that css can go? How could a
framework limit that? Conversely, why would this sort of framework offer any
other way to handle styles?

~~~
crimsonalucard
Its not that it's limited, there's just no feature added for styling. There's
a place to add a template string in a directive but there's no place to add a
"styling string". Typically you just put in classes and ids in your template
string that references the global css file/s. If you try to reuse the
directive in another project you have to move your css file over as well. The
only way around this, or in essence to make a truly self contained and re-
useable component is to inline the styles in the styles attribute. It gets a
bit ugly in that case.

------
jbeja
Had you check on this:

[https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)

it claims to be even more faster and maintainable than React.

~~~
ufo
mercury is (intentionally) a much smaller and less featureful library than
React. IIRC the biggest difference is that React components are stateful while
Mercury prefers components to be fully stateless, with all the state living in
the root.

------
outdooricon
Vue.js has shown to be even more performant than React:
[http://vuejs.org/perf/](http://vuejs.org/perf/)

~~~
paultannenbaum
Vue is a framework that caught my eye a while back, and it's approach seemed
like a nice compromise between backbone and angular. I haven't seen much
published about it though, does anyone have experience working on a decent
sized project with it, and if so how was the experience?

~~~
jgj
I made a file tagging system with node-webkit and Vue (+
gulp/browserify/partialify). Vue was a joy to use. Most of the complexity in
the app was dealing with sqlite, Sequelize and many-to-many relationships.
Once the data got into a Vue VM it was smooth sailing.

I did run into some performance problems (rendering huge lists into complex
tables), but I was able to iron them out for the most part. The only downside,
which is definitely not unique to Vue, was debugging--a ton of functions get
called in the Vue code when model data changes, so it can be tricky to find
the right combination of breakpoints to set to track down why what you're
expecting to happen isn't happening.

