As I’m not an expert on this domain, I’ll let others do this for me, like this one. I’m going to stick to what Web Workers were designed to do in the first place (as quoted from w3schools):
Seems pretty clear to me: it is a (distant) relative of the good old BackgroundWorker in .NET. Having established what it does, let’s see how it works. The process consists out of the following activities:
- Feature check: does the current browser support Web Workers?
- Create an instance of the Worker class and add a reference to the script that must be executed upon firing the worker object. This can either be:
- An external script
- An inline script
- Subscribe and publish messages on both front- and background thread
- Trigger the process
This still looks pretty vague, let’s dive into the code right away. Find a spot in your code where you want to do some heavy work, and then have a look at this code:
Next thing to do is to subscribe to the callback that the background method will fire when it has done its work. In Web Workers, you need to do this by writing a function on the onmessage event. The callback takes 1 parameter, but it’s a flexible one: you can add custom data in the e.data property. I’ll show you how to do this in a minute. Last thing to do here is to trigger the (background) process: the worker’s postMessage method does just this. You can add your own parameters to this method, the web worker will convert the parameter and it will be added to the data property of the incoming parameter (= which is a MessageEvent object) in the background thread. If it’s not clear yet, don’t worry – we’ll get to it. Let’s go to the code that will be run in the background (the external script):
If you look at this code, you might have noticed this establishes two-way communication between foreground and background. The foreground triggers a message, which is handled by the background thread. As soon as the latter has done its work, it can send a message back to the foreground. With the callback method in the foreground thread, it is notified of this event, upon which additional logic can be entered.
This is how the process looks like graphically: Note that the custom parameter in both postMessage methods can be accessed in the onMessage method inside the data property. Here you can see the message event in action:
There are no differences here code wise, but note the ID and the type of the script, we’ll need this when we declare the worker object:
With this new approach, you can add an inline script anywhere in your code, as long as you wrap it around a script tag with a unique ID. I wouldn’t really recommend this approach but at least it’s a possibility. The first approach is a lot cleaner but it has one little drawback: you need to specify a path to a script, which is a bit of a no no in ASP.NET MVC where basically everything happens through routes. There are ways to make this generic, but you’ll need to do the work yourself of course.