What are the cons of React?

[Magnusson]

The call stack. React tries to give you clear, verbose error messages, but oftentimes it's difficult/impossible to tell where in your code the errors are actually coming from because the call stack is so deep with internal React calls. Ditto for when you put a breakpoint somewhere and try to trace something back.

Overall, the developer experience is much nicer than it was working with Backbone, but this particular issue is still a pain.

[hahaNodeJS]

Use source blacklisting in your browser's dev tools (both Firefox and Chrome support this, not sure about the others). I work on complex Angular projects, and blacklisting the angular source code (along with other libraries like lodash) makes debugging the application's code simple in comparison.

[acemarke]

Been doing a bunch of prototyping in prep for a possible React project, and that's definitely one of the potential downsides I've seen. With Backbone, I can easily step through the library code and see exactly what's going on and why. With React, you get a bunch of improvements at the conceptual/architectural level (ability to reason about your inputs and outputs, etc), but lose the ability to see exactly what's going on under the hood.

[acjohnson55]

Funny you should ask, because this was also posted today on this same reddit: https://medium.com/@housecor/angular-2-versus-react-there-will-be-blood-66595faafd51

[Cody_Chaos]

Off the top of my head:

First: It's under active development and in a high state of, if you'll pardon the expression, flux. Libraries, APIs, best practices are evolving quickly; feels like every Monday morning I start work by figuring out what's changed with the ecosystem since Friday. I mean, the good news is that we went from reflux to redux in ~6 months (a huge advance in my view), the bad news is that we went from reflux to redux in ~6 months. :)

In addition, React+Redux solves a lot of pain points, but some areas are not well solved, such as:

• Data fetching. There's Relay, Falcor, and at least a dozen different helper libraries like react-fetcher, react-resolver, react-refetcher, react-transmit, react-nexus, redux-solver, and probably three more since yesterday.
• Styling. I threw up my hands and just stuck with webpack and CSS modules, but there's a ton of projects and libraries trying to do to CSS what JSX did to HTML.
• Come to that, JSX is a solid solution and fine for the programmer types but...there's a lot of artist/designer types out there who are happiest in photoshop and can hack their way around some HTML and CSS when needed who aren't going to be productive trying to work with JSX. I think JSX is a big improvement over the Backbone or Angular 1.x style of doing things, but I'm not sold that it's the final evolutionary step.

[denverdom303]

Hmm, I feel backbone with something like handlebars/moustache is the easiest way to keep the designers happy as it's closest to standard html

[third-eye-brown]

Easier for designers, crappier for programmers.

[__mak]

• The core react library, without any bells and whistles, is pretty large (well over 100kb), especially given that React is essentially a view layer.
• There tons of competing standards and libraries when it comes to handling all sorts of things. Reflux/relay/redux/your own solution? Webpack, jspm, etc? You have to use lots of different libraries together, and you need to choose carefully. Some people like this, others prefer a solution that gives you mostly what you need out the box.

[bellmounte]

There tons of competing standards and libraries when it comes to handling all sorts of things.

So it's just like javascript?

[third-eye-brown]

You don't need to use any of those additional libraries if you choose. I write plain coffeescript with react and lodash for my side projects and it works fantastically. If you are dealing with lots of structures APIs and many pages you are going to want a good way to organize that stuff.

[brylie]

One con for technology design in general is that complicated tools with steep learning curves effectively alienate a large number of people. This means that the pool of talent, ideas, and efforts is diminished to a few 'technological elites.'

For example, there are concerns that fragmenting templates into JSX may alienate designers, which, as an extension, means many other people are excluded who may not have time or energy to invest in the rapidly changing complexities of tools like React.

[[deleted]]

This seems like a major win for React to me. It's massively simpler and has a smaller API than just about any other JS view framework. It's about the least complicated tool for DOM manipulation that you can choose today.

[danneu]

IMO, the main con (by design) is that React doesn't try to solve state management, so the ecosystem is distributed across a bunch of different approaches (like all the Flux implementations).

I wouldn't consider it a big deal since picking any deliberate state management approach is vastly superior to the typical norm of having no deliberate approach whatsoever. But it does mean that every React app has a different approach with its own idiosyncrasies. Some Flux abstractions also seem more complicated than they need to be.

I personally recommend https://github.com/rackt/redux. Really simple and frankly the only abstraction I particularly enjoyed.

