>I dunno here, is Rails a server application library because I can progressively integrate the different components of its total API I'm not familiar with Rail

>I dunno here, is Rails a server application library because I can progressively integrate the different components of its total API I'm not familiar with Rails but it sounds like the individual components you list can be used independently of your traditional Rails web server so that would indeed make them libraries. I'm not sure that makes the entirety of Rails a library. Could you rewrite an endpoint with Rails within another Ruby web framework (I don't know of any) without needing to run two servers? If so, Rails is a library. > But I don't write the code that says when they're called. That's simply not true. Every lifecycle method is the direct result of a specific programmatic call. Whether it be a render (ReactDOM.render), prop change (also ReactDOM.render), or state change (setState). If you don't setup the logic to call these APIs appropriately no callback will ever be fired. It only feels like React is firing these events for you because these API calls are likely hidden behind JSX and hooks and they are also asynchronous by virtue of React having to manipulate the DOM. > If I'm not writing the code that "turns the gears" per se, then to me I'm using a framework. The only gear you don't get to control is specifically how the DOM is manipulated. Everything else is in your control when using React.