Introduction
This specification defines an API for running scripts in the background independently of any user interface scripts. This allows for long-running scripts that are not interrupted by scripts that respond to clicks or other user interactions, and allows long tasks to be executed without yielding to keep the page responsive.
Workers (as these background scripts are called herein) are relatively heavy-weight, and are not intended to be used in large numbers. For example, it would be inappropriate to launch one worker for each pixel of a four megapixel image.
Generally, workers are expected to be long-lived, have a high start-up performance cost, and a high per-instance memory cost.
User case
As the web worker API allows us to implement multi threading behavior to a web application imagine a Stock application requires doing multiple things at the same time, getting stock updates on timed interval and finding quotes for specific stock option based on user search criteria. This can be a very good example to think about web workers to be used.
Another use case could be where the application is required to display different views for the map say regular map view, satellite view, hybrid view and 3D map view displaying same region at the same time. User can switch between maps to move map directions in any of the views where all the maps should get updated to show the respective region in their view.
Examples
This is really interesting stuff. It looks to me like threading as of now, as in conceptually.
ReplyDeleteYes, that is correct and with client side scripting to implement robust threading without settimeouts
ReplyDelete