title: Can a React-Redux app really scale as well as, say Backbone? Even with reselect. On mobile
body: <p>In Redux, every change to the store triggers a <code>notify</code> on all connected components. This makes things very simple for the developer, but what if you have an application with N connected components, and N is very large?</p>
  
  <p>Every change to the store, even if unrelated to the component, still runs a <code>shouldComponentUpdate</code> with a simple <code>===</code> test on the <code>reselect</code>ed paths of the store. That's fast, right? Sure, maybe once. But N times, for <em>every</em> change? This fundamental change in design makes me question the true scalability of Redux.</p>
  
  <p>As a further optimization, one can batch all <code>notify</code> calls using <code>_.debounce</code>. Even so, having N <code>===</code> tests for every store change <em>and</em> handling other logic, for example view logic, seems like a means to an end.</p>
  
  <p>I'm working on a health &amp; fitness social mobile-web hybrid application with millions of users and am transitioning from <strong>Backbone to Redux</strong>. In this application, a user is presented with a swipeable interface that allows them to navigate between different stacks of views, similar to Snapchat, except each stack has infinite depth. In the most popular type of view, an endless scroller efficiently handles the loading, rendering, attaching, and detaching of feed items, like a post. For an engaged user, it is not uncommon to scroll through hundreds or thousands of posts, then enter a user's feed, then another user's feed, etc. Even with heavy optimization, the number of connected components can get very large.</p>
  
  <p>Now on the other hand, Backbone's design allows every view to listen precisely to the models that affect it, reducing N to a constant.</p>
  
  <p>Am I missing something, or is Redux fundamentally flawed for a large app?</p>