One of the things I have often heared among my fellow front-end devs that prefer Vue or Angular over React, is that React is too unopiniated. Paradoxically, what is seen as a drawback is, for me, a great quality.

📚 Framework vs Library

With Angular, you have a full blown framework for creating a view, building forms, fetching data from the server, managing routing and navigation, and you have to follow the framework rules to architecture your application… Libraries like React or Vue only care about the view, and do not impose strict rules about folder structure or what lib to use for fetching data.

The big problem with the framework approach is that you have to learn how to do X with Y. For example, how to add class to my element in Angular? Oh, a NgClass, let's see how it works. How to fetch data in Angular? Oh, there is a http module, let's dive into this one.

How to fetch data in React? The answer to this question is rather simple: as you wish. Because the library does not care about where the data comes from. As long as you give it to your component, React will render it.

The library strategy is the "less is more" strategy: do only one thing, but do it right. Keep things simple. It allows developers to avoid over-engineering, which can be a real plague in a project that drags long or in a legacy project to maintain.

👮 Official vs Unofficial

The “Opiniated vs Unopiniated” discussion is also about official support of third parties. In Vue: you'll have a standard and official way to do routing, styling, state management, etc. It's cool as it's well documented and the developers is not left alone in the wild.

We can think of Vue.js as a good compromise: not too opiniated to avoid the bloated and heavy software, but opiniated enough to guide the developer with official modules.

In React, none of that! Developers have to figure these out by theirselves. Some third-party librairies like React-Router are practically default, but there is no official support. it can make React a bit harder to learn and can cause fragmentation in the ecosystem. When there is a lot of router or state management, which one to choose? Though question for a newbie.

So, yes, avoiding fragmentation is a noble goal, and it looks like official support flattens the learning curve, as the beginner have a clear path to follow. But I'm convinced that this is not necessarily a good thing in the long run, as developers will find it difficult to wander off the beaten official track. Indeed, we can easily fall back into the "How to do X in Y" nightmare.

From the beginning, React has done a great job sticking to the "it's just JavaScript" philosophy, always fighting the tendancy to add magic into the library. That way, "how I do X in React" often turns into "how I do X in JavaScript".

🕊 Freedom creates innovation

Innovation in third party lib: Redux, Recoil, React-Query, React-Router, etc. All this would be more difficult if there were officially supported libraries.

Innovation in React lib itself: hooks, concurrent mode, server components, etc. All this would be more difficult if the lib has to support a way to do everything.

🤔 Final thoughts

The learning curve of unopiniated tech might be steeper, but in the front-end world, I think this is the best strategy.

It might not be the same thing on the back-end, as we are dealing with more security concerns: authentication, roles, database, access to filesystem… In that context, a stiff but robust structure is reassuring, as it reduces the probability of security breaches.

In the JavaScript ecosystem, the unopiniated framework Express is very popular. But I find more opiniated alternatives very interesting. For example, this is the case of NestJS, a Node.js framework inspired by Angular, especially the pattern of modules and dependency injection. Very pleasant to use!

But hey, everyone has their own tastes! 🥝