I watched the introduction video of React Server Components again.
I can’t help thinking that isn’t the PHP web page development is Server Components?
The original intention of JavaScript is to handle client interaction like Client Components.
We also know that the birth of React itself has something to do with the way PHP develops web.
Suddenly I felt dizzy. It was really a spiral of history.
Let’s analyze the story:
1. PHP Server Components(90%) + JS Client Components(10%, JS)
At the beginning, the web page is mainly for read, and there is not much interaction. PHP output “data + UI”, and JS adds UI interaction.
2. PHP Server Components(50%) + JS Client Components(50%, jQuery)
Then, there are more and more web interactions, and JS needs to operate more and more UIs. However, PHP still output “data + UI”.
3. PHP Server Data + JS Client Components(100%, jQuery)
Finally, with the extensive use of Ajax, JS has become a development paradigm to obtain data, assemble UI and locally update web pages. PHP thinks that since JS is so fussy and likes to deal with UI, it’s all for you. I’m only responsible for data API.
4. PHP Server Data + JS Client Components(100%, React & Vue)
This is the development mode in this era. Since JS assembles UI to render “data”, so let JS care about the data. give UI update work to the framework.
JS handles all UI work, and JS files are getting larger and larger, which brings new problems.
JS rendering UI: download JS → download data → JS process data → render UI
In the introduction video of React Server Components, the initial pain point is to render the UI in segments. At this time, download data will be slow (in the demonstration, in order to render the UI in order).
Since download JS and data is very slow, and both are to get the UI, can’t download UI directly?
So, scatter flowers and React Server Components were born.
It sounds scary. In fact, it existed 20 years ago. PHP Server Components download UI directly 😒, The technology 20 years ago was reinvented, yeah.
5. React Server Components(50%) + React Client Components(50%)
Looking to the future, we go back to 20 years ago. Put JS on the server side instead of PHP, React output “data + UI”, and React adds interaction.
Of course, such development is very fragmented, especially the file name has to distinguish between .server.js and .client.js, and there are restrictions. It’s so hard that people can’t help but want to crash.
Therefore, we also hope to look forward to the future.
6. React Server Components(100%) + React Auto Client
Disclaimer: I don’t know if it can be realized technically. I’m just talking nonsense.
I hope we don’t distinguish between .server.js and .client.js. They are all Server Components and have the same development habits as now, otherwise the brain will be divided.
However, React can automatically extract the interaction related logic, such as onClick onChange, into the client JS, and extract the data + UI related JS into the server. The communication between the client and the server is also automatically processed by React.
Now React Server Components distribute UI in the form of stream. The pain point is that functions cannot be distributed. What if they can be implemented? If developers don’t care where the written things run, only React care.
I think it’s revolutionary. I’d like to call it Modern React.
The times have been developing, and the times have been changing, but what has changed is always external, and there are always some things that will remain unchanged forever.
The story of how to better turn server data into client UI will continue.
We pick up the concept 20 years ago, invent new terms, depict new cakes and create new clouds. We want to change the world!
