What are the problems with ReactJS? Summary of reactjs problems

This article mainly introduces some problems that have arisen about reactjs, and points out some disadvantages of using reactjs now. Interested students can come and read this article

Background introduction

In April last year, I came into contact with ReactJS for the first time in a client's project.

I found that ReactJS is much simpler than the AngularJS I have used before. It provides responsive data binding functions and maps data to web pages, allowing me to easily implement a website with simple interactions.

However, as I use ReactJS more and more deeply, I find that it is difficult to write interactive and complex web pages with ReactJS. I wish there was a way to solve simple problems as easily as ReactJS. In addition, you must be able to solve complex problems simply.

So I rewrote ReactJS in Scala. The amount of code dropped from nearly 30,000 lines to more than 1,000 lines.

The TodoMVC application implemented using this framework only uses 154 lines of code. TodoMVC, which uses ReactJS to implement the same function, requires 488 lines of code.

The picture below is a TodoMVC application implemented using Binding.scala.

This framework is Binding.scala.

Problem 1: ReactJS components are difficult to reuse in complex interactive pages

The smallest reuse unit in ReactJS is the component. ReactJS components are lighter than AngularJS Controller and View. Each component only requires front-end developers to provide a render function to map props and state to web page elements.

Such lightweight components are useful when rendering simple static pages, but if the page is interactive, callback functions must be passed between components to handle events.

I will discuss it in "More than React (2) Components are harmful to reusability?" 》 uses native DHTML API, ReactJS and Binding.scala to implement the same page that needs to be reused, and introduces how Binding.scala can easily implement and reuse complex interaction logic.

Problem 2: The virtual DOM algorithm of ReactJS is slow and inaccurate

The page rendering algorithm of ReactJS is the virtual DOM difference algorithm.

Developers need to provide the render function to generate virtual objects based on props and state DOM. The ReactJS framework then creates a real DOM with the same structure based on the virtual DOM returned by render.

Whenever state changes, the ReacJS framework re-calls render Function, get new virtual DOM. Then, the framework will compare the differences between the last generated virtual DOM and the new virtual DOM, and then apply the differences to the real DOM.

This has two major disadvantages:

<li>

Every time state changes, the render function must generate a complete virtual DOM. Even if the state change is small, the render function will be completely calculated. If the render function is very complex, this process will waste a lot of computing resources.

<li>

The process of comparing virtual DOM differences in the ReactJS framework is slow and error-prone. For example, if you want to insert an item <li> at the top of a <ul></ul> list, the ReactJS framework will mistakenly think that you have modified is <li>, and then a <li> is inserted at the end.

This is because the old and new virtual DOMs received by ReactJS are independent of each other. ReactJS does not know what operations have occurred on the data source and can only determine based on the old and new virtual DOMsGuessThe operation that needs to be performed. The automatic guessing algorithm is both inaccurate and slow. Front-end developers must manually provide the key attribute, shouldComponentUpdate method, componentDidUpdate method or componentWillUpdate Waiting for methods can help The ReactJS framework guessed it right.

I will discuss this topic in "More than React (3) Is Virtual DOM Dead?" "Compares the rendering mechanisms of ReactJS, AngularJS and Binding.scala, and introduces the simple and high-performance Binding.scala precise data binding mechanism.

Problem 3: The HTML template function of ReactJS is neither complete nor robust

ReactJS supports writing HTML templates with JSX.

Theoretically, front-end engineers only need to copy the static HTML prototype into the JSX source file and add some variable replacement codes to transform it into a dynamic page. In theory, this approach is more suitable for reusing HTML prototypes provided by designers than frameworks such as Cycle.js, Widok, and ScalaTags.

Unfortunately, ReactJS’s support for HTML is incomplete. Developers must manually replace the class and for attributes with className and htmlFor, as well as the inline styleThe style can be changed from CSS syntax to JSON syntax before the code can run. Under this development method, although front-end engineers can copy and paste the HTML prototype into the code, it still requires a lot of modifications before it can actually run. It doesn't save you much compared to Cycle.js, Widok, or ScalaTags.

In addition, ReactJS also provides a propTypes mechanism to verify the legality of the virtual DOM. However, this mechanism is also full of loopholes. Even if propTypes is specified, ReactJS cannot detect errors in advance before compilation. Only projects with high test coverage can verify that each component uses other components. Even if the test coverage is high, propTypes still cannot detect misspelled property names. If you write onClick instead of onclick, ReactJS will not report errors, which often causes developers to spend a lot of extra time troubleshooting a very simple bug. (If you want to see more, go to the PHP Chinese website React Reference Manual column to learn)

