Why I don't use React?

It goes without saying that React, together with its vast ecosystem, is the most popular JavaScript UI creation library out there. It’s used by big players such as Facebook, Spotify or Uber and has millions of downloads per week on NPM registry. But, in this post, I’d like to abstract from all that a little bit and tell you why I personally don’t use React. So, a disclaimer first - these are just my personal thoughts and you don’t have to agree with any of them. You can share your own point of view in the comments below.

First off, the title reveals an important detail. I may not use React, but it doesn’t necessarily mean that I consider it a bad or inferior tool. Most of the factors listed in this article have more to do with React’s environment and ecosystem, rather than the library itself and can be considered more “psychological”. You’ll see what I mean

Unbiased Vue developer

I started my web development journey not that long ago. Roughly 4 years have passed since then. After some time of using only plain JS, HTML and CSS, I decided to finally lift my skills up by learning something new - a UI library. Even back then, the situation with JS UI libraries looked pretty much the same, with React, Vue and AngularJS (the old one) reigning supreme. React was, even then, the most popular option. But it had one big flaw - its license. It was BSD and came with trade-offs about patents and “all rights reserved” stuff. For such a big and open-source library that was used in countless projects, this was quite a limiting factor for many of its potential users. It was ultimately changed to MIT in late 2017, but the damage has been made - at least in my case, when I decided to go with Vue after all.

As a side-note, I don’t regret my decision. Vue was (and still is) recommended as a great choice for hobby web developers, considering its smooth learning curve. I gave it a try and immediately fell in love with it. That’s why I didn’t really look back… at least for some time.

Ecosystem - React’s advantage

Even with Vue being one of the 3 dominating UI libraries for quite some time now, it still doesn’t have the same, well-developed ecosystem as React. Naturally, it’s because of the fact that it’s a few years younger project. Anyway, being a fan of Google’s Material Design, I was impressed by the Material-UI - React component library. Vue also had great sets of components of its own, but the temptation was too high. That’s why, after some time with Vue, I decided to give React a try - mostly only to try out Material-UI. But, it wasn’t just a one-time switch. I stayed with React for the next couple of months, creating quite a few small projects with it  plus Material-UI, and quite enjoying it in general. But, it’s some inner feelings of mine that made me came back to Vue and use it as my tool-of-choice ever since.

Separation of concerns

So, with some background set up, it’s time to stop comparing everything to Vue and talk about React itself!

React greatly popularized the concept of JSX. Having HTML-like tags in JS code was met with different opinions. Some liked it, others - not so much. That’s mainly because of the separation of concerns issues. But, this group of people seems like a minority, as with React becoming even more popular, JSX has seen a wide-adoption. Even within other libraries!

Personally, I have no problem with JSX. What’s more - I really like it! It has great support overall and makes HTML+JS integration seamless. Adding up to this is the fact that TypeScript - my favorite compile-to-JS language - supports JSX and makes it much easier and more enjoyable to write thanks to additional typings. So I’m totally in for JSX and think that other libraries adopting it is a good thing. Even though, it will probably retain its relation with React for a long, long time…

The only thing that I may not like about JSX (and most likely whole JS programming right now) is the need for transpilation. Sure, it’s a necessity and React development without that would be quite embarrassing, but still… That’s why seeing modern solutions utilizing native JS template strings is really refreshing to me! Even to such extent that I see it as a real alternative for JSX.

About architecture

React is developed by some really smart people. They pay high attention to details and try to keep the code as maintainable as possible. You can learn about it while e.g. reading their articles. If you think that all this is a bit exaggerated, take a look at React’s source code specifically. It’s a really big and complex code-base (mind multi-repo), so maintenance here is very important.

Another thing to notice about React’s architecture is its favor of functional programming (FP) practices. This can be seen even all across React’s ecosystem with other libraries like Redux. The use of FP is meant to make the code more stable, so such pattern is expected, based on what we previously discussed about React’s code-base.

Immutability is one of the most important concepts in FP. Instead of mutating (changing) the original value, the new one should be returned instead. JS partially supports immutability, with examples being some Array methods, like .map() or .reduce(). React, favors immutable data, especially when considering its state-based approach. But, as I said, it’s even more noticeable within the React’s ecosystem, e.g. with another made-by-Facebook library - Immutable.js. Maybe it’s a standalone library, but recommendation about using it with React doesn’t go unnoticed.

