Have you done Backbone? The idea is that you define everything in terms of models and that when one of those models change you call render() to run it through y

Have you done Backbone? The idea is that you define everything in terms of models and that when one of those models change you call render() to run it through your templates and you're done. This is a simple conceptual model, the framework needed to execute it is simple (and well written in the case of Backbone), and it works really well for simple applications. The problem arises when you can't just call render: when you have input fields, when your rendered DOM has event listeners, when you're using a component with it's own internal state (e.g. a jQuery datepicker), or when you're doing something like a grid and generating too many DOM nodes. Unless you know this is coming and have a plan for dealing with it (e.g. the many Backbone addons), this is a complexity land mine since it does not show up in the small apps you build while testing out the framework. You can (and I do) view the React render as an idempotent projection from state to DOM, otherwise known as a template. React is a very fancy template system. You build your fragments (components) up into views, pass in your data, and render the entire page as if you're rendering it from scratch. It handles or provides hooks for all the situations I mentioned in the previous paragraph and React's internals ensure that it's reasonably performant by default. Having everything conceptually fully render from scratch every change means there's no separate handling for the initial render versus updates to the initial render (e.g. you have an accordion, render it with an ejs template but toggle it open/close by toggling classes). It makes the Backbone model work in a way that's easy to reason about. A real world example: I've implemented (B2B, not something I can link) a drag and drop layout builder as a contract. The workalike they wanted, which I had also worked on but didn't design, was ~6k lines of node/class manipulation and mousenter/leave hit testing while my React version worked out to be around 600 lines, most of which were generating virtual screen position hitboxes for the various drop zones. Hovering/dropping in a zone changes attributes in a list of JS objects and the visual feedback is handled by the rendering code you'd need to draw the layout anyway plus another 20% for the drop previewing/hovering. Most savings aren't as dramatic but in general you wind up spending less effort getting your views right. The LoC isn't always that much lower but it's template code instead of manipulation code. There are other benefits like component composition just working, server side rendering, putting all your app state in one place lets you do session recording and time travelling debugging but this post is long enough as is.