It's absolutely fine to adopt React piece by piece, I disagree entirely that it's an all-or-nothing proposition. I've converted a heavily used in-production ser

It's absolutely fine to adopt React piece by piece, I disagree entirely that it's an all-or-nothing proposition. I've converted a heavily used in-production service from 0% to 100% React over the course of more than a year. And this is an SPA, so over that year there was literally jQuery and React rendering to the same DOM. It works just fine, it's all just JS. You don't have to use Redux etc. (but you probably do if you have sufficiently complex state). Even then, you can do things like have multiple stores in the same app. It's fine! It's just JS objects being spliced, merged, propagated. You eventually converge on a single store as the various React parts merge. You don't need to use react-router, or even a router lib. It's probably better if you don't, given how many times that shitshow of an API has been completely rewritten. I took one look at it, could tell that this lib wanted to be fully in charge, and noped out. It's fine to manage browser URL state yourself, it's just JS and the browser APIs are OK for that nowadays. Now we're in the process of adopting Immutable.js. It's fine, it's just fancier collections, with some conveniences and being able to use React.PureComponent 99% of the time without worry. So your codebase is 50% fancy collections and 50% JS natives? That's fine, don't worry about it, just write new components using Immutable.js if that's the direction you're going. Don't worry about the top-level Redux container not being an Immutable instance, just use it for the leaves then. Server side rendering? I retrofitted that in a weekend by compiling the app as a lib with Webpack (project started as Gulp way back), included that in Node.js as an import. Worked just fine, nothing to it. Now we're generating PDFs using the same frontend code with Puppeteer and SSR, it's awesome. The app is in a better shape than ever, a real pleasure to work with. Jest tests for React stuff, Mocha tests for other parts. And that's fine, no need to get all religious about which one is the "one true" framework.