Why You Shouldn’t Use ReactJS for Complex Projects
infoq.com
infoq.com
The author writes off solutions such as Redux which are designed to solve nearly all of the "problems" the author assigns to React because they add extra layers to the application, however in reality, separating your data and your views is EXACTLY the point - that's what helps to make complex applications manageable.
The article is really an advertisement for the authors own framework Binding.scala, rather than a critical look at React.
You tell React that you'd like to Render component X inside DOM element Y, and that's really all React does. There's no architecturing your project around React.
[1] https://facebook.github.io/react/docs/react-component.html
Yes, if use react, you need an architecture compatible with the reactive paradigm.
You call a library.
A framework calls you.
I don't know React, so can't say which it is.
On the flip side, it's nowhere near as all-encompassing as Angular or Ember. No built-in AJAX handling, no complex data model manipulations, no preferred project architecture. So in that sense, it's much closer to the library side of things.
People[1] who were there when it started seem to be OK with calling it framework:
http://queue.acm.org/detail.cfm?id=2994373
[1]Pete Hunt, who at the time was an engineering manager at Instagram as well as one of the more prominent members of Facebook's React core team, is willing to shed some light on React's beginnings.
Also helping to tell the story is Paul O'Shannessy, one of the first engineers at Facebook to be dedicated to React full time.
I'm not sure how I feel about this. One one hand he's clearly biased. On the other hand, for a new project if he doesn't promote it no one will. It's important to market your product even if that product is an open source project.
Although if this was a serious journal or newspaper there would be a very clear disclaimer somewhere. Which is lacking in this article.
A number of the comments about React are very overstated or overblown. For example:
> Since the two versions of virtual DOMs are mutually independent, the React framework has no idea about what is going on in data sources, randomly guessing processing operations depending on just these two DOMs. This kind of algorithm is extremely slow and inaccurate.
In reality, unless the component tree is dramatically changed (such as changing to an entirely different screen), the new VDOM contents are likely to be almost identical to the previous contents. React makes a number of educated assumptions about the structure of a VDOM tree to efficiently diff the changes. That does take processing time, but saying it is "slow and inaccurate" is just silly.
Ultimately, this article seems to be mostly about bashing React and trying to sell the author's Scala HTML bindings library instead.
Wrong. And if you think the correct answer is "function" then you are wrong as well. The answer is: an Element. A pure, immutable value representing a React element. Example: const myReusableDiv = <div />;
> Developers have to manually replace class and for attributes with className and htmlFor.
So? It's just syntax. You can teach that, along value interpolation and everything that a designer might need to be able to make changes to templates, in less than five minutes to someone who only knows HTML.
> [talking about propTypes]. Yet this mechanism is full of holes.
So is JavaScript. Nothing to do with React. Scala is better, obviously. Any statically typed language is better at that. And there even are languages which are better at that than Scala.
If you are all like 'lol JS has no types, look at my fancy Scala code' then I'll smack you with my Haskell ADTs. And then somebody from the Agda or Idris camp joins and gives you a taste of dependent types.
> [how async programming is bad]
Nothing to do with React. React is just for rendering the UI. How you manage the data is entirely up to you.
Gave me a good chuckle... But on a serious note, at least the author is providing a programmatic solution to the problem, albeit being framed rather one-sidedly.
typeof <div /> === "object"
If you have a 'complex project' you are going to need more than just ReactJS. It's like saying Handlebars templating is no good for large projects.
The reusability of components in a large project, and specifically the issues the author points out about interactivity between components, isn't supposed to be done in react, you're supposed to have a data (store) layer which manages the state of your components. This means the component itself is essentially just an template for your output.
He also seems to believe that React is framework when it's a library, if his knowledge of React is so shallow that he didn't even read the first sentence on the React website I can't take his opinions on it seriously.
I don't like these kinds of articles which are only thinly veiled advertisements that do not offer any thoughtful criticisms, what I would really like is to hear from someone who has actually worked on a huge project which includes React and what troubles if any they ran into.
> However, after a few weeks, as I became more skilled in React
Do it for a year and a half and I'll accept your criticism. A few weeks is not enough time to claim enough expertise to be making the claims the article makes.
I'm not quite sure how using "className" vs "class" materially affects a complex project.
propTypes are pretty shallow in terms of checking, but I've seen them more as something third party components should provide as metadata/documentation rather than replacing a type system. Large project should rely on Flow or TypeScript if they're worried about typings.
I'm not sure I follow the complaints against asychronicity? Maybe when dealing with improperly complex components it becomes tricky and that I think takes experience to get a feel for.
Additionally, if we're comparing what appears to me to be a synchronous two way binding pattern to React, I think it's really just a matter of choosing the wrong technology for a given preference. React and the omnidirectional data flow pattern are directly opposed to that.
I found this argument pretty confusing at first too. I think since the author is familiar with Scala he may be used to the Actor style of async programming used heavily in the Akka framework that abstracts most of the hard to understand control flow away from the programmer (http://doc.akka.io/docs/akka/2.4/scala/actors.html).
It's a valid complaint, but as long as Javascript is the only choice for developing on the web we don't really have an alternative.
> Apparently, Binding.scala is more flexible and powerful. We can use Binding.scala to solve complicated issues that React cannot.
How did the author come to this conclusion?
He only complained about issues he saw in React, he didn't really compare them to how it would work in binding.scala. I'm sorry, but I find this post a badly written example of `software A is bad and therefore you should use software B, even though it is not examined critically`
*edit: formatting
"Issue 1: React components are difficult to reuse in complex interactive web projects.
Such a lightweight component is very handy in rendering plain and static webpages. Nonetheless, when there are interactions between one component and another, passing callback functions as parameters are inevitable. Particularly for webpages with complicated structures, we have to nest dozens of components from the inside-out, where those callback functions are passed through from parent to child components across layers and layers. The only outcome for applying React framework in complex interactive web projects is that the codebase would become too messy to maintain."
Out of the box React is relatively spartan, which is great for small projects. At scale it only really comes into its own when used in conjunction with other things such as Redux and its wonderful ecosystem of middleware.
In this kind of situation, I would advise using something like Redux and following the advice of Dan Abramov (Redux creator). He wrote a wonderful article on how to split functionality between components and containers:
https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
I think this is a great pattern to follow for larger scale projects.
"It is well-known that React is a great tool for implementing simple interactive websites, but how does it apply on complex interactive front-end projects?"
Facebook seems like a pretty complex website to me and they are all in on React.
As to his points about the virtual DOM performance, I'd love to hear a more experienced web dev chime in on that as my area of expertise is native development.
> As to his points about the virtual DOM performance, I'd love to hear a more experienced web dev chime in on that as my area of expertise is native development.
His example of an <li> with a <ul> is wrong. Setting that aside..
Depending on the operation and the browser, you can do anywhere between 2000-100000 more operations per second in a virtual DOM than in the browser DOM.
The complaint that complex render functions are wasting precious resources is valid, which is why documentation makes it very clear that these functions should be as simple as possible and produce no side effects. Remember - library, not a framework.
Additionally, it belies the question of - why are you writing a complex render in the first place. In a well-structured app, components would be reasonably small and render functions relatively simple, for varying definitions of 'relatively.' That is, you aren't doing complex number crunching in the render. When I do React perf optimization, one of the most common errors I see people make is have render functions full of complex logic and branching render paths. If you are doing that, your component can be further broken down.
Apparently Facebook is built on over 100,000 individual React components. Damn.
"For example, besides the four facets above, the state management problem of React is non-negligible. If we introduce a third-party library such as Redux to deal with the state, the framework would become tangled and the number of layers would increase."
Given how widely used Redux is with React I would have expected him to expand on this point some more and provide a meaningful critique. It's a shame that the other parts of his series have not yet been translated into English. Perhaps he elaborates on what he means by the above statement.
> ... if you wanted to insert <li> on the top of a <ul> form, then the React framework would misjudge that you modified all components of <ul> and appended <li> at the end.
Yes, that will happen ... but only if you don't assign a key property to each of the `<li>`s. React uses the key prop to uniquely identify nodes that were actually changed versus ones that were just moved around among their peers. So if you're dynamically creating lists of nodes of the same tag type, you really need to be giving them a unique `key`.
Also, it's not a framework, it's a library. A framework calls your code, a library gets called by your code. With React you call `ReactDOM.render` or similar.
Does anyone have any tips for avoiding this extremely irritating 'props-nesting' (as I like to call it)? I'm pretty new to React, and the one thing that's bugging me about it is that in more complex UI (for example, a toolbar that independently controls a nested component), is how you can't just go through a top-level component directly; you have to go all the way up and down the chain. This gets very messy once you decide to change some of the intermediate components fundamentally.
Vanilla Redux is quite obtuse. I prefer Jumpstate, which makes it much more declarative. https://github.com/jumpsuit/jumpstate
I have built some fairly sophisticated applications in React and never pass props down more than one level. Like anything else, doing this well requires discipline. The author of the article appears to be complaining that React isn't a silver bullet.
It really depends on what you're trying to do, but it really comes down to storing state and data in a central location.
If it's a simple component, passing the on click callback to a child that updates the parent master state is pretty straightforward. So for example selecting an item in a list and updating the active item when a list item is clicked.
If it's a really deeply nested component though, that can get a bit harder. I've had some success passing simple string values via the context reference, which makes the values accessible to all the children.
Another pattern I've used is having a state store similar to the flux pattern using eventemitter. I'm using this pattern a lot on thebigpicture.io for the editor page. There's two main columns in the page that are very deeply nested, so I created a separate state store and individual components are able to listen to changes from different events.
My main problem with React is that it's more complicated than it needs to be - If following an architecture like Redux, you often end up with long complex chains of reducers and components which makes the logic very hard to follow - Especially if you like to split up your code across multiple files.
There are few things worse than having 10+ files open at the same time and having to figure out which one(s) is/are the cause of your problem.
"For example, besides the four facets above, the state management problem of React is non-negligible. If we introduce a third-party library such as Redux to deal with the state, the framework would become tangled and the number of layers would increase."
I like Redux but I think the actions/reducers structure can be a little cumbersome to follow at first.
Instead of reasoning in one file, now you have to reason through half a dozen. Poorly set up actions/reducers will _stay_ cumbersome to follow, and aren't appropriate for every application.
However, none of it's problems are due to react.
https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
A lot of the work I'm doing right now is in a reasonably complex react native app with multiple screens. In that context its worth the added boiler plate. I wouldn't use it for a one or two screen app with little shared state.
And a particular comment about asynchronous programming - ALL JavaScript requires async programming and you need to know how to properly handle it no matter what you are programming.
http://www.stefankrause.net/js-frameworks-benchmark5/webdriv...
As a result, Binding.scala is fast when k < n (aka partial updating), even faster than vanillajs written by a common human for some cases. Check the rows "partial update", "select row", "swap rows", "remove row" in the benchmark.