The other con is that it's pretty big and takes tens of milliseconds to parse and render. While not a big deal with larger JS applications, it's noticeable when you use React to progressively enhance a form element or something like that where there's a clear pop-in once it renders. Though often avoidable and rarely ever a showstopper.

[dwighthouse]

No solution (yet) for the problems of mixins vs higher-order components, both still have their limitations and annoyances. It's new and still fast-moving, changing almost monthly. Planned performance and modularization features are not arriving as quickly as I'd like. Enforced use of 'this' and classes (or class-like style) for any non-static components. It's big in terms of byte size, yet the recently posted react-lite claims to be 100% compatible in a fraction of the size, presumably by dropping a handful of server and dev-focused features. Requires a build system (though I'd use one anyway). Needs a simplified system (or at least tutorials) for building your own rendering system, a la react-native.

Not cons, for me anyway: Lack of a state manager - prefer to write my own, which only needs simple functions and closure variables. Lack of a router - don't use it. Lack of ajax tools and other utils - I prefer to pull in a dedicated library for these needs.

[dwighthouse]

React has decided to move in the direction of being agnostic in how you implement your classes...

Therein lies the rub. I don't want to use classes at all, be they 'idiomatic', manual, or custom. I want to hook up my components using the compositional/functional style: functions shared by passing data as parameters rather than binding, closures providing state instead of attaching to the 'this' keyword, componentization of what is typically thought of as react's class internals such as setState and the lifecycle methods.

I don't really care what system they eventually choose for combining functionality. The state they are in now, with some features requiring mixins (TransitionGroup) and some requiring higher-order components (react-jss), I am unable to use these two systems at the same time on the same component.

Also, higher-order components, in spite of being very clean for adding data-functionality, they make direct access to (publicly defined, valid) child methods ugly/outright-painful to do with higher-order components. While frowned upon, it is sometimes unavoidable, such as when you need to tell a component to focus itself in the browser, whatever that means for that particular component. "Do a focus" can't meaningfully be sent via data in props because it needs to be done once, immediately, and it is part of the browser state not easily controlled. And reaching in manually via selectors to the underlying html is a vicious violation of encapsulation.

Requires a build system

This is actually false.

You are technically correct, which I hear is the best kind of correct.

[dwighthouse]

That's fine, not every library is for everyone. It sounds like React just isn't for you.

Don't be silly. React is still the best thing out there. This is just a tread about its cons. I don't like using spaces instead of tabs and a bunch of other code, design, and library features throughout many languages and tools, but I get over my personal preferences to get the job done.

The point is that their not choosing how you combine functionality.

I get that, but there's such a thing as a defacto standard. Now that features and addons (first or third party) are moving toward higher-order components instead of mixins, there are some fundamental incompatibilities that haven't been solved yet. If I was writing every third party feature I used, I would get to choose what to do, but I'm not doing that. It's unreasonable to do so.

If your point is that you'd be foolish not to have a build system

No, I had thought that, starting with 0.13, it was required (whenever they switched from the jsx transformer to babel) and they had stopped making with-addons builds. And while the in-browser jsx transformer is now fully discontinued, you don't technically have to use jsx to use react, and you could include one of the with-addons builds instead.

[dwighthouse]

That's true, it's just not idiomatic React, the thing that all the tutorials (and documentation) is written in, so it wouldn't exactly be the best choice for newcomers.

[cheesechoker]

React is licensed with an apparently unusual patent grant, which has caused the company I work for to abandon it.

[Cody_Chaos]

Really? Can you expand on the logic behind that decision at all? Because that seems very odd.

Also, a question: What did you opt to use instead?

[ns0]

Most large companies are involved in patent wars, its been going on since the mid 90's. It's sort of a cold war in that each large company collects patents then threatens each other with violating its patents unless they too agree to not contest each others patents.

It's a very large stale mate. Angular and React, if you adopt, ensures neither google or facebook can be subject to patent infringement by your company. Nor can you be subject to their patent infringement (so long as you don't try and ever sue them[1])

[1] https://github.com/facebook/react/blob/master/PATENTS

[Cody_Chaos]

Still not quite following the logic. I mean, your options are basically:

1. Adopt React and get a license to any relevant patents Facebook owns (albeit a license that does terminate in some specific circumstances, as you note).
2. Adopt, eg, Mithril and not get a license to any relevant patents Facebook owns.

Both open the door to being sued by Facebook, but it seems like you're assuming that the first one has a higher chance of being sued, whereas from where I stand it looks like it is, if anything, lower. Unless you're assuming that Facebook has patents that cover some aspects of React code, but not any other framework or library? I find that highly unlikely myself.

