Recently I come across web workers, it's a way to have your scripts run parallel. Giving your script to run in background without "freezing" the user interface. When I found out this, I think I have found a new technique to implement into my ionic app which should bring significant UX performance improvement.
But after some searching, I hardly find any article talk about web workers in ionic. As web workers isn't something very new, why there hardly any mention about it in ionic or even Angular? Is ionic isn't suitable to implement? Or, it is something else that I overlook?
Will web workers beneficial on ionic app?
That depends entirely on whether you have some heavy processing that you can offload to web workers.
As web workers isn't something very new, why there hardly any mention about it in ionic or even Angular?
Because web workers have nothing to do with UI frameworks, because code in web workers can't directly manipulate the UI of the browser (e.g., can't manipulate the DOM, or do alerts, play audio, etc.). So web worker code has little-to-no use for a UI framework library, as that library's job is largely to do things the web worker can't do. Instead, there is one main UI thread (the default JavaScript thread for the page) which is allowed to use the DOM and such, and so has reason to use UI framework libraries.
Details:
Originally, JavaScript in web browsers ran on a single thread, which also updated the UI. This made for a very simple model without concurrency issues and was tremendously simple and successful. But it's also limiting: As JavaScript started getting used for more and more things, that one UI thread got bogged down in processing, and browsers had to implement heuristics to do "slow script" warnings and such so the user didn't think the browser had frozen.
Web workers were introduced in order to let us have threads in browser-hosted JavaScript, while keeping the powerful simplicity of the single UI thread without concurrency issues (this is also why they don't share a global data area with other threads). They let us do heavy processing in other threads, but not allowing us to update the UI in those threads.
That work can be indirectly related to UI. For instance, on modern browsers it's possible to send certain kinds of objects, called transferrable objects, from the main UI code to web worker code. IIRC, canvases are transferrable. We get around the concurrency issue because once you post a transferrable object from one thread to another, it's only accessible in the target, not in the source anymore. So the main UI thread, which is allowed to directly interact with the UI, can take something (like a canvas) and transfer it to a web worker to do something to it (a transform, perhaps) and then send it back. But since that work wouldn't involve directly manipulating the browser UI (DOM, etc.), it's unlikely to have much call to use a UI framework library.