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.

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.

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.

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.

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.

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.

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.

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.

This e-book breaks down the various foundational components that build up the transition to DevOps within an enterprise. It also introduces the continuous life cycle that maintains the integration and collaboration needed to deliver an exceptional end user experience with your applications.

As Java applications become more distributed and complex, finding and diagnosing performance issues becomes harder and harder. Download this eBook and learn how to troubleshoot and diagnose some of the most common performance issues in Java today.

Sponsored by

In this interview, Anil Gaur sheds some light on Oracle’s Java EE strategy and roadmap. He describes how the platform will evolve to support the cloud, comments on the future of the Microprofile.IO, and explains why Java EE 8 is being delayed until the end of 2017.

Online businesses need a fraud prevention solution that can detect many different types of fraud and is effective across multiple channels. Learn how the right fraud prevention system can help businesses reduce fraud losses, lost sales, fraud review costs, and chargebacks.