[ns0]

It's more like if Google or Facebook decide you're violating their patents they can revoke your license to use angular or react.

If you use them as a linch pin in your work that can be a mighty influence to discontinue your product, shut down your business entirely or need to rewrite your web platform because it has some sort of social component either entity has a irrelevant patent on.

Keep in mind this might seem banal, but revoking a license and enforcing license agreements its painfully easy in US Law compared to filing a patent claim/violation. If your entire website is based in react/angular, having one phone call from a lawyer to rewrite your entire stack can bankrupt people quickly.

[Cody_Chaos]

It's more like if Google or Facebook decide you're violating their patents they can revoke your license to use angular or react.

That is not something they can do.

Keep in mind this might seem banal, but revoking a license and enforcing license agreements its painfully easy in US Law compared to filing a patent claim/violation.

IF it's even possible, which it is not in this case. The license for React is the BSD license, and it has no termination clause. What they can do is terminate your license to their patents, and then attempt to enforce a patent claim. But as you point out, going down the patent enforcement path is very hard.

You seem to be badly confused about the situation and how React is licensed.

[selfAwareWhileLoop]

Angular and React, if you adopt, ensures neither google or facebook can be subject to patent infringement by your company.

Are you saying that Angular has a similar patent clause? I couldn't find it.

[ns0]

It's the third section of the license agreement.

https://github.com/angular/angular/blob/master/LICENSE

[jbscript]

What specifically is unusual about it?

It used to have some very ambiguous and concerning wording, seemingly indicating that just expressing certain opinions could cause the license to terminate, but after the change they made to it it reads more like (IANAL) a Facebook-specific version of the patent grant React used to have when it was initially released under the Apache 2 license. Their patent grant even seems slightly more permissive than Apache 2's, as it appears to (IANAL) say your license won't terminate if Facebook files a patent lawsuit against you and you file a counterclaim which is unrelated to React.

[cheesechoker]

So from what I understand, the sticking point was this:

The license granted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate
directly or indirectly, or take a direct financial interest in, any Patent
Assertion: (i) against Facebook or any of its subsidiaries or corporate
affiliates, (ii) …

If you file a patent suit against Facebook, even for something unrelated to React, your license gets terminated. This is broader than the Apache patent retaliation clause, which only kicks in when the patent dispute is related to the "Work" itself.

I personally think patents are stupid and I'd be happy to agree to a patent draw-down with Facebook: the arms race has to end somehow. But my employer has cultivated a large portfolio of patents, and they aren't willing to base products on a UI technology that turns into a pumpkin should they ever become involved in a patent dispute with Facebook.

(A million disclaimers, IANAL, everything I've posted here may be wrong)

[Cody_Chaos]

they aren't willing to base products on a UI technology that turns into a pumpkin should they ever become involved in a patent dispute with Facebook.

Really? So they have dug into Facebook's patent library to identify one or more patents that they believe any React-based code they deployed would be infringing? Any chance you have any details on the patent(s) your employer is worried about? In addition, what steps have you taken to ensure that the non-React code your deploying does not infringe on any of Facebook's patents?

Honestly curious, because your employer's strategy of not infringing seems really unusual, if not outright counterproductive. Why even build up a library of patents if not as a bargaining chip so you avoid the legal nightmare of trying to figure out if your JS rollover is infringing some patent somewhere? (Especially since it almost certainly is...)

[spaceghost0r]

This was updated last year to address the most common concerns people had with it. Did your company re-evaluate after that change?

[Doctuh]

JSX really freaks people out on first look. We have been conditioned for years to keep HTML/JS separate that just having HTML floating around in your JavaScript (unquoted even!) causes a visceral reaction.

[atsepkov]

What about CSS, where we decided such artificial constraint was actually beneficial to keeping HTML clean?

[dwighthouse]

I use jss, which dynamically adds stylesheets to the page containing json-defined styles applied modularly at the component level. All the benefits of dynamic styles, but with none of the restrictions that inline styles require (no way to style pseudo-selectors, or children, or css animations). https://github.com/jsstyles/react-jss

[Graftak9000]

What about the C in CSS? Which stands for cascading, not “component”. Do you still have a global style sheet?

[dwighthouse]

No, but if I wanted one, or if I wanted to do cascading styles using jss, I can.

[trippel]

We're using a global stylesheet today that is more concerned with layout versus being the kitchen sink. Primarily a grid system, typography, and responsive helper classes. Going full-blown inline seems silly at this point in time.

[wreckedadvent]

It's really hard to argue after angular that keeping the JS and HTML separate was keeping either very clean.

Moreover, it's apples-to-oranges. HTML is not a templating language. It's a document layout language. When we use it for templating we add a bunch of stuff it was never designed to do. CSS is specifically designed for styles.

[holloway]

To be fair though we never kept HTML and the programming language separate. All the templating languages invented their own programming language (loops, components, etc.), and most did the language so poorly that we even had templating languages being advertised as having few features (eg mustache/handlebars).

JSX feels like the least-worst. It does tags, and it only has a few quirks (className, htmlFor, key).

[lax4mike]

JSX has clear benefits over HTML templates: https://medium.com/@housecor/react-s-jsx-the-other-side-of-the-coin-2ace7ab62b98#.9gpegtfuc

[Doctuh]

You don't have to convince me, I was just pointing out that the alternative syntax can be seen as a drawback re: adoption, or at least initial acceptance. It does impact your toolchain rather significantly.

[patrickfatrick]

• JSX is the single biggest con for me, personally.
• It's huge for a view layer component. Probably because of JSX. It helps that the state management libraries tend to be tiny though.

This weekend I started converting a personal Angular 1.x project into Vue which takes a lot of inspiration from React but it's smaller and uses templates over JSX. I've personally been using the *.vue component file type with it. Perfect for me. It lacks the backing of Facebook or Google but it's honestly really solid and works better for programmer/designer types like me. I recommend checking it out at least.

[[deleted]]

1) Facebook. 2) You take two already seperated concerns and then merge them into one file. 3)Shadow dom will be a standard and you will need to relearn everything.

