It only feels this way because your calls to React are hidden away behind JSX. I believe this is also why you can't write any JSX without importing the React module first.
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".
Create-react-app is much more akin to a framework in that it bootstraps an environment for you where you don't have to do any of the things that make React feel like simply a fancy library for rendering HTML.
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.
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.
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'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 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.
When you write
return <MyFunction foo={bar}/>
return React.createElement(MyFunction, { foo: bar }, [])
It's really a reactive-functional type system, rather than a framework - with a syntactic sugar that makes it easy to generate a reactive wrapper round a function.
Then you take the result of passing all your functions into that syntactic wrapper and hand it to ReactDOM to have it synchronize it with the DOM.
React transcends the framework/library discussion because it really isn't either. It's a higher-ordered type factory.
Literally everyone has to cobble some n-factor framework together and given the amount of inexperience out there, what results is a damn nightmare.
React solving the state problem natively would have made it an industry game changer. What we have is an industry mess.
React is a library that powers several different frameworks, as well as lets people use it without those frameworks. If one size fits all, answer-for-everything frameworks were the optimal solution for all problems, Angular would own the world and we wouldn't need React.
React really isn't the thing people have decided is the optimal solution, jsx and keeping presentation tightly coupled to business logic is.
What is see with react is constant attempts to work against that ideal.
My point is there is no one thing people have decided is the optimal solution. React is an element of snow me of (several different) things people have found is optimal for some problems, and not part of others.
> jsx and keeping presentation tightly coupled to business logic is.
JSX is more generally than React is, which is why many not-React solutions use React, too, though even that is far from universal. Tight coupling between business logic and presentation is, OTOH, far less generally what people have decided is optimal.
In my experience redux just enables developers to sprinkle global state everywhere which makes tests a pain to write and code hard to debug.
Sorry, you will have to do things React’s way until the end of time if you want your rendering to be optimal. That means whatever it means, hooks, suspense, fibers, context, so on.
A library means I get to plug in other stuff without totally crippling another library, as React claims it is.
Nothing wrong with React, just become the framework you are and provide the built in solutions.
Think of it this way, imagine the React team made curl. Now they say you can curl anything. So now you say, ‘ok, I want to curl this’ and they respond:
‘Oooo, I don’t know about that, that’s gonna mess up all the curl internal optimizations, hmmm, no no, you SHOULDNT be curling that’
And then we all walk away going ‘oh’, silently. Checkmate, hoodwinked.
React was not bothered at all. From the start there were ways to escape React model in components and integrate components into other frameworks. Been there, done that, it was never a huge deal.
But I am an American, so I won’t put up with any inconvenience and don’t consider it virtuous to do so (we fought a war over a tea tax after all).
But I’ll take a wild guess:
A bunch of useRefs? I’m excited to hear all of this.
import { useEffect, useRef } from 'react';
import { Controller } from 'some-animation-library';
const SomeWrapperComponent = ({ options }) => {
const elementRef = useRef(null)
const controllerRef = useRef(null)
useEffect(() => {
if (!elementRef.current) {
return () => {}
}
if (!controllerRef.current) {
controllerRef.current = new Controller(elementRef.current, options)
} else {
controllerRef.current.setOptions(options)
}
return () => {
controllerRef.current.doSomeCleanup()
}
}, [options])
return <div ref={elementRef}></div>
}I’ve been using React for quite some time (started with version 0.11 or something) and had to integrate quite a few libraries on my own (stuff like OpenLayers for maps, etc) and it also worked pretty well. Also made few apps that had only few widgets (search UI, calendar, etc). It usually worked quite well.
Mixing React with non React is quite easy. You only need to encapsulate it - keep all non vdom stuff in one component and never escape single DOM node.
Until the hooks introduced.
Now it also want to handles all the state and timing for update. And you are no longer able to call from outside or decides when to render (in a simple manner, as there are still workarounds).
> This is why I don't like when people say "React isn't a framework, it's just a library"
Eh, this is just a breakdown in the "framework calls you" heuristic. It's still a reasonable heuristic, but it doesn't completely describe all distinctions people make between frameworks and libraries.
The distinction missing from the heuristic is the overall scope of the software project relative to other popular software projects in the same area. When people say "React isn't a framework, it's just a library" they're not saying much about the coding style one uses while using React. They're just comparing the overall scope of React to some of its close competitors (like Ember and Angular).
There may not be a clear line between framework and library, but as written in the homepage of reactjs.org, it claims itself: React - "A JavaScript library for building user interfaces"
This is why I don't like when people say "React isn't a framework, it's just a library". Almost all of my React code is "called by React" with the one exception being `ReactDOM.Render()` (I don't count that since every other framework has some analogous "bootstrap" instruction).
Now if folks want to argue that React only handles the "view layer" without providing a built in state management solution, that's absolutely true (and considered a separation-of-concerns positive by a lot of people including me). But I feel like so many folks just boil this down to "React isn't a framework, it's just a library" and then use that as a segue to negatively comparing it with their chosen tool.