At GitHub China’s first official meeting held on September 17, 2019, I shared the theme of the Debate on Breaking the Framework paradigm, and this is the transcript. Beginning of the body —
Around early September, a React Meetup invited Rich Harris, author of the Svelte framework, to do a tech share.
The main thrust of his content is as follows:
In React, Svelte is better than React.
It’s the equivalent of saying open source isn’t a good option on GitHub.
Ha ha, of course, he was joking.
In fact, he was speaking from his own point of view, pointing out what he thought were the problems with React.
You can visit Rich Harris
Slides, it is particularly important to read the remarks section.
As I summarize, Rich believes that the core issues in React are:
The Web, be it DOM, BOM, CSS, JavaScript or WebGL, is full of internal state and imperative style apis, a far cry from the React functional style of abstraction.
The React Team continues to widen the gap between the two.
As a result, while React Hooks are a pioneering and good technology; However, most React developers have trouble understanding and getting used to some of the React Hooks mechanics.
(Rich gave an example of the problematic React Hooks that only about four of the 100 + React developers in the room knew about.)
In this case, React Team still doesn’t see React as a problem and doesn’t try to fix the counterintuitive things that plague developers. Instead, they argued that React developers needed to be educated, gradually adapted to React’s paradigm and thinking, and developed new intuitions.
Also, the React Team is pleased with what they’ve learned over the past four years: Most React developers don’t use the DOM in render functions anymore, and some have forgotten how to use the DOM API.
React Team also has faith in the future of new education.
Rich disagrees, pointing out at the end of his post that unlike React, the Svelte framework strives to build the UI in a way that matches the habits of the human mind.
Let’s take a look at the reactions of other open source authors without judging Rich’s views.
Jordan is the original author of React. “If DOM is stateful/imperative, embrace it,” he tweeted. Well, so are computers.
His quips were more subtle. I’m going to make an interpretation, which may not be accurate, but listen.
The foundation of functional programming, Lambda Calculus, is a general computing model equivalent to the computing power of the Turing Machine.
The current mainstream computers are devices built on the Turing Machine and Von Neumann architectures. It is full of mutable states and an imperative set of instructions.
All the functional code we write ends up running on our computers in a non-functional way.
Well, if the bottom layer is stateful, imperative, there’s a good reason to embrace it. The development of functional programming over the years is impossible.
What’s more, the universe we live in is itself full of states and imperative behavior. Why should we develop pure mathematics, something so far removed from objective reality?
Jordan is no longer directly involved in the core development of React. The current technical leader of the React Team is Sebastian, the brainchild of react-Hooks. He wrote a whole article explaining why React did what it did.
In it, he summarizes two types of Reactivity handling.
One is represented by Vue mutable + change tracking. Mutable data structure, in conjunction with change tracking, triggers the update function.
The other is immutability + Referential equality testing represented by React. That is, immutable data structure, with repeated rendering functions, and in the process of function execution, through the judgment of reference equality of data, find out the changed part, and only apply the changed part to the UI.
Sebastian begins his article by stating that both practices have trade-offs. Because mutable is a way that has been well studied by other frameworks, the React Team decided to focus on exploring immutble to see where it might lead us.
Vue, React and Svelte have their own trade-offs and advantages and disadvantages in Reactivity mechanism.
Reactivity with different tradeoffs
The tweet was well received, and if you’re interested, you can go to the link above.
At this point, we can sort out the key points of the framework paradigm debate:
To framework authors, paradigm differences are simply trade-offs.
For users of frameworks, however, paradigm differences can be differences of belief.
This is not the first time such controversy has occurred. We can listen to some of the special voices in the community.
All the contents in the quotation marks above are quotes from the original text. I don’t know why any developer, in the name of best practice, would rush to draw a line in the sand.
It was like going back to the early 20th century and thinking that the edifice of physics had been built and that all that was left was some cosmetic work. All the major problems have been solved. There is no need to play around with finding new links. Just take sides and stand firm. Therefore, if you use the A paradigm, you have to reject the B paradigm.
There are, however, two dark clouds hanging over classical physics.
If we are not blinded by prejudice, we can easily find that there are multi-paradigm linking points in React and Vue.
Since Vue V2.0, there is a built-in Virtual-dom for cross-end rendering via functional-UI. React also supports the render method and JSX syntax.
The Vue authors themselves are always open and receptive, absorbing parts of other frameworks that will benefit or inspire Vue. Mutable is a distinctive feature of Vue, not its only goal.
He doesn’t stop using virtual-dom because it belongs to functional-UI. He did not reject the react-hooks approach because they belong to the functional programming style. Instead, he tried to use them in Vue 3.0 to form a Vue composition API that combines Vue features.
In addition, I demonstrated how to implement React-style immutability + Referential Equality Testing based on Vue 3.x API in the article “Revealing the Most potential OF VUE-3.0 API”. The feasibility of concatenation between mutable -> immutable in VUE is verified.
React also contains mutable parts, such as the most intuitive useRef. Not only is it mutable, but React mutate himself.
As shown above, useRef(NULL) is originally null. After rendering to the DOM, React assigns div elements to ref.current in a mutable way, so we can access div elements inside useEffect.
The useEffect function makes it clear that imperative style side-effects code can be executed internally.
In event handlers, we can also execute side effect code.
React is all about making the render function /function-component as free of side effects and mutable data as possible. Rather than exclude all mutable and side-effects.
What React does is delay and isolate side effects for better management.
Even the purest functional programming languages deal with side-effects. Back in 1989, they found an efficient and safe way to handle side effects while keeping the pure functional nature of the code.
”
On the Expressiveness of Purely Functional IO Systems”
If you are interested, you can click on the Paper above. It can be seen that React’s current practice is exactly the same as the Dialogue model in the Paper 30 years ago.
Interestingly, several members of the React Team, such as Redux author Dan, were born in 1992. Neither they nor JavaScript were born at the time of the Paper. The ideas in Paper still inspire the design of Web frameworks 30 years later.
As we see above, both Vue and React already contain multiple paradigms, but each has its own emphasis.
Deliberately elevating the emphasis of the frame into a belief can easily lead to confirmation bias. That is, they only pay attention to the information that fits their expectations and ignore the information that doesn’t. Such as:
Although Sebastian emphasizes that React is immutable, this does not mean that he negates the positive effects of mutability on React.
“Mobx’s mutable/ Reactive style is inconsistent with the React approach,” he said in a tweet. But immer, the library that produces immutable data in a mutable way, matches the React route exactly.
Sebastian himself is open and positive about finding the junction between the mutable and immutable paradigms.
Mobx authors don’t even fully agree that Mobx and React are immutable.
He wrote in a tweet that he was thinking about the connection between Mobx and IMmutable.
The paradigm struggle to break the framework is actually a change of thinking. From thinking about competition between different paradigms to thinking about synergy between multiple paradigms.
Inspired by Immer and Vue, I have also created an open source project that attempts to integrate mutable, IMmutable and Reactive modes.
As shown above, biState, like immer, can be switched between immutable and mutable operation states. In the React demand immutable phase, it is immutable; In the React support mutable phase, it is switched to mutable via useMutate.
In addition, like Vue, it is reactive, a listener to the parent node that responds to changes made to the child node.
Immutable, mutable, and Reactive work where they are appropriate.
We get both the predictability of immutable data for execution, the ease of writing code, and the simplicity of reactive-data for state management.
You can learn more about the Reactive Hooks State Management Library: Introduction to Bistate.
conclusion
In the face of the paradigm struggle between frameworks, we need to actively receive a variety of positive and negative information to reduce information polarization.
We need to understand that JavaScript is a multi-paradigm language. And different paradigms have their own scenarios.
Just because framers emphasize their own paradigms and paths does not mean that they deny other paradigms.
Compilation techniques and meta-programming features of the language, such as Proxy/Reflect, allow our code to derive new semantics and behaviors, building Bridges between different paradigms.
Be open and inclusive.
The paradigm struggle to break down frames is, in fact, to break down prejudices in our minds.