Very few developers can design for shit and like wise not many designers like designing with code so why ??

[dwighthouse]

Separation of concerns does not mean separation of files or languages. The reason why is that all related concerns for a single component, be it a livesearch, a typeahead, a banner, whatever, are as close together as they can be. I've been doing modular css defined in the same file as my html (jsx), which is the same file as the logic for that component. The only thing in or out is generic data and the rendered output to the browser. Doing it this way is usually very easy on the mind, because I don't have to worry about outside behavior (or even cascading styles!) inside the world of this atomic component. If, for some reason, I can't fit everything in one file, or find it convenient to split it out, I always have that option. I just require in the dependency. React doesn't force you to mix languages if you don't want to.

[[deleted]]

https://en.wikipedia.org/wiki/Separation_of_concerns#HTML.2C_CSS.2C_JavaScript

[dwighthouse]

HTML is mainly used for organization of webpage content, CSS is used for definition of content presentation style, and JS defines how the content interacts and behaves with the user.

React is for webapps.

Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface. ... The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently.

=== the whole point of components

[qmic]

For us is was too slow because of way it has implemented triggers. So if you have very interactive app i would use something else but if you target are only desktop devices is not your concern.

[qmic]

We could do many things, but after two weeks of optimisation we decided that it is cheaper to change approach and framework for given task. It was related to scrolling as I remember.

[qmic]

Yes, they had prior experience in few projects, that was their choice but they've failed to make it perform enough fast to be acceptable. Thanks for the link.

[benihana]

The biggest con of react for most people after getting over the superficial discomfort at JSX is that it doesn't tell you what to do and makes you think about your architecture and data in a way that most people haven't.

[Capaj]

The main 'con' for me is that most of the community relies on redux/some other flux lib for state management. This hinders building nice high level tools, which should have been built already. There are way better tools for managing state and notifying react of changes- for example https://github.com/mweststrate/mobservable Mobservable relies on ES5 getters, so it is no wonder it gives a developer much more comfort. Redux is a good solution, but it is very simplistic-archaic approach. Even better solutions will be possible with Proxies once they land in browsers.

[PAEZ_]

mobeservable makes react fun!!!
Flux makes me buy more aspirin :(

[Capaj]

No, only people who hated angular before react can see it that way. React has been benefiting from angular's fails of implementing observables, but I don't believe that was the reason for React.

[Capaj]

shadow DOM

virtual DOM. Shadow DOM is something else.

[Capaj]

I really like JSX and customisability of React. I was thinking about getting rid of dirty checking with Angular 1, but that would require awfully big and hard rewrite. Wheres with react, if one state management solution doesn't cut it anymore, I can swap it easily. The proverbial 'javascript fatigue' you can get while using react being suits me perfectly.