I personally struggle with embracing immutability. Maybe that’s because I’m more of a performance guy. Even though I really want to make my code more maintainable, and thus I started reading a lot more about FP in recent times. It’s often said that you shouldn’t favor performance over readability and maintenance and that such things are what’s called micro-optimization. But seeing 3x - 20x times degradation in performance, with use of only JS native array methods, is just heart-breaking to me. And, if you want some “real” immutable data structures, Immutable.js will provide you with just that… together with some additional KBs of code. There might be some performance degradation in a couple of cases too, but Immutable.js has been really well-optimized, so this shouldn’t be an issue. But still, it’s a big library and implementing it in your code might come with some breaking changes.

I know that array methods are extremely convenient, in fact, I use them quite often! But just putting them all over my code-base or using a library such as Immutable.js just for the sake of better maintenance doesn’t convince me. Maybe that’s because my projects haven’t ever had such problems. Maybe because I haven’t yet worked with projects so big that they’d require such kind of special treatment. On the opposite side, I’ve experienced some performance-related issues. But, with React in mind, its immutability-focused nature and my performance concerns, my inner conflict is quite understandable… I think.

Hello Facebook!

Speaking about the ecosystem, we all know that React is under the umbrella of Facebook’s open-source projects. Sure it’s also maintained by its community, but the Facebook influence is surely noticeable.

From a certain point of view, it can be considered a good thing. OSS supported by a company as big as Facebook can be seen as one less likely to be abandoned. People working at the company will always work on and look after it… but only as long as Facebook wants it. But, as we know, if the OSS is popular enough, its community is very likely to keep it maintained equally well. So, if React lost Facebook’s support one day (and no license changes would be made) it’s safe to assume that it’d take such hit without much damage.

But it’s Facebook itself that’s the problem. It’s this company that has one of the highest numbers of privacy issues per year, kind of monopoly on the social-media market and… one of the biggest collection of OSS out there. The number of libraries, tools and general commitment of FB into open source development is really impressing. It’s good - sure, but this whole situation makes me worried - could FB with such a big number of high-quality  (judging by the GitHub stars count) OSS tools available, try to use OSS to its own advantage? For example, consider the case of React’s previous BSD license. If not for the community involvement, Facebook could continue to use such license throughout all their OSS projects, effectively making OSS community embarrassed and unsure of their current situation.

I know that the term “open-source monopoly” sounds unreal, but maybe it’s good to take such an option to consideration. If too many projects are dependent on OSS code, that’s still mostly maintained by people working in one company, doesn’t this company have somewhat control over all of that? Still, such a scenario is very unlikely with React in mind, as it’s old enough to have a great part of its code contributed by other people, that doesn’t have any association with Facebook. But that’s worth considering. Especially to know that even your contribution can help stabilize the “openness” of your favorite OSS.

Up to the hype

Yeah, React is popular - almost every web developer knows that. And it’s this fact that makes new project use it. Popularity in the OSS world can be considered as a guarantee of the stability of the project. But, what if someone doesn’t really want to follow the “hype”? What if they want to be unique, to stand out? I know it might sound like a joke to some web developers, but this post as a whole is, as previously said, more psychological more than rational.

“Hype” is often used to something that’s too much popular - unhealthy popular. Can something like this be present in OSS? Maybe. Does it mean that React’s popularity is exaggerated? Not really. In programming, popularity isn’t just a one-time spin-off. A tool needs to be good enough to be deemed popular. But still, some people may not want to use such tools, despite common public opinion.

Preference

To summarize the whole point I’m making here - React is a really good tool. It’s been one of the first to exist, revolutionized web development and influenced many, many tools that came after it. Almost all of the new tools, whether it’s something completely new like Vue or just an alternative like Preact, React’s presence can be felt almost everywhere. It’s definitely up to the task - whatever you throw at it.

But, even with all its advantages, React isn’t perfect - nothing is. And that’s not only from the code perspective, but when looking at it from another side. As discussed in this post, the psychological-like look at React is really interesting. One might not like that it’s backed by Facebook, has certain architecture and is so popular, but still, consider it a great library. Others might consider such debates pointless. But, with countless libraries and frameworks available in today’s world, the process of decision-making has become really, really complex… especially in JavaScript space. That’s why some smaller and less definite thoughts can decide about one’s ultimate choice.

So, I guess this, like all things, this comes down to the person. It’s up to one’s set of thoughts about the given tool (also called preferences) to make the final choice. And, who knows? - maybe React is indeed the one… for some at least.

Thoughts?

So, that’s it for this post. A different approach to choosing your tools… a different perspective. But still, these are only my thoughts. Should one use React despite his inner feelings? Let me know what you think about all that in the comments and with a reaction below. Also, if you liked the article, consider sharing it, following me on Twitter, on my Facebook page and signing up for the weekly newsletter. Thank you for reading this one, and have a great day!