Maybe we should build a new framework to support a completely worker-based web app.

[Shwvi]

dai-shi! I am really excited to see your work about web-worker based on react.

In fact, I also caught the problem that complex render task on the front-end caused the bad performance for the app. The worse thing is my colleague （who do native work）think the web tech is not able to be high-performance. I feel unfair that they can easily use mutil-thread to build the app. So, I am trying to work out a worker-based render framework to show that we can.

I want to do a demo first and I have two plans:

1. In the react system, provide a function to produce a worker-render component like you. But the dom event is not supported now. Should we continue to be compatible with React's rendering mechanism to improve these flaws?

2. Try to build a new framework that all render task is worker-based and the dom event is mapped by the framework to the corresponding worker-based component. But I'm struggling with whether the interaction between workers and the DOM or even other web APIs will make the communication mechanism more complex, and the subsequent distribution of more and more components and tasks to workers.

I might be a rookie but I really want to own a natural higher-performance UI framework :) Looking forward to receiving your suggestions

[dai-shi]

Hi, thanks for your thoughts!

I would like to come back to this project (this repo or a new repo) for worker-based solution, after kind of stabilizing my recent active project to develop the minimal React Framework for RSC: https://github.com/dai-shi/waku

This repo's approach should be able to be redesigned/rewritten with RSC.

---

As far as I recall, React tried experimenting full worker solution, but it's not best for performance because of DOM access as you said. React Native traditionally had a bridge between two threads, and I also did something with React Native DOM: https://github.com/dai-shi/react-native-dom-expo

So, at this point, one conclusion is to use UI extensive tasks in the main thread, and do background tasks in worker threads. And, what this repo does is trying to bridge between the two threads seamlessly.

Alternatively still, I'm also interested in full worker based UI framework, especially using WASM. But, I guess it will take like a decade.

[Shwvi]

Well, dai-shi... You can build this repo for RSC. Maybe we have different intention now: I want to use web-worker to get good performance on client side while you on server side. I approve your view and I will also try to build high-performance UI with worker on client side.

Glad to have more communication with you in the future.

[dai-shi]

I am interested in Web Worker-based solution. Just too busy with Waku at the moment. Maybe, we come back to this repo and develop RSC version after React releases a new version with RSC.

[Shwvi]

Forgive me for not knowing that much about the RSC. I understand that if you use RSC, then the complex calculations are all on the server side, right? So when you say worker-based solution, you mean using workers to accelerate the computation on the server side, right?

[Shwvi]

Maybe I get your point. If react support RSC, maybe the worker-based component is much more easily to be integrated into the client side react vdom and all its operation mechanism.

[dai-shi]

Yeah, RSC here has nothing to do with the server you have in mind. RSC can work for Web workers, or even within the browser's main thread. It's simply a mechanism to serialize JS values.

So, we can simply replace https://github.com/dai-shi/react-worker-components/blob/a23c8d43fd129a6039aa3ebbab4b1f78ee7effae/src/serializer.ts.

That said, it doesn't add much benefits except for async and Suspense. So, capability-wise, it doesn't change from what it can do now in this repo.

[Shwvi]

Thanks dai-shi, have a nice day!