
Why We Moved to React - sorcercode
https://tech.instacart.com/why-we-moved-to-react/
======
tracker1
In this way, it seems that React makes a lot of sense as a migration path.
Honestly, I find flux/redux and other unidirectional data flows are much
easier to scale than most patterns for UI development, especially class/oo
ones.

That said, React is just a part of it, and some flows are counter-intuitive in
React. This must be said because it is true... that said, I find that React is
far better, all around than most of the other options I've used, and I've been
building web apps for two decades now.

I'm currently working on supporting an Angular 1.x app, have a proof of
concept built in Redux+React, and another app I've been instructed to write in
Angular 2. I've also built a couple of SPAs using Backbone. In the end the
Redux flow has meant less code as features are added, and I'm working towards
writing my Angular 2 app with that in mind. Modern React takes a lot of
tooling setup to get started (or starting with someone's existing
boilerplate), but the shear amount of boilerplate code that you have to write
with Angular2 is just unnerving. The DI model is awkward, and I'm not enjoying
it at all...

The Redux+React proof of concept is for half the functionality of the Angular
1.x app, I'm pushing for the change in the next version... with about 1/3 the
functionality, the code is 1/10th the size, and there's a lot less
complexity... A single state tree, in the end is easier to reason with, even
if you're only looking at part of it. It's much easier to deal with, even with
scale than trying to add more message channels in an application between
components. Getting used to separating actions via a single dispatcher, and
the resulting state changes takes getting used to... but so much easier in the
end.

~~~
jsprogrammer
Do you know of a worthy Redux+React boilerplate project?

