My assumption was that writing the handful of sCU I think you'd need is simpler than handling coordination. You seem to have a reasonable understanding of the tradeoffs.
> At that point, it seems you're not necessarily any better off than you would be with a more traditional, event-driven architectural style
Not having to implement the dom state updates and rAF update batching are fairly big wins. The only other way I know of doing this is via data binding and the difference there is that individual updates are more efficient but establishing the bindings is usually O(n_size_of_input) and in practice every app I've worked on that did data binding eventually broke the approach. Having the shouldComponentUpdate escape hatch has allowed me to push much larger volumes of data through the system without it breaking.
I've implemented a number of reasonably complex apps but the two largest have been on immutable datastructures where React's assumptions always hold unless you screw something up. The largest non-immutable app I've written was a 25k LoC layout builder where the two shouldComponentUpdates for vdom pruning were pretty straightforward.
Not having to implement the dom state updates and rAF update batching are fairly big wins.
I agree, and these are two of the main reason we're interested in React. We've had in-house code doing some similar things for a long time, more the batching than rAF in our case, but for much the same reasons. Now that mainstream libraries are offering similar tools and with reasonable trade-offs in terms of functionality offered versus level of dependency, there's not much reason to maintain our own in the next generation of the UI.
In case you're interested, our model code also presents its interface in the form of immutable data structures, with quite fine-grained events available to monitor quite specific parts. But even with that, in something like our small multiples test case, where we're plotting a number of interactive SVG charts using modestly derived data but thousands of underlying data points, it appears that the indirections and tests do still add up to a noticeable level of overhead. Of course that's more demanding than what a lot of web apps will ever need, and our conclusions for our project won't necessarily be anyone else's conclusions for theirs.
> At that point, it seems you're not necessarily any better off than you would be with a more traditional, event-driven architectural style
Not having to implement the dom state updates and rAF update batching are fairly big wins. The only other way I know of doing this is via data binding and the difference there is that individual updates are more efficient but establishing the bindings is usually O(n_size_of_input) and in practice every app I've worked on that did data binding eventually broke the approach. Having the shouldComponentUpdate escape hatch has allowed me to push much larger volumes of data through the system without it breaking.
I've implemented a number of reasonably complex apps but the two largest have been on immutable datastructures where React's assumptions always hold unless you screw something up. The largest non-immutable app I've written was a 25k LoC layout builder where the two shouldComponentUpdates for vdom pruning were pretty straightforward.
Good luck with your app.