Move JS Processing to background thread or allow creation of other WebWorkers/Threads

From what I understand everything runs on the primary thread. So this is a feature request -- but if done possible sooner would eliminate any later incompatibilities. Having the main thread run the interface and JS runtimes means that hiccups can and will occur frequently. Either the design where the interface is run on its own thread; and the engine is on its own or the ability to start webworks will eliminate these types of issues where you need to do any long running calculations.

Please vote for this feature in our ideas portal.

Yeah, I'm pretty sure ReactNative does something along those lines at the moment. Even if JS is in its own thread, I still think that having something like a WebWorker would be very useful feature to have.

+1 I made a comment about this on the Q&A blog post and didn't get a respond. I think this is important to, especially when animation or long background task comes into play. I hope other upvotes this feature. It very important for performance.

+1

My reply was originally posted on the forums but I'm reposting it here is well:

This is really a tough engineering problem to solve as there is no silver bullet here. For example we can introduce WebWorkers but they do have their flaws as well. There is this new re-thinking of WebWorkers in the web space - SharedWorker that tries to solve some of the limitations there. There are other concept like immutable data structures that are slowly gaining momentum.

I also want to mention that React Native solution has its own flaws. Being always on a separate thread means that you will constantly have to marshall data (in their case serializing/deserializing JSON) between the JS thread and the UI thread. This might be beneficial for compute intensive JavaScript but in the general case the price you pay is significantly higher compared to doing it in the UI thread.

In order for us to provide the right solution we need your use cases. What is your particular scenario that you need to perform compute intensive JavaScript operations? Having more use cases on the table will help us drive this forward.

Persoanlly, more I'm a fan of the code running in the UI thread by default. I just think that having the option to run things in a worker would be a useful feature to have for projects that would need a separate thread for heavy computations and what not. But even more so, it'd be nice if we had an abstraction that would let us write something like and Android Service which would let our JS code run even when it's not part of the UI of an app.

My top case isn't even necessarily compute intensive, but that I have a background operation that isn't tied to an Android activity but still needs to run. Maybe I have a messaging app that receives pushes from a server, a location tracker that performs activities based on where the device is, etc. In Android, the only way to reliably run code separate from the visible UI is in a service. It'd be nice if Nativescript could encapsulate that idea somehow into some cross-platform concept, something like a headless block of code with a lifecycle and the ability to communicate with other blocks. Not familiar with WebWorkers but perhaps their semantics could be adopted and translated to Android services, whatever the IOS equivalent is, etc.

@ndarilek

+1 to what @ndarilek is saying. I think that ServiceWorker is a better abstraction than WebWorkers for this case, though. Since WebWorkers are more like a separate thread and must be started by the UI, where as a ServiceWorker can run even when a website isn't even opened.

Sometimes you don't get a preference as to whether or not a long-running task can execute on the UI thread. As an Android user who relies on accessibility, I can tell you that actions that block the UI thread can murder accessibility. Say you're displaying a splash screen to notify a visual user that a long-running action is taking place. As a blind user, I don't know that is happening unless I touch the screen to learn of it. If your long-running action is happening on another thread, then the accessibility service can get the UI details from the app and report the screen's message to me. If it is blocking, the service hangs and throws an ANR, or sometimes crashes out-right. I doubt the Android a11y developers see this as a bug because developers are urged to run intensive tasks on another thread, and indeed not doing so is a StrictMode policy violation. I can almost always spot apps that don't spin off threads for long-running actions--until recently, one of my fitness trackers didn't do so, and I usually took several attempts to launch it because it'd block communicating with the server and I'd touch the screen too quickly. All that is to say that moving long-running tasks into another thread isn't usually a matter of developer preference. It's a platform best practice whose violation has consequences for some users. That said, I recognize this is a difficult problem and don't have a solution to propose. That's probably why we don't see lots of these types of scripting environments on mobile platforms years after they've surfaced. :)

Hi everyone,

I looked at the documentation (perhaps I did it wrong) and saw nothing about multi-threading too. This thread is actually quite new so I was simply wondering the status of this request?

Thanks a lot. Can't wait to see all NativeScript possibilities.

