Sorry, but I think you have completely misunderstood me. We're not avoiding the popular Flux-style tools like Redux because we don't understand the need for a model behind the rendering components. We're avoiding them because they are nowhere near powerful enough out of the box for our data modelling and constraint enforcement needs. We're not kinda-sorta-fluxish, Flux is kinda-sorta where we were about five years ago on the Web side and probably closer to a decade ago if you include applications written in languages other than JS for native clients and the like. And we don't want to write a full application in React; we already have 90% of the application and we're just experimenting with whether React might offer a cleaner architecture for the easy bit in our next version.
Ah, that is a very different situation than I believed you were discussing. In which case...sure, that sounds logical. If you already have a good architecture and a very large, complex app, of course it's going to work better to keep the architecture you have than switching to the sort of naive React design that you'd normally find in a TodoMVC example project. :)
(...of course, that doesn't really tell you much about React; seems like all you really learned is that badly architected apps perform badly. Not sure that one needed much testing. And of course, your initial comment seemed to be making a very different claim.)
I'm sorry if my earlier posts weren't clear. I mentioned the kind of scale we're working on in another post -- the previous version is under 100K lines of code so still not really that large or complex as UIs go. But yes, it's a little more challenging than TodoMVC. :-)
In any case, our current view is that there is a useful middle ground where React may work well for us. The app in question predates just about all of the modern JS UI libraries/frameworks, at least in anything close to their current forms, so much of the rendering and event management code right at the front end is built with jQuery, early toolkits, and in many cases a lot of home-grown code. All of this still works pretty well, but quite a large proportion of it is functionality that every UI library in the universe provides today, so there's little reason to maintain another version any more. The rest of the app does have a good architecture that has stood the test of time, but for the next big update we're trying to solve much the same issues as everyone else with managing UI code as the app grows.
React is of interest to us for several reasons, from being a useful templating mechanism, through providing a way of composing components that are relatively clean and modular in design, to its efficient DOM updates and declarative nature. These too are presumably the features that make it attractive to many of its users. But it is also of interest for this project precisely because its scope is tightly confined to just the rendering parts of the system and it doesn't try to lock the whole app into its own framework.
We just confirmed early that some of the hype really is only that, and that scaling up to the kind of UI that has more than a few hundred data points on screen at one time is not as easy as some of the advocacy might suggest, so we're exploring how we can use the tool to take advantage of what it clearly does offer and play to its strengths without paying too high a price. In that respect, it's really no different to any other library we'd evaluate.
