> 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]
[0]https://github.com/mitranim/posterus
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]
[0]https://github.com/mitranim/posterus