React Sucks
An objective analysis of React and why developing with it sucks for the majority of projects.
- Home
- React Sucks
A High Level View Of Reacts History And Architecture
Facebook's Huge User Base
React was created by Facebook to solve a very specific challenge. They have a huge user base, close to 3 billion at the time this
article was written. With a user base like that it is absolutely critical to push as much of the processing of the
user interface code to the client. 3 billion users means 3 billion client machines, which should scale just fine. If Facebook
was a server side rendered application, say like PHP or Spring MVC, they would have to have many more servers to render
all that server side HTML. This would be significantly more expensive for them. Instead they push much of the processing down to their customers machines.
The React Solution
The React solution is to cache all the layout/HTML embedded in javascript and download it onto the browser, when the user first logs in. That way,
after the initial loading of the application,
when the user navigates between views, the browser only has to pull down new data from the servers and does not have
to redundantly pull down layout. This architecture saves a lot of the server side processing involved in rendering layout.
Unfortunately, the implications of this are that React includes a very large library of javascript as its foundation.
Furthermore, developers have to write a substantial amount of javascript to manipulate this complex library in the process of creating a viable user interface.
In summary, React development is far more complex than classical server side rendered web application development.
The Development Cost Tradeoff
So, the React solution saves Facebook tons of money because they have 3 billion users and the extra cost and maintenance
of a highly complex web application framework is offset by the money saved in server processing time.
However, like all programming fashion trends everyone wants to jump on the React bandwagon because what is good for Facebook must be good for
every situation right? Actually no, because just like Angular, React is so much more complex than traditional web application development
that it, sorry to say, sucks for developers. In my experience coding and maintaining a React application is at least 10 times more
expensive than Spring MVC. I want to emphasize MAINTENANCE, because the pain does not stop when you have your first release.
The sphagettifest of typescript will cause you endless pain from that point on. If you have 3 billion users of course this pain is worth every
penny, but if you have 3000 users or 300,000 users you are better off with something closer to classic web architecture.
One day someone needs to do a study and
create a graph of at what user base size React becomes worth it, but it would of course be a very hard data set to get the real numbers on.
However, my point being that React is totally not worth it even for something like a regional bank web application.
Your user base has be huge before you should even consider using it, but that doesn't stop almost every company from thinking
that everything they write has to be in this latest hottest architecture. That is what really sucks.
Angular is another framework that has exactly the same issues. Will someone, some day, invent a framework with all the benefits
and not the trade off. We can only hope but that hasn't happened yet, so make sure you have all the facts before jumping on the latest trend train.
The wrong decision could cost your company millions.
How Does WebRocketX Compare?
WebrocketX doesn't have all the server side processing reducing benefits that React has but it still is a big improvement over classic full page
refresh architecture. The fact that much more of the browser state is cached and that smaller parts of the page are rendered means that it greatly
reduces server side processing. Another fascinating thing about WebRocketX is that by facilitating more targeted smaller transactions
it makes the web application code simpler and easier to maintain, not more complex. So, it is more efficient and less complex than full page web application
development, and it does not have the ugly server side processing reduction to coding complexity trade off that both React and Angular have.
React Sucks For Developers As The Following Points Show
Now that we have laid out some perspective, it is obvious that React is the right solution for Facebook. That being said let's go over in detail
what makes React a less than optimal environment for developers, and therefore not worth it for smaller user bases.
Keep in mind that developer time is expensive, so pain for developers equals pain for the company.
Unlike the article Angular Sucks I won't go into the full analysis of what makes a good web application development environment
because I don't want to repeat that entire thought process. Instead I will go through Reacts pain points and by reading both articles the reader
can put the pieces together.
I hope this has shed some light on what a developer has to wade through when developing in React. Below are some more links that might be helpful.
React is not intuitive or easy to learn. I took an online Udemy course with a very good instructor,
Maximillian Schwarzmüller and the course is 55.5 hours! This course goes really fast and assumes years
of previous web development experience. React is harder to learn than Angular and Angular was no picnic.
There is nothing intuitive about React. Like Angular it involves retrofitting a linked memory tree
of javascript objects on top of the DOM that are tasked with keeping the DOM up to date. Developers no
longer just have to only render HTML and possibly do some DOM manipulation client side with javascript,
but instead have to understand the entire complex lifecycle of React architecture.
The most deceptive thing ever said about React is that React is "Just Javascript". Correction, React is written in Typescript and TSX. If you did want
to write React in something close to javascript you will need to go back to Legacy React (not maintained anymore)
which has completely different syntax, and you will also still write JSX which also isn't javascript. JSX is an ugly
mish mash of javascript, html, and React specific syntax. But why would you go use the old unsupported version anyways?
The entire React transpile process completely defeats the purpose of using a script language. Since you have to
build the code before running it and as a part of this process it gets transpiled multiple times (typscript, to javascript, to javascript wrapped in React framework javascript)
it then comes out in a form completely different than what you wrote.
It might as well be compiled into binary. Furthermore, your code will be executed
according to the complex React lifecycle. All the script language benefits are gone.
Maybe they just should have written it in a real typed language like Java?
A fascinating fact is that prior to Angular, Google developed a framework called the Google Web Toolkit or GWT, which is
a transpiler from Java to javascript for Web Development. It never caught on so they took the ideas from that and created Angular.
React is very similar to Angular so it is interesting that 2 large IT companies went to from a transpiler back to javascript directly,
then almost immediately back to a transpiler, but this time a transpiler of typescript to javascript.
TSX is a congolerate of typescript, html, and React specific syntax, and therefore an incredibly leaky abstraction.
Its trying to be JSP but the separation between what is layout
and what is dynamic is horribly blurred. Furthermore, there are many many special cases for syntax that are work arounds to
weaknesses in its implementation, like the fact that only a single node can be returned in a components layout so they invent this tag
called a fragment so that you don't have to code in extra wrapping divs to make things work. The really "fun" thing is that your
TSX will be compiled into JSX and your JSX will be compiled into "God Knows What". It's certainly not a format that is directly
readable so you had better hope it renders the DOM you want in the end. Trial and error will be your only approach if something doesn't look right.
Try to develop a React application and serve it on something other than a Node server. I dare you, because every example you find will
be coded assuming it is running in Node. Now that your whole application is coded in Node you will also inheret the Node
package.json/node modules
dependency nightmare that node is so famous for.
Since React applications are compiled, a developer cannot by default just refresh the page to see their changes the way they would with html, javascript, php, or jsp.
The Create React App template was created to facilitate a less tedious development environment and make it behave more like a script development environment.
It uses a library call WebPack to put together code into something that can be deployed every time
you make an edit to a file, and also launches a browser with an open socket back to Node that will also refresh its self every time an edit is made.
Without Node and Create React App development is much less efficient, so all of this extra environment becomes compulsory.
Firstly, a new developer of React will struggle with how to even make code run when a page first renders. Pro tip, use the useEffect hook along with the empty square brackets.
If this sounds weird, its because it is weird. Next a new developer will have to figure out how to change data in the layout. Another pro tip, use the setState hook but you
have to declare it ahead of time and dynamically assign the function and variable in some extremely odd syntax. Then when setState method is called keep in mind that the layout
for the entire component is re-rendered even if you are only changing one small part of it, but don't worry React has created a virtual DOM layer that parses the differences
in the update before actually updating the real DOM and then only updates the actual node affected. However, be careful with your syntax because you can inadvertently force
the entire view of this component to update anyways, negating the benefits of the virtual DOM. React is full of this kind of esoteric knowledge and its not easy to find
assistance on the internet or in their own documentation. After all its an open source project so no one is really responsible for making this easy for you.
Web development already comes with a component model, they are called html tags. React creates another component memory model that sits on top of html
and is assigned with manipulating the DOM according to the React lifecycle. Each component functions as a sudo tag which accepts a list of props, the React
equivalent of tag attributes. Information is designed in React to flow through the props of the root tags in a page to the branches of the tree,
one prop relay at a time, literally like the sap flowing through a tree.
This is an extremely tedious way to pass information around a page, so bad in fact that they have already broken their paradigm by creating hooks
that facilitate global variables. The truth is that a normal webpage doesn't need this kind of isolation of every visual element in a page. Only something,
like a Facebook page, with hundreds of elements each doing their own thing, needs this kind of isolation. Once again, Facebook is an edge case that isn't
practical to emulate in an "ordinary" web application.
