[lhorie]

> it can be used in multiple and qualitatively different ways, in contrast with your own position

I agree React can be used in different ways but as I already pointed out earlier, this is a not-particularly-notable characteristic shared by a variety of frameworks, so what you're saying is more of a tangent (i.e. that a tool within a class of flexible tools is itself flexible too) than a contrast to anything I said (i.e. that the bullet points support the idea that React is a framework). In order to contrast to my original comment, the logical thing to do would be to present arguments to support the idea that React is not a framework, since that was the point of contention upthread that I was responding to.

[Chris_Newton]

In order to contrast to my original comment, the logical thing to do would be to present arguments to support the idea that React is not a framework, since that was the point of contention upthread that I was responding to.

You originally wrote, in the comment that I first replied to:

- It "calls you" (i.e. you never explicitly call your React components, React does)

This is clearly true, but as we have established, merely having a library call back into your own code is not a defining characteristic of a framework, because we all agree that the sort and Lodash examples aren’t frameworks.

I don’t think you’ve ever properly addressed my point that calling ReactDOM.render may only differ from these examples in terms of scale. You gave an obviously contrived example of importing Ember and not doing anything, but you can import React and use it to render component trees usefully efficiently — its raison d’être — simply by calling render when you need to, without relying on tools like state or hooks to trigger updates.

When people talk about React not being a framework, I believe this is what they usually mean. You can use it as a library just for handling your view rendering — “the V in MVC” — and you can call that functionality on demand and handle any other responsibilities your application has somewhere else using whatever code or libraries you like.

- It permeates your codebase (e.g. migration from moment to date-fns is something you can realistically do piecemeal, React to Vue or vice versa not so much)

I have migrated more than one substantial web UI from another rendering system to React. It was just like swapping out any other library. Most of the codebase didn’t know the previous rendering system existed before and didn’t know React existed afterwards.

I would like to emphasize that this is completely normal software development. Nothing I did during those migrations was novel or specific to front-end web development.

However, you can’t swap rendering libraries like that if you choose to tangle the other responsibilities of your application with your rendering logic, for example by doing other things inside your React components. In that situation, you are no longer separating concerns cleanly, and of course you will have more difficulty if you want to change your rendering library when you have you have tied the rest of your software architecture to it as well.

- It enforces a specific architectural paradigm (components) to the exclusion of others (e.g. MVC, MVVM, etc)

I have built and maintained more than one substantial web UI that used React and yet still had a clean separation of concerns along the lines of MV*. You use React for the V. You use the other parts to handle other responsibilities and to determine what data to pass into the V for rendering using React.

Obviously the “V in MVC” approach emphasizes using React for rendering, while managing other responsibilities like state and remote API calls in other ways. That means you’re not going to be using a lot of hooks, or class component state and lifecycle methods, because you won’t much need them. I’m not arguing that this is the only way you can use React, and clearly some people prefer to use those other React features more and their software designs will differ accordingly.

But contrary to your claim that I quoted above, React does not enforce a specific architecture. It does not stop you from adopting other strategies for designing applications and managing UI code that have proven to be effective elsewhere in the software world, and those strategies can be used as effectively with React as any other rendering library.

Those are the three specific claims you made that I first responded to because I don’t fully agree with them in the context of React. If your argument is that React is a framework because those claims are defining properties of a framework and React has them then evidently we disagree about that conclusion. But IMHO terminology isn’t as interesting as exploring different ways React can usefully be employed and the guarantees it gives and restrictions it imposes in each case, whatever we choose to call them.

[lhorie]

> ReactDOM.render is only different to these examples in terms of scale

I think you're confusing longitudinal vs latitudinal comparisons (see point about direct competitors). Sorting is not a competitor to React, or even in a similar class of tools.

I did mention equivalents to ReactDOM.render in various frameworks. Those equivalents also differ in scale in the exact same way as React does to sorting, and yet we're clearly in framework territory when we talk about them. One substantial difference I addressed is that React is inextricably integrated to its internal state and re-rendering mechanisms even if you only use ReactDOM.render; calling setState will always take over control for managing batch updates (not calling it is beside the point; it's always available). This is objectively more "frameworky" than, for example, Mithril's `m.render`, which acts like a true library in this case (and yet, it's still a framework).

> I have migrated more than one substantial web UI

I'm not sure what this has to do with the point you quoted. We've established w/ the lodash example that it is possible to "permeate" the codebase w/ a library, but that doing so is not an intended use case for a project that is a library, and conversely a project that is designed to dominate a complex control flow orchestration between user code and itself throughout a significant portion of scope for an app is a framework characteristic (and React presents that characteristic)

> had a clean separation of concerns along the lines of MV

Here, it appears you're conflating framework-ness with a specific scope size (roughly the size of MVC); this is inaccurate. Consider that Ionic is a framework despite being largely a "only V". Consider that Jest is a framework, despite having no concept of M/V/C whatsoever. Entity is only "M" but also a framework. But what they all have in common is they are organizationally opinionated within their scope of operation (this is what alluded to when I mentioned spaghetti code).

> If your argument is that React is a framework because those claims are defining properties

They are not defining properties, not exclusive to frameworks, possibly not even universal, and certainly not an exhaustive list of arguments. What I'm saying is that these are arguments used to support the idea that React shares an overall strong semblance to frameworks (even if the imprecise examples can be nitpicked to whatever extent). "If it quacks like a duck" and all that.

If we were to zoom out a bit, the entire reason why this whole framework-vs-library thing is even a thing stems from objections that the "just a library" tagline is often mindlessly parroted as a soundbite to support the idea that React is not "bloated". But ironically, if you scroll around this thread, you'll see that this correlation has lost its edge on two fronts: a) people now complain about fragmentation in the React world caused precisely by its lack of opinions in various areas of web development and b) many of the frameworks I mentioned are less "bloated" than React (because they don't support multiple ways of doing components, because they offer equivalent functionality in less bytes, or because apps written in them require less boilerplate for things like state management, for example).

[Chris_Newton]

This discussion is frustrating and I feel perhaps we should agree to disagree at this point. It seems we keep talking past each other and I don’t know how else to explain my position. It also seems that perhaps you have some more specific ideas in your head about what some of these terms mean and you are seeing what I’m writing through that lens, but unless you explain those ideas the rest of us can’t productively discuss them with you.

I addressed three specific claims you made in the comment I first replied to. The first was true as written and my point in that case was that it doesn’t tell the whole story about how React relates to your own application code. I have tried to be diplomatic, but the second and third were simply incorrect: you claimed that React permeates your code and makes migration between rendering libraries difficult, and that it enforces a specific architectural style to the exclusion of others, but as I have tried to explain, my own experience on multiple occasions has proven otherwise. These things are only true if you use React in a certain way, and my greater point throughout this discussion has been that you are not required to use React in that way and a different approach may be beneficial in some respects. I feel like the old saying applies here: perhaps someone who says a thing cannot be done should not interrupt someone who is doing it.