More Than React: Why You Shouldn’t Use ReactJS for Complex Interactive Front-End Projects, Part I

Jay Taylor's notes

back to listing index

More Than React: Why You Shouldn’t Use ReactJS for Complex Interactive Front-End Projects, Part I

[web search]

Original source (www.infoq.com)

Tags: javascript react scala.js complainers thoughtworks www.infoq.com

Clipped on: 2017-02-19

Exclusive updates on:
& Design
Architecture

Enterprise Architecture

Scalability/Performance

Design

Case Studies

Microservices

Patterns

Security
Featured in Architecture & Design

Jonas Bonér on the Actor Model, Akka, Reactive Programming, Microservices and Distributed Systems
|
Read later
My Reading List

Key Takeaways

ReactJS components are difficult to reuse in complex interactive web projects.
ReactJS’s Virtual DOM algorithm is time-consuming and imprecise.
ReactJS’s HTML templates are neither complete nor powerful.
ReactJS requires complicated asynchronous programming while communicating with the server.
Binding.scala has less concepts but more features. The promising Binding.scala solves complicated issues that ReactJS cannot.

(Editor’s note: This five-part series was originally published in Chinese on the Chinese edition of Insights and on InfoQ China.)

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? Does it function as well as it did in simple interactive websites?

In this article, I will introduce several problems that I encountered using React during program development and why I decided to develop a new framework in Scala to compare with React. Surprisingly, the amount of code was approximately 1000 lines, while there were roughly 30,000 lines in React.

Background

Node.js Performance Cheat Sheet

A Data Application to Foretell the Next Silicon Valley

Get started with Data-Driven, Intelligent Apps with SQL Server

The Ultimate DevOps Toolkit

Guided Tour: AppDynamics Application Performance Management

Related Sponsor

Firts of all React is not a full stack web framework.
It's just a "view" part of Model View Whatever concept.
Thus first and last cons of this reading is not related to react.

One should use some data flow manipulation means in conjunction with react when building big apps.
A good example is Redux based on FB Flux approach.
There a "service" diapatch function is available for every component and you can avoid cluttering components with passing callbacks.

Async logic can be easily implemented using redux-saga with them utilizing es6 generators.
It allows to describe the flow of a certain action as synchronized one: do some preparation, send request, wait on success, update your state, do smething else, quit.

Problems with class name and for attrs in JSX is not a real issue I would say.
While as flow typing is still indeed immature we use FB flow type to cover whole app.
And inline styling I would say is bad approach anyway because we ptefer to store and load style to/from CDN via CSS classes.

As for React's Dom comparing algorithm we do experience some problems.
You always have to keep in mind how many rendering cycles you would trigger performing some data manipulation.

To sum up:
Two of four cons of the article are irrelevant to React because data manipulation infrastructure is out of the React's scope.
JSX templates are a good fit even for big apps.
And React's vertual DOM algoriths should be improved indeed.

More on React Feb 09, 2017 05:15 by Charanjeet Kaur

Issue 1: React components are difficult to reuse in complex interactive web projects.
As also mentioned in previous commit, we can "subscribe" to actions than having to pass the callback functions. And, this is easy with redux.
www.ctheu.com/2015/02/12/how-to-communicate-bet...

Issue 2: React’s Virtual DOM algorithm is time-consuming and imprecise.
I am interested in learning more on this and will spend time in understanding how binding.scala solves it. As per my understanding, comparing two versions of the DOM is done by matching shallow copy. Here, it's required that developers are careful not to mutate the data.
facebook.github.io/react/docs/optimizing-perfor...

Issue 3: React’s HTML templates are neither complete nor powerful.
I agree that html is not directly usable with react. What we do is to look into material ui like UI frameworks to look for UI requirement. And, that reduces the development time. We avoid inline CSS. I haven't yet explored Cycle.js, Widok or Scala Tags. It seems like a good time to do so :)

In addition, Typescript is said to be syntactically and semantically analyzing the code. I am interested in learning more on how binding.scala can do it at compile time!

Issue 4: React requires complicated asynchronous programming while communicating with the server.
async api calls are super easy with redux. We just need to call a promise. I don't see a flaw here.

I have used flux before. I faced the problem of async api calls there. We are currently working on redux. It is easy to understand and, I have experienced dramatic reduction in lines of code. I find the learning curve of redux shorter than flux.

Re: More than react misgudge Feb 09, 2017 08:51 by Yang Bo

We understand the benefits of React/Redux/Promise/generator's tech-stack you mentioned, and we realize that it helps developers on some point. I am sure you feel "be easily implemented" or "good" when you compare React stack with your original jQuery or other development experience.

However, this series of articles are comparison between React stack with Binding.scala. React is good, but we thought it is not good enough when comparing with our framework, Binding.scala.

We will reveal how to resolve the problems mentioned in this article, with the help of Binding.scala, resulting simpler design and abstraction, which is 3X or 4X less code than React tech-stack.

I appreciate your feedback on this article. I hope you would keep your attentions on the rest incoming articles and see if they answer your questions.

Re: More on React Feb 09, 2017 08:59 by Yang Bo

Issue 1: React components are difficult to reuse in complex interactive web projects.
As also mentioned in previous commit, we can "subscribe" to actions than having to pass the callback functions. And, this is easy with redux.
www.ctheu.com/2015/02/12/how-to-communicate-bet...

I will introduce another way to capsulate callbacks as bindable values in the part 2 article of this series. After you read the article, you will find out if the redux way is easy enough.

Re: More on React Feb 09, 2017 09:08 by Yang Bo

Issue 2: React’s Virtual DOM algorithm is time-consuming and imprecise.
I am interested in learning more on this and will spend time in understanding how binding.scala solves it. As per my understanding, comparing two versions of the DOM is done by matching shallow copy. Here, it's required that developers are careful not to mutate the data.
facebook.github.io/react/docs/optimizing-perfor...

Regardless how React update real DOM, React continuously builds the entire virtual DOM for a component, whenever its state changes. This can be avoid by compiler-time analyzation on HTML template. Binding.scala's compiles one HTML templating function into small piece of functions. As a result, only a small part of code is reevaluated when the data source change.

Re: More on React Feb 09, 2017 09:09 by Yang Bo

Issue 3: React’s HTML templates are neither complete nor powerful.
I agree that html is not directly usable with react. What we do is to look into material ui like UI frameworks to look for UI requirement. And, that reduces the development time. We avoid inline CSS. I haven't yet explored Cycle.js, Widok or Scala Tags. It seems like a good time to do so :)

In addition, Typescript is said to be syntactically and semantically analyzing the code. I am interested in learning more on how binding.scala can do it at compile time!

Enjoy it!

Re: More on React Feb 09, 2017 09:18 by Yang Bo

Issue 4: React requires complicated asynchronous programming while communicating with the server.
async api calls are super easy with redux. We just need to call a promise. I don't see a flaw here.

I have used flux before. I faced the problem of async api calls there. We are currently working on redux. It is easy to understand and, I have experienced dramatic reduction in lines of code. I find the learning curve of redux shorter than flux.

There is other approach than promise.then(), even in JavaScript world.

Binding.scala's remote data-binding is like react-refetch in concept, except its API is 10X smaller and more general.

Please wait for the last article in this series.