With that theory in mind, why do dev teams switch from Angular to React or Svelte?

React is not a framework, it’s a tiny lib that renders stuff reactively. There are no guardrails, and it is not even specific to Web. You can use it to render to hardware LCD if you want.

When people switch from Angular to React, it’s not a framework-to-framework move. They may have outgrown a ready-made solution and want a fully custom one (could be some sort of home-grown framework, more aligned with their goals). React allows that, being a library.

Meanwhile, an actual framework-to-framework move can occur due to many factors like mismanagement of priorities or changes in HR situation (maybe they do not have success finding good Angular people cheaply, or they are already using Svelte somewhere and can reuse resources from another team).

"React is not a framework"

I know, people in our industry are lazy with words, but there are meanings behind them.

A framework is when you embed your code into the framework code, and the framework calls your code, like in React.

A library is when you call the library code.

You do not embed your code into some “React project”. You call React however you see fit. Sure, you pass it some callbacks, but it doesn’t make React stop being a library.

I might have always used React wrong, I don't call React but embed my code into React like so (syntactic sugar aside)

    class HelloWorld extends React.Component {
      render() {
         return (
           --- my code here start ---
           <div>Hello World!</div>
           --- my code here end ---
         );
      }
    }

and React is calling my code with render(), I'm not calling React.

React owns the control flow and the execution loop, which calls your code (hooks, render, ...) as needed.

With a library you own the control flow.

Here is what you typically do if you use vanilla React in Web context from scratch:

1. You define a function (or in your example a class) which calls React.createElement(...) one or more times and returns the result.

2. You set up the initial DOM as needed.

3. You call ReactDOM (another library, separate from React) and give it your function as callback.

4. ReactDOM sets up the main loop that handles updates to DOM when things change.

You can claim that ReactDOM’s reconciler “owns” the flow, but you have to keep in mind that reconciler is not part of React proper, that you are the one who calls it in the first place, and that React does not provide a reconciler of its own or impose any constraints whatsoever on the structure of your project or what you use to render things in the end or where (it could be not even DOM at all).

I imagine most people who think of vanilla React as a framework go with CRA or another template that brings in the boilerplate code, bundler configurations that make JSX magically work, etc., and acts as a sort-of-almost-framework (not a particularly good one, perhaps), which obscures the fact that React itself is merely a very generic library.

"It's not a framework because I say so"

Ok!

No. React calls your code (over and over again). That's a framework.

If using callbacks is what makes it a Web framework then you can call anything a Web framework.

React is a library not even specifically for Web. Angular, however, is a Web framework. It’s up to you if you want to compare the two, but you will not be comparing Web frameworks.

>>> React is not a framework, it’s a tiny lib that renders stuff reactively.

yeah, no.

try for example to mix in a single page react components and jquery ui widgets

I did that with React, but you can do that with many frameworks, even Angular probably if you’re careful.

You need to understand what makes a framework a framework. onion2k’s comment does a decent job of explaining that, take a look. React has no guardrails and does not force any particular structure. That’s why there’s a plethora of frameworks built on top of it.

I would include React in the framework camp. It isn't technically a framework but it goes far enough that it pushes you to write code in a specific way. If you approach it like a library you often find yourself writing code that doesn't work well with React, which is a common source of janky websites. If you approach it more like a framework, and make sure you follow 'the React way' you'll almost always end up with a better app. To that end it might be better to think about it like a framework.

> I would include React in the framework camp. It isn't technically a framework but it goes far enough that it pushes you to write code in a specific way.

My litmus test to decide whether I'd personally classify something as a framework or library is to see what it's compared against and how people talk about it, as well as how they actually use it in a given scenario.

For example, people typically consider using either Angular, React or Vue for a project. Then, they talk about it very much like it is "an Angular project" or "a React project" because most of their code is limited to working within the confines of those (life cycles, state management, routing, patterns).

Does the fact that you could swap out one React statement management solution for another actually matter in that case for the distinction? It would... if anyone actually ever did that. Most people stick to whatever is the recommended option.

Same for the ability to run a whole Vue app under a specific div in a greater legacy site - in that case it would be treated more as a library... except that happens very rarely.

Then again, I don't really care about how strongly people care about these things, in my eyes one day the same codebase could be treated as a framework (a SPA in Vue with all of the mainstream packaged like router and Pinia, with hundreds of components and thousands of dev hours) and another as a lightweight library to be embedded into something else.

I believe when people consider using Angular or React they are simply not informed and make a mistake. I was in that camp myself. It’s important to be aware of what you are getting if you go with React, and what you are getting is a far cry from what a framework would offer, with all the corresponding pros and cons.

> It’s important to be aware of what you are getting if you go with React, and what you are getting is a far cry from what a framework would offer, with all the corresponding pros and cons.

Would you like to elaborate on that?

In my experience, with something as great, size/ecosystem-wise as React, there will almost always be at least one mainstream package for whatever you might want to do with it, that integrates pretty well. Where a lot of things might come out of the box with a framework, with a library I often find myself just needing to install the "right" package, and from there it's pretty much the same.

For example, using https://angular.io/guide/i18n-overview or installing and using https://react.i18next.com/

Or something like https://angular.io/guide/form-validation out of the box, vs installing and using https://formik.org/

Or perhaps https://angular.io/guide/router vs https://reactrouter.com/en/main

Even adding something that's not there out of the box is pretty much the same, like https://primeng.org/ or https://primereact.org/

React will typically have more fragmentation and therefore also choice, but I don't see those two experiences as that different. Updates and version management/supply chain will inevitably be more of a mess with the library, admittedly.

Now, projects like Next https://nextjs.org/ exist and add what some might regard as the missing pieces and work well if you want something opinionated and with lots of features out of the box, but a lot of those features (like SSR) are actually pretty advanced and not always even necessary.

There are a bunch of compatible packages, sure, I just meant what you are getting is not actually a proper Web framework, that’s all. It’s a reactive renderer library with another library (ReactDOM) that makes it work with DOM.

I imagine because the framework isn't working for the way they want to build things. That's a good reason to switch. Teams should pick the tech that aligns best with the way they want to work.

If they're switching for user-facing reasons it's likely that they're using just the framework poorly. Changing your own code is usually a much more effective way to get a perf boost than changing an underlying library.

Yes, but I was not interested in general reasons, but reasons with that theory "A framework is a way of aligning how you approach writing things. " in mind.

Take your pick: resume-driven development, Make Your Day Job Exciting Again, or thinking that switching frameworks will magically solve all your technical debt and inherent complexity