> If you've ever had the "pleasure" of writing React with plain React.createElement() calls (what your JSX ultimately gets transpiled to) then I think you would more likely agree with the notion that React is "just a library".
I'm not sure why someone would unless you're strictly writing static JSX with no components whatsoever as some sort of weird replacement for just writing the equivalent static HTML. The minute you write a `render` or lifecycle method, React is now calling you. Not to mention stuff like Suspense asking you to throw a Promise to render from latest render cache.
I think something like Crank.js[0] is more a view library since it puts all the nuts and bolts into userland.
You use React APIs to do everything you would normally do with React. You use the API directly if you don't have a build step for your web app and you cant or don't want to add one. Since React is indeed simply a library with an API, you can progressively integrate React into an existing web app in this way (a big selling point in the early days that people have sensibly forgotten by now). You couldn't progressively integrate a traditional framework like Django for example.
Lifecycle methods like render, componentWillMount, etc are just callbacks that get fired when you render you a component. I don't think any library is immediately graduated to the class of "framework" the moment a callback is added.
> You couldn't progressively integrate a traditional framework like Django for example.
I dunno here, is Rails a server application library because I can progressively integrate the different components of its total API, e.g. first use ActiveRecord, then adopt rails-api for the frontend, then adopt ActiveView and Turbolinks for the end-user frontend? Or is there different idea of framework at work here?
> Lifecycle methods like render, componentWillMount, etc are just callbacks that get fired when you render you a component. I don't think any library is immediately graduated to the class of "framework" the moment a callback is added.
But I don't write the code that says when they're called. Backbone is more of a library, for example, since it lets me do all that and it can be progressively integrated into an app too (I can just use models, I can just the views, etc). I mean thats part of why people ran to Ember and Angular when they appeared, they didn't feel like doing all that.
Also see Crank.js: you can emulate React's Component API in Crank, but the reverse is not true. If I'm not writing the code that "turns the gears" per se, then to me I'm using a framework. That framework might have a small API surface, it might have a large API surface. That's how I see it at least. A framework to me is defined by a certain threshold of abstraction.
This is an async task library because I can opt-in and out of, as well as control, or simply replace, the scheduler[0]
>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.
> I dunno here, is Rails a server application library because I can progressively integrate the different components of its total API, e.g. first use ActiveRecord, then adopt rails-api for the frontend, then adopt ActiveView and Turbolinks for the end-user frontend? Or is there different idea of framework at work here?
I think you misunderstood parent comment. Progressively integrate here means: you have a web page (facebook.com), you want to replace a part of it with react (chat function), you rewrite just that portion of the webpage in react.
You can't get a Sinatra application and replace just one route with rails. Well, you can use ActiveController, which is just an opinionated wrapper around Rack with a lot of sugar, but that wouldn't be rails and you won't get any rails benefits of doing that.
I'm not sure why someone would unless you're strictly writing static JSX with no components whatsoever as some sort of weird replacement for just writing the equivalent static HTML. The minute you write a `render` or lifecycle method, React is now calling you. Not to mention stuff like Suspense asking you to throw a Promise to render from latest render cache.
I think something like Crank.js[0] is more a view library since it puts all the nuts and bolts into userland.
[0]https://crank.js.org/