I will be in "More than React (4) Can HTML also be compiled? "Compares the HTML templates of ReactJS and Binding.scala, and introduces how Binding.scala can statically check syntax errors and semantic errors while fully supporting XHTML syntax.

Question 4: ReactJS requires complex asynchronous programming when communicating with the server

The architecture of ReactJS when loading data from the server can be seen as the MVVM (Model–View–ViewModel) pattern. Front-end engineers need to write a database access layer as the Model, using ReactJS's state as the ViewModel, and render as the View. Model is responsible for accessing the database and setting data to state (i.e. View Model), which can be implemented using Promise and fetch API. Then, render, that is, View, is responsible for rendering the View Model is rendered to the page.

In this entire process, front-end programmers need to write a large number of asynchronous processes composed of closures. The code for setting and accessing status is scattered everywhere. If you are not careful, bugs will appear, even if you handle all kinds of things carefully. Asynchronous events can also cause programs to become complex, making them difficult to debug and maintain.

I will explain in "More than React (5) Why not use asynchronous programming?" 》Compare the data synchronization models of ReactJS and Binding.scala, and introduce how Binding.scala can automatically synchronize server data and avoid manual asynchronous programming.

Conclusion

Although Binding.scala looks a lot like ReactJS at first glance, the mechanism hidden behind Binding.scala is simpler and more versatile, and is completely different from ReactJS and Widok.

So, by simplifying the concept, Binding.scala is more flexible and can solve complex problems that ReactJS cannot solve in a general way.

For example, in addition to the above four aspects, the state management of ReactJS is also a long-standing and difficult problem. If a third-party library such as Redux or react-router is introduced to handle the state, the architecture will become more complex and the layers will become more layered. , the code goes around and around. Binding.scala can use the same data binding mechanism as page rendering to describe complex states. It does not require any third-party libraries and can provide server communication, state management and URL distribution functions.

The functional differences between the above Binding.scala and ReactJS are listed in the following table:

##ReusabilityMinimum reuse unitMethodComponentDifficulty of reuseEasy to reuse regardless of interactive content or static content Easy to reuse static content components, but difficult to reuse interactive componentsPage rendering algorithmAlgorithmAccurate data BindingVirtual DOMPerformanceHighLowCorrect Automatically ensure correctnessRequires developers to manually set the ##OthersHow to assign URLs or anchor linksSupport using URLs as ordinary bind variables without the need for third-party libraries.

		Binding.scala	ReactJS
		Binding.scala	ReactJS
			key attribute, otherwise complex pages will be messed up.
HTML template	Syntax	Scala XML literal	JSX
	Whether to support HTML or XHTML syntax	Complete support for XHTML	Incomplete support. Normal XHTML won't compile. Developers must manually replace the class and for attributes with className and htmlFor, as well as the inline style Style from CSS syntax changed to JSON syntax.
	How to verify template syntax	Automatic compile-time verification	Passed at runtime propTypes Verification but cannot be detected Simple of spelling errors.
Server communication	Mechanism	Automatic remote data binding	MVVM asynchronous programming
	Difficulty of implementation	Simple	Complex
		Not supported, third-party library react-router is required
	Functional completeness	Complete front-end development solution	itself Contains only view functionality. Additional mastery of third-party libraries such as react-router and Redux is required to implement a complete front-end project.
	Learning Curve	The API is simple and easy to understand for people who have never used Scala	Get started quickly. However, the function is too weak, which leads to a steep curve when learning third-party libraries later.

More than two months ago, when I released Binding.scala on the Scala.js forum, the most popular responsive front-end programming framework in the Scala.js community at that time was Widok. Tim Nieradzik is the author of Widok. After seeing the framework I released, he praised this framework as the most promising one in the Scala.js community. HTML 5 rendering framework.

He was right, two months later, Binding.scala has now become the most popular responsive front-end programming framework in the Scala.js community.

The Awesome Scala website compared Scala's responsive front-end programming framework. Binding.scala is more active and popular than other frameworks such as Udash and Widok.

This article ends here (if you want to see more, go to the PHP Chinese website React User Manual column to learn), if you have any questions You can leave a message below to ask questions.

The above is the detailed content of What are the problems with ReactJS? Summary of reactjs problems. For more information, please follow other related articles on the PHP Chinese website!