User Experience (UX) on the online has improved tons over the past decade, because of fast machines, high-speed data connections and upgraded browsers. But fast machines play their part mostly at the server end; the client-side doesn’t really utilize their full potential. This lack of efficiency lies within the incontrovertible fact that browsers run JavaScript during a single-threaded environment, meaning multiple scripts cannot run at an equivalent time. It doesn’t really matter if you’ve got a multi-core processor installed on your system or an easy one because your browser won’t be ready to utilize its true power.
Every developer runs into a scenario where the online application he built so enthusiastically, is ruined due to obstructive JavaScript. The interface (UI) layer is blocked due to long-running scripts; these scripts prevent the user to interact with action items that use JavaScript so as to function properly, like an animated button etcetera. for instance, imagine a site that must handle UI events, process large amounts of API data, and manipulate the Document Object Model (DOM, which is a component of the presentation layer). Unfortunately, all of this cannot happen simultaneously, thanks to limitations in browsers’ JavaScript runtime. In other words script execution is catered within one thread.
Some of you would possibly think that AJAX (Asynchronous JavaScript and XML) is that the answer to the present problem, but I’m sorry to burst your bubble because asynchronous events are processed after the present executing script has yielded. So how can we affect this situation? Say hello to HTML5 web workers.
Well don’t be confused, “Web Worker” is that the name of 1 of the various taxonomies available in HTML5 specification. The WHATWG (Web Hypertext Application Technology Working Group) and World Wide Web Consortium (W3C) define HTML5 web worker as, “a JavaScript script executed from an HTML page that runs within the background, independently of other user-interface scripts which will even have been executed from an equivalent HTML page..” How Workers work!
Using the worker, developers can now run code containing extensive computations within the background, without fear about the UI layer being blocked. Let’s have a better check out how the workers make this possible.
The HTML5 markup shows the only use of a worker for performing a computationally expensive task without interrupting the interface. during this example, the most document creates a worker to compute prime numbers, and display the foremost recently found prime. The output of this document’s body may be a single line of text which says “The highest prime discovered thus far is: ________ “. The dashed area is in fact replaced by the results of the worker.
You must have noticed that there’s no coding during this document. that’s because a worker always works from an external JavaScript file, during this case “worker.js”. The content of the worker created during this file
As you can see, there is nothing out of the ordinary here, except for the postMessage() method, only plain old JavaScript used for prime number computation. This method is used if a prime number is found and the result section is modified, to send a message back to the HTML5 text.
It might not be a smart idea to use a worker just to show a small line of text (on a webpage); but if you have been following closely, you may have found that the script written to measure the prime numbers would run itself until infinity. Until the kingdom arrives, or the browser window is closed, it will keep updating the result section with the newest prime number found. If the same logic had been used without a worker to produce the same result, the browser window would have crashed in less than 30 seconds.
Restrictions and limitations
Now that you simply skills of powerful HTML5 Web Workers are, let’s have a glance at their limitations. Inside a worker script, we don’t have access to several important JavaScript objects like document, window, console, parent and DOM. Yes! A worker isn’t allowed to access the DOM due to security reasons; but as I said this restriction only applies inside the worker script, which suggests we will still update the DOM with the results from the worker.
Although workers are denied access to some pretty important JavaScript objects, they’re allowed to use important methods like set Timeout(), clear Timeout(), set Interval(), clear Interval(), navigator etcetera, and most significantly we will use the HTML5 local storage and XMLHttpRequest objects inside our workers.
When to use them
A worker is best fitted to situations where we’ve to affect third-party APIs that force the most thread to attend for a result, before proceeding to a subsequent statement. In such cases, we will delegate this task to a newly spawned worker to leverage its asynchronous capability to our benefit.
Tuts+, a blog that offers tutorials and technical articles, talks about how there might come a time once we got to process an enormous amount of knowledge returned by the server, as seen within the above example. Traditionally, processing such data negatively impacts the application’s responsiveness, thereby making the UX unacceptable. A more elegant solution would be to divide the processing work among several workers to process non-overlapping portions of the info, thus taking multi-threading to a subsequent level. Web workers also help in polling, where we continuously poll a destination within the background and post messages to the most thread when new data is received, making them a very smart choice.
Conclusion
HTML5 Web Workers have brought the facility related to multiple threads, in an otherwise single-threaded environment, call at the important world. All of the newest browsers support web workers including Firefox, Chrome, Safari, Opera and even Internet Explorer 10. the simplest part is that if you recognize the way to write proper JavaScript, you’re ready to form use of HTML5 Web Workers and if you’re not, then get yourself thereto, because knowing the way to write JavaScript is that the key to HTML5 development.