~~~
carsie
[https://github.com/GordyD/3ree](https://github.com/GordyD/3ree) is a good
starting point for React + Redux (+ RethinkDB).

~~~
tracker1
My anagram is r3k[1] (React, Redux, RethinkDB, Koa) ... Still a work in
progress. Wanting to get to the point where I have an adaptive login (local
account, google, facebook, twitter) and some public/private pages with
universal rendering. Been working on it as time permits.

[1]
[https://github.com/tracker1/r3k-example](https://github.com/tracker1/r3k-example)

------
bschwindHN
I like the idea of React. I like it even more when you take out all the frills
and boilerplate. If you haven't already, I would encourage you to give
Clojurescript and Reagent a try:

[https://reagent-project.github.io](https://reagent-project.github.io)

I decided to use it for a small client for a chat server my company runs. The
initial environment setup on OS X wasn't the smoothest, but once I got that
taken care of the actual development was very pleasing and quick. You need to
know just a few core concepts and then you can more or less replicate the
common patterns you use in React - application state, component properties,
local component state, initial values for local state, etc.

Along with that, you get immutable data structures and the benefits of the
Google Closure Compiler out of the box. Give it a shot!

~~~
dm3
If you're ready to check out Clojurescript, I strongly recommend trying out
Hoplon:

[https://github.com/hoplon/hoplon](https://github.com/hoplon/hoplon)

It requires a certain shift in thinking when coming from pretty much any other
framework. However, it avoids all of the unnecessary complexities of React by
exposing the DOM elements directly as functions. The mindshare behind it might
be low compared to Om or Reagent, but the people that are using it are pretty
active at Clojurians slack channel #hoplon and on IRC (freenode, #hoplon).
It's also FRP-based and pretty efficient. Highly recommend!

------
drdaeman
I must've done something wrong, but I haven't attained that "zen" part when I
tried to use React. On the contrary, it felt like I'm writing a giant pile of
boilerplate code "just to use React", where there shouldn't be any.

A simple, almost ToDo-like form quickly grew to 7 files, averaging 100 SLOC
each, with a air-filled boilerplate-feeling classes (yet not lacking works-by-
convention magic) that juggle data through those render -> onClick={e =>
this.onItemAdd(e)} -> onItemAdd -> addItem -> update -> UpdatePromise ->
handleUpdateItems -> render loops.

Sure, everything's logical but that feels like I'm deeply stuck in the wheel
of Samsara, writing code for its own sake and not attaining any Enlightenment.
;)

~~~
dominotw
> render -> onClick={e => this.onItemAdd(e)} -> onItemAdd -> addItem -> update
> -> UpdatePromise -> handleUpdateItems -> render loops

you seem to have fallen prey to overengineered examples.

that example should be

>> render -> onClick={e => this.onItemAdd(e)}

thats it, data change should re render the tree.

~~~
drdaeman
Well, maybe. But I also wanted it to sync up with the server too (onItemAdd
actually updated component's own state with extra "save in progress" flag,
handleUpdateItems would clear it later).

~~~
dominotw
well then you are doing much more than

    
    
      A simple, almost ToDo-like
    

You can do things like writing sever-syced component,mixin ect .

------
ridiculous_fish
React has been quite nice, and very fast to work on. But there's one aspect
that's concerning.

You have state and props, and the React tree diffing algorithm attempts to
make some minimal set of changes that preserves state. However this algorithm
is a heuristic, and so it's possible to hit a case where your component gets a
different component's state.

For example, say there's a text field which has keyboard focus. Another text
field is added above it: the keyboard focus should stay in the bottom text
field. But React has no notion of identity and doesn't know whether the top or
bottom text field is new. All it sees is a diff from one text field to two,
and who knows which one will get focus!

React's answer to this is to introduce identity by assigning each component a
key, and that works. But this is reactive: I notice a bug, and fix that case
by assigning a key, but still most elements do not have a key and it is not
reasonable to add one. I'm stuck hoping that the opaque tree-diffing heuristic
is correct enough for my case.

How do other React users handle this? How do you go from "seems to work" to "I
am certain React's tree diff will assign the right state to the right
components in all cases?"

~~~
dominic_cocch
This should really only be an issue when the children of an element are all
the same type of element and are at the same depth level. For example, this is
very common for li elements in a ul element.

We try to keep the structure of the html so that wrappers generally keep
different UI components separate from each other. In other cases, like in the
example in the blog post, we just use the index from the .map() loop to add a
key to every element we know will need one. React should also warn you when
this is an issue.

~~~
ash
> we just use the index from the .map() loop to add a key to every element

Doing this could hide weird bugs. Let's say we render a list of posts with
"remove" button for each one. The user clicks on "remove" button, we modify
the underlying this.state.posts. And on next re-render removed post key would
be assigned to the next post! The next post could inherit just-deleted post
handlers, for example.

It's much better to use unique keys like database ids.

~~~
dominic_cocch
Great point. This has to be the funniest and most confusing bug when you first
encounter it!

If your list is totally static, an index will do the job. However, we usually
end up appending something like an id from the db since almost nothing on
Instacart is static.

------
jorgecurio
one of the biggest changes was accepting that React is different from old way
of doing things like with jquery.

I used jQuery to build 4k loc applications. It's a fucking blast when you are
just wiring up the template and watching the UI come alive...to me that was
the power of jQuery. No need to think, just go and make everything stick like
glue.

Angular.js was also right in that regard....add annotation to HTML. but this
shit doesn't scale when application grows.

I'm still frustrated that I can't write shit in jQuery anymore because HN have
collectively ruled against it and I guess at 4k loc it has become very hairy.

But I still argue if your needs are pretty small, like make a small widget app
that has two buttons and makes ajax request to an endpoint, no other frontend
framework can even touch jQuery in this territory....

In fact the overhead of having to think about states, structures, components
organized in hierarchy...this shit adds to my stress and I can't experiment
fast...but then also was the stress from not being able to add new features
because the jQuery app grew in complexity....

difficult times gentlemen difficult times. I've been holding on to jQuery
since 2009...maybe it's time to venture out entirely with React.js? Or should
I crawl back to the comfortable cave that is jQuery where I can make
_anything_ very quickly.

~~~
alien3d
KISS. Keep it simple and straightforward. Once been extjs then come to weird
mvc pragma come become line of code(LOC) become triple larger. Then i moved to
jquery, it breeze to code.Have try learn new tech like angular,backbone but
still fall back to normal javascript and jquery.Maybe i'm to old to learn new
tech. :(

~~~
pkrumins
You're not too old. The new frameworks just don't make much sense. You don't
need any of them to write applications. They just bloat everything, create
additional dependencies and don't help you much. You spend all your time
figuring out how to do things limited by frameworks's scope rather than
getting things done. You can generally write 90% of what you'll need from any
framework in 90 lines of code and create nice abstractions yourself. Don't use
frameworks and don't let the peer pressure get you sucked into this nightmare
what frameworks are.

------
philmander
It's clear why using React in your Backbone views is beneficial, but I'd be
genuinely interested to know what tangible benefit moving the models (and,
thus, entirely from Backbone I guess) to flux/redux etc brings you, besides
just keeping up with the latest conventions.

~~~
dominic_cocch
The backbone model api was made with totally mutable data in mind. React, on
the other hand, only works well with immutable props and some mutable state in
the top levels of components. That's our first issue, for sure.

Backbone also has a dependency on jQuery, which isn't very useful in React
apps since mutatuing the DOM (one of jQuery's main purposes) is a no no. So
most of the Backbone library isn't very useful to us anymore. I do still
really enjoy the backbone way of fetching and saving models, especially in a
Rails context. But I think we can get those features in other ways.

~~~
pramodliv1
I use React and Backbone too. Here's the source code:
[https://github.com/pixyj/feel/tree/master/client/app](https://github.com/pixyj/feel/tree/master/client/app)

I use jQuery for animations and also for non-crud pixel-level DOM
manipulations as in the graph shown in the home page:
[https://conceptcoaster.com/course/python-
tutorial/](https://conceptcoaster.com/course/python-tutorial/) In the graph, I
need to dynamically calculate height of certain elements based on the height
of others. The height cannot be predicted in advance. Can React work for such
cases too?

~~~
ConAntonakos
Really like the app. I like the top progress bar loading animation. I'm
assuming this is the relevant file?
[https://github.com/pixyj/feel/blob/master/client/app/base/js...](https://github.com/pixyj/feel/blob/master/client/app/base/js/top-
progress-bar.js)

Trying to figure out a way to implement this with React + React Router...

~~~
pramodliv1
Thank you! Yes, that's right! I'm not familiar with React Router yet though :(

------
phat4life
Personally, I prefer more web-component like frameworks. Vue.js is more
usable, and easier to understand than React, but stuff like React Native is
why React.js is worth learning.

I strongly dislike the JSX syntax as well. Its messy, and difficult to read. I
would like my to write my components as dom nodes, like with Vue.js, Riot. The
way that react.js handles css, is also messy. I would rather just defined a
<style> tag like in Vue.js.

~~~
mercurial
> I strongly dislike the JSX syntax as well. Its messy, and difficult to read.

I've read quite a few criticism of JSX but "difficult to read" is a first.
It's not significantly different than any templating system out there (eg,
ERB). It's just XML with interpolated code, what's confusing about it?

~~~
tragic
Well, now.

Firstly: context switching is an inevitable inconvenience, but in JSX you're
context-switching _line by line_ between two radically different syntaxes.

Secondly: switching into _what_? It's not HTML (Angular templates, for
instance, are not going to win any beauty contests, but they are technically
valid HTML). XML? No, not that either. So ... something that looks kinda like
HTML/XML, but which isn't really. It's perfectly legitimate to sacrifice
aesthetic elegance for the sake of adhering to well-understood standards. But
if you're _not_ going to adhere to that, then why pick something that is
merely similarly ugly? I don't get it.

Thirdly: templating/view layers always face a trade-off - either they are
embedded within the host language, or they use an external DSL which is
parsed/compiled by the host language. The trade-off is: better change of
'correctness' and cleaner interop with the rest of the language if it's an
internal DSL; on the other hand, with eternal DSLs, at least the possibility
that non-engineers will be able to work on things. With JSX, you end up
grafting an 'internal' DSL simply by adding a whole pile of syntax to the core
language. You don't have the advantages of the separate template language, and
you lose _some_ of the advantages of the other by requiring a whole pile of
extra tools. JSX is an attempt _not_ to choose, in a situation where
compromise is basically impossible. Hence its extreme awkwardness - just like
E4X before it.

React has done some good things: it's put performance on everyone's agenda in
a big way (Hallelujah!), and it has acted as a testbed for interesting front-
end architectures. JSX, however, I feel is a serious mistake. I actually
_enjoy_ writing React code through Reagent or similar, but in native JS and
especially JSX, it just _feels_ awful. I just don't want that in my editor
window.

~~~
spion
> It's perfectly legitimate to sacrifice aesthetic elegance for the sake of
> adhering to well-understood standards.

React goes out of its way to make it look like you're working with the real
DOM, but in a different way. Take the event system for example:
[https://facebook.github.io/react/docs/events.html](https://facebook.github.io/react/docs/events.html)

In that sense its even closer to the standards than Angular is - it still uses
events instead of databinding.

> the possibility that non-engineers will be able to work on things

Its highly suspicious that it was ever possible because of tight coupling
between template and its data. Just look at an Angular controller and view.
Tell me that two different people can work on that in parallel, one on the JS
part, the other on the HTML part. Its impossible.

At best you can have a designer work on the HTML part first, then a programmer
can import it (a fancy word for copy paste + add all the dynamic behaviour),
then perhaps the designer can do incremental design-related fixes but might
need to consult the programmer regarding the data. The programmer can also do
HTML fixes but might need to consult the designer regarding how they would
look.

Lets see if that workflow works with JSX:

    
    
      * copy-paste: check
      * add dynamic behaviour: check.
      * tweak and maintain the design: provisionary check:
    

If the designer really can't handle the surrounding JS, (although given what
you are saying it sounds more like the programmer cannot handle the sprinkled
HTML), you can move the render function in a separate file:

    
    
      module.exports = function() { return (
        // JSX goes here.
      ); };
    

Problem solved.

Anyways, this is just staying inside the box with old aesthetic sensibilities
developed from a bygone dark ages era. React is a peek at what HTML and JS
could be, if only they actually worked together. Its also a snide remark *
implying: "Hey WWW, you're doing a crappy job at supporting web applications.
Let me show you how its done"

* not saying its intentionally snide, just that it might come off that way

~~~
mbrock
Watch out for space between words in your designer's copy disappearing though,
because React chose to deviate from the HTML whitespace semantics.

    
    
        <p>
          Hello and welcome to our fancy site, where you
          can do all kinds of cool things.
        </p>
    

In JSX, that text will become "...where youcan do all..." and the recommended
solution is to type

    
    
        {' '}
    

to insert a literal whitespace. [Edit: See spicyj's response; I was wrong
about this, but the behavior is different from HTML in other cases.]

That, plus the way JSX confuses the hell out of language modes—Emacs, GitHub's
rendering—makes me want to stop using JSX. I just don't enjoy using it, and I
really do enjoy creating DOM elements with normal JavaScript syntax.

But like so many other things people argue about... it's just preference, and
ultimately pretty insignificant.

~~~
raquo
This exists for a reason. If you do this in HTML:

    
    
        <li>Hello</li>
        <li>World</li>
        <li>!!!</li>
    

You now have text nodes containing a space in between the <li> elements. These
will subtly affect how the elements are rendered. In HTML, if you want to get
rid of those text nodes, you have to write the elements on one line:

    
    
        <li>Hello</li><li>World</li><li>!!!</li>
    

Or use float: left|right styles to push the text nodes out of the way. Both
are ugly solutions. With JSX, I don't have to think about that.

I've never even ran into your issue because I use React for web app
development and so use translation strings (i.e. function calls) for pretty
much all user-visible text. If you ask me, the trade-off React chooses here is
adequate.

~~~
mbrock
Sure. I'm mostly just saying you can't take HTML and cut & paste it into your
JavaScript file.

------
pmlnr
[https://www.instacart.com/](https://www.instacart.com/) -> among the JS
loaded: static-react-base-{id}.js 273KB. It it just me thinking that ~300KB of
code, about to be evaluated in the browser is a bad idea?

~~~
GoToRO
I feel the same, but people use it because they can deliver things faster (and
get the money sooner). Sure, after that the client will maybe get complaints
about website crashing user's mobile browser on cheap phones but those phones
will get replaced soon (5 years?) so the problem will fix itself.

On a second thought, how do you access the Contact form on a website you can't
even load? :)

------
Kiro
I'm interested in learning more about reusability. One problem I have with
React is that I've made this component called Product and then I need another
Product component but in a different context, for example in a listing with a
thumbnail. Much like the carrot example. How do you approach this exactly?
Shouldn't it be based on the same component somehow?

~~~
astazangasta
I think the vague answer is 'use mixins', but they are generally unsatisfying.
One hopes that using ES6 classes to define react components this way would
allow proper inheritance, but the whole ES6 thing is a mess that breaks a
bunch of other things (notably autobinding this). Upshot is my code remains
repetitive.

Where possible you can use composability, extracting common function into a
subcomponent, but this doesn't always make for neater code.

~~~
wereHamster
Ugh no. Please don't use mixins or inheritance. Composition is the way to go.

[https://en.wikipedia.org/wiki/Composition_over_inheritance](https://en.wikipedia.org/wiki/Composition_over_inheritance)

~~~
Kiro
Do you have any example React code using composition?

~~~
wereHamster
Same way you compose functions or HTML elements.

Functions:

    
    
        add(1,multiply(2,3))
    

HTML:

    
    
        <div>foo <span>bar</span> </div>
    

React:

    
    
        <Container> <Header>foo</Header> <p>content</p> </Container>

~~~
Bahamut
To be pedantic, that is not quite composition - I've made this exact mistake
before too. Composition is where you have a function f o g (o being the
traditional mathematical notation for composition), where (f o g)(a) = b
satisfies g(f(a)) = b.

Composition is a useful tool, and so is writing functions like this, but they
are two different ideas.

------
ezequiel-garzon
As I go over the impressive list of big sites adopting React [1] I feel there
must be something wrong with this current survey [2], which states a mere 67
of the top 10000 sites are using it. Any insight will be welcome.

[1] [https://github.com/facebook/react/wiki/Sites-Using-
React](https://github.com/facebook/react/wiki/Sites-Using-React)

[2] [http://trends.builtwith.com/javascript/javascript-
library](http://trends.builtwith.com/javascript/javascript-library)

~~~
chrischen
While easier than before to do server side rendering, it's still non trivial
to do a react app that preserves SEO and renders on the server if your app
isn't already a nodejs app.

It would require running either V8 to render on the server behind whatever
language your backend is already written in, or calling node to serve your
backend, relegating your existing backend to an API (and tying the backend
rendering to your API along with the Frontend to use the same API isn't simple
either).

~~~
girvo
Indeed. We had to tackle this for Expedia's Viewfinder[0] (which was done by
utilising nodejs as the server), and we're tackling it again for another
project that has it's server-side rendering done in PHP. Interestingly, we are
leveraging the v8js PHP plugin to be able to execute JS from inside a PHP
context, sharing variables between them as needed. Though I'm not convinced
its the perfect way of tackling this problem, there's still a lot of quirks
and bugs.

[0] [https://www.expedia.com/pictures](https://www.expedia.com/pictures)

~~~
chrischen
I looked into another alternative: dnode, although I think I'll still stick
with V8js for now. I don't think it's avoidable unless you want to switch to a
Nodejs API server as well.

------
b34r
The forceUpdate API is murderous for performance, since it causes the entire
tree to do a vdom rerender, bypassing shouldComponentUpdate() checks. Should
really try and find another way to trigger a re-render.

~~~
dominic_cocch
Definitely agree. In our real code we're much more sensitive of performance.
This was just a quick way to show a simple way Backbone can be used with
React.

I think it'd be interesting for us to do another post in the future about how
we measure and improve performance within our React apps. There aren't a ton
of articles about this with relation to Bakcbone, it seems.

Thanks for giving it a read!

~~~
rgbrgb
Would definitely like to read that one. We have a backbone/react app and
generally use your example pattern, but I can see how it would take a toll on
performance at some point. What's the general pattern you use if not
forceUpdate? I suppose you could use something like @setState(model: model)
but you still have mutable models to deal with in shouldComponentUpdate. Have
you guys come up with a good way to reconcile backbone's tendency towards
mutation and the performance benefits of immutable props?

~~~
dominic_cocch
Yes and no, really. We mostly keep our backbone models as props and keep them
immutable by pure convention. You really could just call set() on one of them
and cause some problems. This isn't great long term, of course. Code reviews
and code style guides help here for now.

We've also at times converted backbone models to simple objects at the parent
level and passed them down that way. Keeps things simpler, but we lose some of
the niceties of the backbone model api. Once the models are objects, you can
use componentShouldUpdate pretty defensively if you need.

We've also used throttled and debounced functions for anything which gets hit
very heavily.

------
Aleman360
As a C++/XAML mobile app dev, I'm baffled by how a common UI like this (lots
of lists?) requires such a deep dive.

~~~
badsha
Saw your comment in another post about how the Start Menu is really just an
XAML app. I was wondering, how did you guys make it transparent and blur? I
have been trying to figure that out for the past 2 days and have had no
success yet.

------
kzhahou
Dominic, when did you start rolling out this change, and how long have
significant parts of production been on it?

I'd be very interested in a follow-up in a year, once it's grown to the size
of the backbone app it's replacing, and been battle-tested (in prod and in
development)

~~~
dominic_cocch
We've slowly been growing our React presence on the site for almost a year
now. At this point, we're fairly close to the size of the original Backbone
app as far as views are concerned.

We're still somewhat tangled in with Backbone, but it's been a great success
internally. Performance-wise, development speed-wise and also developer
happiness-wise we haven't hit too many snags.

------
aioprisan
I was checking out their careers page and they're looking for a senior
engineer to lead 5 engineers, but they require masters degrees? Really?
Newsflash: a one year degree isn't what's needed to be a successful team lead.

~~~
jackdempsey
The next bullet point:

"Employer will also accept a Bachelor’s degree or foreign equivalent in
Computer Science, Computer Engineering, Information Technology, or related
technical field and 5 years of progressive, post-baccalaureate experience in a
related field."

We don't require a Masters. Some engineers have one (or PhD even) but that's
much less important than being a great engineer.

~~~
aioprisan
You missed my point entirely. A one year degree isn't the equivalent of 5
years of post-bac experience in the field, and that is your first bullet
point, the "expected" and most discouraging one - folks stop reading after
that. That some folks have masters or PhD degrees is great, but shouldn't be
an expectation for a team lead role. I'm sure you'll have issues trying to
attract talent with that kind of messaging and expectations.

------
capkutay
> As an experiment, we tried writing a separate app to try out the popular
> Flux library.

Is there one 'popular Flux library'? Perhaps they meant redux? No other
mention of it in the article.

~~~
phereford
There are lots of popular Flux libraries.

[https://github.com/acdlite/flummox](https://github.com/acdlite/flummox)

[https://facebook.github.io/flux/](https://facebook.github.io/flux/)

[https://github.com/reflux/refluxjs](https://github.com/reflux/refluxjs)

[http://fluxxor.com/](http://fluxxor.com/)

[https://github.com/reactjs/redux](https://github.com/reactjs/redux)

Each of these appear popular in their own right. Given they mentioned Flux, it
probably is the actual Flux library.

~~~
dominic_cocch
Yep, it was the actual Flux library. However, we're not totally settled on
that choice just yet.

~~~
phereford
Awesome! I had chosen flux for one project I was on and really enjoyed it!

Thanks for the post!

------
partycoder
Saying CoffeeScript is simpler than JavaScript is the same as saying: I am
going to make traffic simpler by removing lane delimiters, traffic signaling,
lights, street names. You end up with a "simpler" language, but it is also
less safe to use. Python will throw you an error with inconsistent
indentation, but that's not the case in CoffeeScript. So any little messing
with the whitespace, which is impossible to infer automatically, and you have
a bug.

Then, you can massively auto-format JavaScript, use great tools that inference
type information from documentation, etc... but with VomitScript, you are
pretty much on your own. In fact using an advanced editor and nano will
probably make no difference.

"Duh but I want to type less"... NOBODOY CARES about you typing less. If you
care about typing less use templates in your editor and autocomplete.

------
carsongross
Peguy's quote:

 _" And it will never be known what acts of cowardice have been motivated by
the fear of looking insufficiently progressive."_

becomes more and more relevant to the tech world.

We are managing a few lists. How is this so complicated?

~~~
rgbrgb
If you have a less complicated way to build a big beautiful app like
instacart, I'm all ears (that's why I'm reading this). Or are you just saying
we should give users a CLI and be done with it?

~~~
carsongross
[http://intercoolerjs.org](http://intercoolerjs.org)

~~~
rgbrgb
Nice, looks very simple. But I don't see how it would make it simpler to build
an app like instacart. Try instacart, the app is borderline magical. I've
never seen a bug with their cart or the awesome realtime-multiplayer shopping.
I'm guessing if you tried to build an experience like that with just
intercooler, your codebase would end up being significantly more complex.

------
ausjke
for newcomers is it too hard to find all the pieces that need to work with
React to make a final product? I just started with Angularjs 1.x, while it has
its faults I found it's easier to get started.

maybe React is better suited for the experienced who knows how to bootstrap
all the components? I'm interested in learning React _after_ I get more
familiar with the javascript-ecosystem, and it seems to start with angularjs
will be a good approach?

------
ConAntonakos
What is Instacart using for its routing logic?

~~~
dominic_cocch
For now we use Rails on the server and a single backbone router for the the
client side. This isn't how we want it stay. :)

We do have a couple side apps internally using React Router. We've liked it so
far, but it's a pretty basic implementation.

------
kensign
No matter how I try to accept it, it is a really bad idea to embed views into
business logic. You have no clear separation of concerns and this can create a
lot of headaches as the sophistication of the application grows. Instacart is
a great product, but it has a lot of room to grow still. What happens when you
get into some deeper aspects of UX? I presume you do your own UX research and
these highly segmented views are going to be a pain to manage.

You'll also need to worry about how you run BDD tests for specifications and
scenarios. How can this be achieved in React as you write test suites for user
stories and non-UI acceptance tests? How will this impact your continuous
delivery/integration systems as well? You'll have to rewrite all your test
suites into Jest, right?

There are architectural trade-offs for sure. Can you definitely say you've
performed a thorough analysis before making this decision? There's a
difference between having a clear strategy to move from one tech to another
and knowing that the migration will not just bury you into a deeper whole than
the one you think you're escaping.

[http://aurelia.io/](http://aurelia.io/) is based on webcomponents (MVVM),
ES6, and current web standards. It's amazingly simple and good architects can
use their own structural patterns to create code that can actually scale with
the product. DDD and BDD methodologies mesh perfectly into the development
workflow, especially with Agile product development.

I wish you well, but I really think React is a short sell with dire
consequences.

~~~
madeofpalk
What you see mixed in with JSX is view logic, not business logic. I see the
same thing in the Aurelia examples

    
    
        <h1>${router.title}</h1>
        <ul class="nav navbar-nav">
          <li repeat.for="row of router.navigation" class="${row.isActive ? 'active' : ''}">
            <a href.bind="row.href">${row.title}</a>
          </li>
        </ul>
    

Which is almost identical in JSX:

    
    
        <h1>{router.title}</h1>
        <ul className="nav navbar-nav">
          {router.navigation.map(row => (
            <li className={row.isActive ? 'active' : ''}>
              <a href={row.href}>{row.title}</a>
            </li>
          ))}
        </ul>
    

For loops and map functions aren't necessarily business logic, but they are
view logic (and you'll see them in any sort of tempting or view system). React
actually makes it very bad to include any substantial business logic into your
templates as the render function is called many many times potentially
whenever your data changes, so you want to include very minimal stuff in
there.

> You'll also need to worry about how you run BDD tests for specifications and
> scenarios. How can this be achieved in React as you write test suites for
> user stories and non-UI acceptance tests? How will this impact your
> continuous delivery/integration systems as well? You'll have to rewrite all
> your test suites into Jest, right?

Exactly the same! At the end of the day, React is just Javascript. You still
have your models in their own classes or functions, with your own API helper
methods. How you write that doesn't change - no need for Jest. We're testing
our entire app - including templates/views - using Mocha (and we're about to
run tests in Karma in real browsers pretty soon).

~~~
kensign
The JSX is not the same as it is encapsulated in the render() method withing
the JS file. This is the whole point of why this implementation is not a
separation of concerns. The view is essentially embedded in the controller in
order to simplify how a controller passes scope to the view.

This isn't the first time people have fallen prey to embedding HTML as a
string into JS to write the DOM. 5/10/15 years ago, if we saw this, devs would
just shake our heads. If anything React is an old hack, an anti-pattern
brought forward again.

I misspoke about views in business logic, as you said, it is the controller
logic, which should be decoupled from the view itself as well. The naive
example of converting a webcomponent to a JSX component may look similar, but
more complex components will only require greater complexity for the render()
method to handle.

I understand your rationalization, but the crux of the arguments here are
concerned with the anti-pattern React introduces and why developers who've
come across this before have seen this as technical debt. The arguments for
React are a matter of opinion, wherein the arguments against it are based on
the practical principles for programming UIs, principles have been forged to
be tried and true since the 70's.

I personally favor standards, such as webcomponents and OO programming for
modules. I understand that this may not seem popular at this point and time,
but 20 years of dev experience has taught me otherwise.

~~~
madeofpalk
> The JSX is not the same as it is encapsulated in the render() method withing
> the JS file.

I'm not quite sure what you mean by this.

Anyway, I can't help but think that the distaste of the way React does stuff
is due to first impressions and not actually using it in a meaningful way. I
get where you're coming from - when I first saw React I thought the JSX was a
terrible idea, raising many of the same concerns you have. I'm not sure what
your experience is with it, but I definitely didn't like the syntax at first.
Also, although we are talking about react specifically, usually you'll be
using other libraries along side to it handle the other non-viewy type stuff.

But then I actually used it, and lead a reasonably sized team to create a non-
trivial web app with it. People who have been programming since before I was
born, and people who learnt React for this project. Not all of them love it,
but everyone is very productive with it and we all see the benefits it brings
and we haven't been burned by some 'anti pattern'.

Traditional programming common sense still applies here: bad developers are
going to write bad code. When something gets too large, take another look at
the problem and perhaps break it down into sub functions. If you're repeating
thinks, create a common module for it. Nothing really revolutionary about
that.

I'm not convinced there's no one working on or with React who's seen the pain
of poor separation of concerns. There are lots of smart people working on
React, both at Facebook and in the community, who are just as aware of the
programming. "principles [that] have been forged to be tried and true since
the 70's"

Additionally, the Aurelis example we both mentioned isn't a webcompoent. It's
as much of a web standard as React is.

~~~
kensign
What I meant by the difference between the HTML in an Aurelia template and JSX
is that the React component's markup has to be inside the its respective
controller's render() method. That's the main issue.

I am not arguing about JSX syntax, but rather the principle behind it. How
would I safely refactor a css class across hundreds of components in a safe
way and not by find/replace? An IDE such as WebStorm actually tracks CSS
classes by their reference in other HTML/CSS files and this includes CSS
preprocessors. I know it's a safe bet to run the renaming, although I always
preview the changes beforehand.

I'm a reasonable developer, but this is an anti-pattern that has been eschewed
voraciously over the years. Your appeal to the intelligence of React's devs is
an informal fallacy and doesn't change this fact.

I am not trying to be dogmatic here. Yes, breaking the 'rules' when it is
warranted is perfectly fine. My argument here is that in this case, this anti-
pattern isn't warranted and will be very expensive work with as the product
grows. I am advocating standards and best practices. React sidesteps both for
an unnecessary reason. It works, it's pretty awesome how fast it is, but it
cannot scale with a product's lifecycle.

Web components keep the HTML in the DOM and are being officially adopted as a
standard. They can be polyfilled with a lib from
[http://webcomponents.org/](http://webcomponents.org/). Aurelia, although it
is a framework, is extremely lightweight and greatly simplifies the use of web
components. Polymer isn't as elegant, but it clearly demonstrates the idea of
dynamic reuse. There are other alternative libs as well.

As an aside, ES6 is now standard and with Babel. Javascript is now closer to
ECMA, as it was intended to be.

I think I've made my argument as clear as I can, thank you for a great (and
polite) discussion. It has actually been helpful for me to voice my opinion
and get a better understanding of the support behind React. Again, it's
impressive how fast it is over other libs such as jQuery, but jQuery's always
been bloated and is near the end of its usefulness. However that point doesn't
detract from the very cool things that React can do in the right hands. I wish
I could bet on it, but to me it's the wrong horse in the race.

