The other day, I was asked to compare frameworks like Angular and React.js. It was an interview, so I didn’t notice the tiny slip. Developers reading the interview didn’t hesitate to point out that React is a library, not a framework. A few months earlier other developers reminded me you can’t compare Angular with React because the former is a framework, while the latter is not.
The reactions of the community where so emotional that I gather many people consider it an important difference. That, in turn, means it’s fun to play devil’s advocate. It’s the kind of games generating new insights.
so, let’s have a closer look at these claims, just for the fun of it. Let me defend the opinion that React.js is a framework. To be honest, that’s not what I’m really saying, it’s just the headline over the 30-seconds-summary. Let’s see how it goes.
You can’t compare Angular to React! They are just too different!
Image source: Pixabay. Published under a CC0 license.Many a times I’ve heard I can’t compare Angular to React because you can’t compare a full-blown framework to a smart library.
Tell that to your customer. They need an application. You can write the front-end of the application either with Angular or with React (or any of the countless other frameworks and libraries out there). It’s unlikely you’re going to combine Angular with React. That just doesn’t make sense, and I doubt it’s possible at all.
So you have to decide between Angular and React. From the customer’s perspective, this choice makes a lot of sense. They don’t care about the difference between frameworks and libraries. You can use either to build an application. From the customer’s perspective, there’s no difference.
So why do we developers insist there’s a difference?
Using React as a library
We do so because the difference sometimes matters. For instance, there’s a WordPress plugin using React.js. React adds merely 23 KB to the plugin, so it’s a sensible choice. You can’t do that with Angular. The footprint of Angular is a lot larger, even after tree-shaking. That makes it an ill choice for lightweight websites and WordPress plugins.
Maybe even more important, Angular has been designed to be the only framework of your application. That makes it a bit difficult to integrate into another framework like WordPress. It’s also a bit difficult to add Angular to an existing application. Maybe it’s possible. Remember, a couple of years ago I’ve managed to “marry” Angular.js 1.x with JSF. These two frameworks both assume they own the DOM exclusively, so combining it was sort of a challenge. It works well, and it’s even used in a few applications in production. But most developers and architects felt this was a bad idea, so AngularFaces never took off.
Cutting a long story short, Angular is most interesting if you can use it from day one. Adding Angular as an after-thought is almost always a bad idea. React also shines when you add it to an existing project, or when you are concerned about memory footprint, and so on. Full-blown frameworks like Angular are doomed to fail under those circumstances.
Using React for enterprise applications
However, most of the time, I (like most front-end developers I know) work on major projects, usually with an enterprise context. One of the first decisions is which UI technology is used. It’s one of the few architecture decision that can’t be postponed. So let’s assume our team is working on a major application based on React.js.
Our team has to solve a lot of problems. Among other things, they have to communicate with the backend, they have to care about input validation, they have to implement navigation and routing, and so on. Every React programmer I’ve asked so far told me “well, that’s not covered by React. But there’s a library for that!”
As to my theory, every experienced React programmer has a set of libraries they use in every project. Together, these libraries cover more or less the same solutions as Angular does. Most likely, it’s only a subset. For instance, most teams never have to translate their application to foreign language, so they don’t need the i18n support of Angular. Even so, the collection of libraries share many commons traits with a traditional framework.
It may be a sloppy use of language, but I’m pretty much convinced that almost every experienced React programmer working in the enterprise context uses a React framework, consisting of React.js itself, a set of libraries written for React and some glue code.
That’s what I’m referring to when I call React a framework. I totally aware that React.js itself is a small library, but hardly anybody uses the bare-bones approach.
Differences between a de-facto-framework and a real framework
Of course, there are important differences. In the React world, every developer chooses their own set of pet libraries. That, in turn, adds a lot of flexibility. You can choose the framework addressing the requirements of your customer best.
The drawback of this approach that you have to find such a set of libraries. That’s a one-time effort, but that’s one of the reasons why it takes more time to set up a React application than an Angular application. It’s more than just asking the Angular CLI to build the entire application skeleton.
More pressing is the fact that you have to care about the updates of the libraries, and you are responsible for the compatibility. In the case of Angular (and similar frameworks), that’s the job of the framework team. You lose flexibility, but you gain guarantees that everything is compatible. At least within the framework.
Be that as it may, I’m pretty much convinced that React wouldn’t be the success story it is today if it was just a library. In reality, it’s part of a major ecosystem.
Wrapping it up
Mind you, would you care about using React.js if there wasn’t decent tool support for it? If you had to edit the JSF files with a black-and-white-editor, without autocompletion and without squiggly lines indicating errors?
Luckily, there are people willing to do this. That’s great because without those adventurous early-adopters there’d be no progress. Every new technology starts small.
But the vast majority of us is happy to get every support we can get. Editors, IDEs, debuggers, linters, quality checking tools, and so on. It takes many good ideas and tools to populate a programming ecosystem.
By the way, the last couple of decades rose the bar a lot. No developer (let alone their boss) accepts the productivity we displayed one or two decades ago. Most of the time we don’t notice the tremendous productivity boost because the requirements and the software both have become much more complex nowadays. I guess most of us deliver the same amount of business value we already delivered in the 90s, but nowadays the software concentrates more on usability, is part of a complex web of applications and we even manage to write automated tests.
Back to the ecosystem of editors, IDEs, debuggers, and linters. Judging by this standard, both Angular and React have done a good job. And both ecosystems are comparable. Neither falls short of the other. Both have a greater ecosystem and better tool support than many, if not most, other UI frameworks.
So, while I agree that it’s correct to call React.js “just a library”, I also insist that in the perception of the average developer, React is a lot more. Most developers embed React into a full-blown de-facto framework. Plus, React is part of a huge ecosystem. All this blurs the difference to the Angular ecosystem. Nobody will dispute that Angular is both an ecosystem and a framework. The daily experience of the average React developer isn’t that different. From this perspective, I call React both an ecosystem and a framework. That doesn’t mean I’m not aware of the differences. But there’s also value in pointing out the similarities.