You mean besides the one where I learned it and realized I would never use it in production? No, and here is why:
1. There is no adherence to the living standard
2. Web components are meant for this exact purpose
3. The added complexity and burden on the browser runtime will only create headaches as the application begins to scale.
4. There is no clean separation of concerns.
5. Writing HTML in js files is an anti-pattern.
6. The browser runtime, CSS and DOM obviate what React is trying to accomplish, especially with web components being added to the living standard.
7. Browser networking, workers and server-side events are much more powerful ways to scale complexity.
8. CSS3 is not hard to understand.
9. There is no way to bypass the browser's rendering engine.
10. The business scenarios for our software product did not align with the use of React after a very thorough ATAM.
11. Much better technologies exist that do not cross-cut concerns the way React does. Aurelia is what I ultimately recommended because it did not violate points 1-10.
React isn't pragmatic and if anything, the lack of examination of its internals distinctly reflects the zealotry of arguments that oppose reasonable points. Every dissenting argument I have ever encountered, especially the ones on this thread are rationalizations and opinions. I haven't seen one technical advantage that solid software engineering, the browser API, and HTTP do not already provide.
Discussions like this are meant to become arguments based on facts, zealous or not. As always, fact trumps opinion.
Do you mean the HTML living standard? Why would a javascript library be concerned with the HTML standard? What do you mean with this? The HTML output from React certainly complies with the living standard, and it doesn't even have any artifacts now that react-ids have been removed.
If you meant the javascript rolling standards, React pioneered the use of many ES2015 features.
> 2. Web components are meant for this exact purpose
Web components are meant for encapsulation, a problem that React handles fairly poorly. Meanwhile, React's alleged purpose is to handle developing large applications, a problem that web components do not really address.
> 3. The added complexity and burden on the browser runtime will only create headaches as the application begins to scale.
Practically every abstraction adds complexity and "burden" on the runtime - even Web Components! This is an assertion without evidence. There's a contention line between performance and development time that, for web applications, is usually skewed heavily towards the development side. You need to deliver your web applications in a short time frame, and also continually update them. These are the things React alleges it excels at, while also delivering acceptable performance.
> 4. There is no clean separation of concerns.
React has three clearly separated parts, component definitions, VDOM rendering and reconciliation. Which concerns aren't separated?
> 5. Writing HTML in js files is an anti-pattern.
React discourages writing HTML in js files. The standard method of using React does not involve writing HTML, React renders that for you.
> 6. The browser runtime, CSS and DOM obviate what React is trying to accomplish, especially with web components being added to the living standard.
This is just word salad. How does the browser runtime help with developing large applications?
How does CSS? Just look at all the CSS frameworks trying to wrangle the complexity of managing CSS in a large application - from CSS parsers like less and sass to naming styles like BEM, CSS modules, and so on.
The DOM isn't concerned with writing large applications at all, however directly manipulating it is usually a minefield thanks to its API and forced re-renders. Pretty much every JS framework has run away from the DOM.
Web Components don't really tackle the problems building a large application.
> 7. Browser networking, workers and server-side events are much more powerful ways to scale complexity.
I don't know how any of these things help with complexity. They're performance optimizations.
> 8. CSS3 is not hard to understand.
This is not an argument against React, since React components use CSS..
> 9. There is no way to bypass the browser's rendering engine.
Thus, we should never write libraries and frameworks for rendering? What is this even an argument for?
> 10. The business scenarios for our software product did not align with the use of React after a very thorough ATAM.
That's fine, but that's a consideration you make for yourself. It doesn't make React "quite possibly the worst anti-pattern". This is the first reasonable argument you've made.
> 11. Much better technologies exist that do not cross-cut concerns the way React does. Aurelia is what I ultimately recommended because it did not violate points 1-10.
This is possible, I haven't used Aurelia to comment.
React is very pragmatic for me. I've been moving towards data-driven UI rendering ever since I started web development. The components have good lifecycle hooks, unlike angular 1's directives. The VDOM rendering frees me from touching the DOM(a huge plus for me), and I've never had to wrestle with its edge cases(don't really do a lot of animation). The diffing engine makes it absolutely fast enough for any app I've written. The combined coding style(don't store state in the DOM, render the UI from state, take props instead of locating data via global services) is a great fit, I've already tried to enforce all these for my team manually. The documentation is top-notch, there's tutorials for everything. The tooling for it is just great. The debug story just makes me happy. Debugging React apps is a breeze compared to any other app I've had to debug. This is probably the biggest selling point for me. I am willing to go through quite a bit more pain than React causes to get this kind of debugging.
React for me has some fundamental problems, like its small surface area(only handling the view), which means it doesn't solve all my problems. The things I use it for though, I'm really content with.
> This is possible, I haven't used Aurelia to comment.
I took a brief look at the documentation. It appears as though it's a "batteries included" framework favoring convention over configuration, with a custom templating specification a la AngularJS.
The nice thing about React - to me - is the straightforward mapping of Javascript control flow to DOM. You don't have to learn a custom templating protocol in order to render things and it's ridiculously easy to create encapsulated components.
data.map((el) => <div>{el}</div>)
var Foo = React.createClass({render: () => ...});
Gets you <Foo/>
Even less syntax noise if you take advantage of stateless functional components. [0]
Compare this to Angular's ridiculous directive declaration syntax nightmare... cringe :)
Aurelia isn't that much better in this regard [1]
There's a bunch of boilerplate that needs to be introduced for you to create simple custom elements: lots of .bind, <require> tags, separate files for each custom element. Bleh :)
Maybe it's better when you're working with a bunch of developers with bad habits, or have to grok a huge code base. There, I can see some of its conventions and structure coming in handy. Still, I don't see why OP is throwing a hissy fit over it. Everyone has their favorite tools ¯\_(ツ)_/¯
> React for me has some fundamental problems, like its small surface area(only handling the view), which means it doesn't solve all my problems.
I've occasionally, successfully repurposed React to keep track of my AJAX requests. Just create a (<div/>) component for every type and start/cancel the XHRs via componentDidMount() or componentDidUpdate().