there have been various disputes over front-end framework for a long time. The most controversial items are the following two: performance dispute dispute over API design for example, emerging frameworks come up with benchmark to prove their excellent runtime performance, and React is usually at the bottom of these benchmark . in the API design, Vue enthusiasts believe that "more API constrains developers and will not cause significant differences in code quality due to differences in the level of team members." and React enthusiasts think: " Vue a large number of API limits flexibility, JSX yyds". the above discussion boils down to the trade-off between framework performance and flexibility. this article introduces a state management library called legendapp , which is very different from other state management libraries in terms of design philosophy. rational use of legendapp in React can greatly improve the runtime performance of the application. but the purpose of this article is not just to introduce a state management library, but to share with you changes in framework flexibility as performance improves. performance optimization of React It is an indisputable fact that the performance of React is really not very good. The reason is the top-down update mechanism of React . with each status update, React traverses the entire component tree first, starting from the root component. since the traversal mode is fixed, how do you optimize performance? The answer is looking for subtrees that can be skipped when traversing . what kind of subtree can skip traversal? Obviously a subtree of that hasn't changed. in React…

there are three front-end framework concepts that are easily confused: responsive updates unidirectional data flow Bidirectional data binding before continuing with this article, readers can think about whether they clearly know the meaning of the three. these three are easy to be confused because although they belong to the same front-end framework, they are not the same level of abstraction, so it is difficult to compare them directly. this article will explain the differences between these three levels of abstraction. responsive updates responsive update is also called fine-grained update . At the same time, the recently popular concept of Signal describes responsive updates . In a nutshell, responsive update describes the relationship between state and UI , that is, how state changes map to UI changes . consider the following example (from what are signals article): function TodoApp() { const [todos, setTodos] = useState( [{ text: 'sleep', completed: false }] ) const [showCompleted, setShowCompleted] = useState(false) const filteredTodos = useMemo(() => { return todos.filter((todo) => !todo.completed || showCompleted) }, [todos, showCompleted]) return ( <TodoList todos={filteredTodos} /> ) } in the TodoApp component, two states are defined: to-do todos whether to show completed items showCompleted and the state derived from the above state filteredTodos . Finally, the & lt;TodoList/> component is returned. if the state of todos changes, how does UI change? That is, how do we know the scope of influence of state changes ? At this point, there are two ideas: push ( push ) pull ( pull ) the principle of push We can start with the changing…