React Native start to be mature enough to think about adding the ability to place, executed in parallel, some controller's scripts in different threads.
The one and only bottle neck of React Native is the slowing performance on view building and animations due to the single Javascript thread.
We see appearing here and there different node modules that could be merge into React Native core.
I specifically think about:
- for the workers: https://github.com/devfd/react-native-workers
- Hamster for the multithreading engine: http://www.hamsters.io
Starting developing on that direction makes huge changes in the app. If those libs were included in Core, there's maybe a way to start threads transparently by placing specific markers at the head of the JS Classes?
React-Native is awesome and have all to be the next cross platform language for web and mobile.
But in the near future, when the applications will be complex enough, the criticism will rapidly comes from the lack of speed and smooth transition that make all the difference between an 100% Native App and a 80% Native React-Native App...
I think by introducing multithreading like facility into react native we are breaking the very rule of javascript's single threaded nature. But I believe what we can do is implement some thread pool (as observed in nodejs which is used for time consuming operations) like architecture to handle execution of those events that are too heavy for javascript to manage. But to do that we must tweak into the javascript engine running on devices, its more than just a React Native change. Providing an abstraction for the same could cost a lot of penalty to us.
@Harshul Sharma: Why is the single threaded nature of javascript a good thing to persist in an environment where multiple tasks need to happen at the same time? I can't always expect gestures, animation, UI, data fetching, and business logic to happen at different times. They're often happening at the same time. Multithreading is the de-facto paradigm for accomplishing multiple tasks with a program at the same time in high performance systems. I'm also curious for myself as to why the single thread of JS is necessary on an architectural level.
A first class implementation of the web workers interface would be very appreciated.
@Garrett Mitchell: But won't that make our applications run into isolated webworkers that could make synchronisation much difficult.
@Harshul Sharma: it'd mean you'd need to think carefully about what to use them for and how to use them. But their use would be completely optional, up to developers.
@Harshul Sharma: web workers are already implemented in browsers and used in web clients. Native mobile development already exposes multithreading to apps. The primary benefit of web workers is to offload expensive computations to other threads, so that your UI computations are not blocked.
@Garrett Mitchell: I agree that giving optional functionality is good for community as it opens gates to new opportunities. But still what benefit could one get by firing different web workers. To be more clear we will be firing different js engines for different tasks and then later collecting each of their results into main js thread could also make the whole process slow. The main problem is javascript was never meant to be executed in parallel. One engine has one call stack and can manage that only. Web workers do make sense in backend with nodejs where we have high computation power but mobile phones already lack computation abilities. So the questions is, Will we be misguiding other developers to try something out that will not work for most cases?
@Garrett Mitchell: Yes agreed mobile development platforms do expose multithreading but that is multithreading, its much lighter since multiple threads share some context and can perform some operations with concurrency in mind. But web workers are different since they fire a totally new js engine for their operations and are used for cpu extensive operations that mostly can be done in total isolation. I do doubt that firing these many engines will not do us much good in case of mobile development but still it will be fun to see how things end up. I may be wrong but my opinion is a single js engine could perform much better since most of the slowdowns occur while managing components and state. While other async operations play a little part(but they do) and ar e not so significant to performance.
Instead what we can do is create a threadpool like functionality (nodejs implements threadpools to offload heavy tasks) to native threads that can do heavy tasks for us and will surely be much lighter than webworkers. That way I believe we might see more performance improvements. But that does require a lot of tweaking into our current js execution architectures.
I can't believe this feature request has 98 upvotes only 😮
@Ben Hartouz Mohamed: I've tried it once quickly and didn't work. I'll give it another try
@Egidio Caprino: okay that's good , if you you found something useful don't hesitate to tell me. this is my facebook https://www.facebook.com/samikokizz
@Egidio Caprino: yeah i agree with you. in fact i try to use this https://www.npmjs.com/package/react-native-threads but i face a lot of issues.
@Ben Hartouz Mohamed: thank you 😄 I'll let you know how it goes
@Ben Hartouz Mohamed: it would improve React Native apps performance so much
@Egidio Caprino: yeah unfortunately , this feature it's so important. currently i'm working on app and i want to add some task's in background , but all of plugins (worker/threads) in github not worked clearly