Regards.

@VinceOPS

Hi @VinceOPS, this issues is still not in active development. We treat it with high priority and we are evaluating what will be the best strategy here based on all the feedback.

Can you please share your scenario that requires multithreading.

Thanks!

@valentinstoychev

Hi @valentinstoychev. Understood!

The typical scenario would be any common background task like fetching some data from a webservice (which could eventually timeout) or a database. Inserting group of rows in a database, too. Generating a .CSV file (sent, later, by email) with few hundred or thousands or entries...

I hope it helps.

Thanks!

Regards.

@VinceOPS

Thanks @VinceOPS - this helps a lot!

@ligaz

@ligaz

This might be beneficial for compute intensive JavaScript but in the general case the price you pay is significantly higher compared to doing it in the UI thread.

Thing here is that React's JS computations is heavy, this is why they went native and on separate thread by default. Here, for {N} is not real need to be by default on separate thread, but having ability to run system thread with JS handling would be good since without it smooth UI is hard thing (see how hard it's for mobile web to live on one thread).

Anything new on this one?
Image/Bitmap processing is one more thing that could be done in background.

Personally I would just like a way to "process" something off somewhere else and whatever is handing that be a core part of {N} so I know it's fully tested and rock-solid. I'd be less optimistic about this being done generically by a plugin author who might disappear in 2 months.

Yes and plugins is too big for small services that needs async like async .. Task :)

One scenario for me would be doing data transformations, i.e. iterating on datasets fetched from my backend. A workaround is to do the transformations server-side, but it seems a bit counter intuitive, as the transformations will often be specific to a given view.

A concrete example where background processing made a huge difference in my native code: I am displaying a map, and fetching points of interests inside the area currently displayed. After the POIs are fetched, I need to calculate the display location for each of them, and group them if they are too close to each other. Doing this on the UI thread, will make the map unresponsive and sluggish.

+1
I hope it will be possible to send the reference and not the object between the threads. (for performance)

Any plans for blog to develop native plugin for background threading using Android studio and xcode ? Or maybe NS guys can describe how they develop the tns plugin? It will be great time saving

Thanks

Hey everyone - In order to explain better the current state of the threading model we wrote a blog post. It also outlines what we are planning for the future and how you can use background threads now.

http://developer.telerik.com/featured/benefits-single-threading-model-nativescript/

nice blog, so the next JavaScript background thread will be able to pass variable from the main JavaScript? and in iOS will it use wkwebview for more performance?

+1

I'm closing this issue, lets use the other ones for the current state -
NativeScript/ios-jsc#620
NativeScript/android#532

We would love to continue the discussion there on the current thinking!

Merge pull request #85 from NativeScript/clip-path-density

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Navigation Menu

Repository navigation

Move JS Processing to background thread or allow creation of other WebWorkers/Threads #85

70 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Move JS Processing to background thread or allow creation of other WebWorkers/Threads #85

Description

Activity

RangerMauve commented on Apr 27, 2015

emmanuelbuah commented on May 6, 2015

wan54 commented on May 19, 2015

ligaz commented on May 21, 2015

RangerMauve commented on May 21, 2015

ndarilek commented on May 21, 2015

RangerMauve commented on May 21, 2015

ndarilek commented on May 21, 2015

NathanaelA commented on May 21, 2015

VinceOPS commented on Jun 10, 2015

valentinstoychev commented on Jun 11, 2015

VinceOPS commented on Jun 11, 2015

valentinstoychev commented on Jun 11, 2015

NekR commented on Jul 23, 2015

cime commented on Aug 26, 2015

70 remaining items

sitefinitysteve commented on Mar 24, 2016

x4080 commented on Mar 24, 2016

NathanaelA commented on Mar 24, 2016

paandahl commented on Mar 25, 2016

NathanaelA commented on Mar 25, 2016

Stavanger75 commented on Apr 3, 2016

x4080 commented on Apr 11, 2016

valentinstoychev commented on May 11, 2016

x4080 commented on May 11, 2016

manojdcoder commented on Jul 18, 2016

valentinstoychev commented on Aug 11, 2016

lock commented on Aug 29, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions