Web workers

Web workers work in a separate thread and does not block the main thread

<!doctype html>
<html>
<head><title> web worker example </title></head>
<body>
    <button id="backgroundBtn"> change background </button>
    <button id="calculateBtn"> calculate </button>
    <script>
        const backgroundBtnEle = document.getElementById("backgroundBtn");
        const calculateBtnEle = document.getElementById("calculateBtn");
        
        backgroundBtnEle.addEventListener("click", (event) => {
            document.body.style.background === "green" ?
            document.body.style.background = "gold" : document.body.style.background = "green"
        })
        calculateBtnEle.addEventListener("click", (event) => {
            let total = 0;
              for(let i=0; i<100000000; i++) {
                for(let j=0; j<100; j++) {
                  total = total - i + j;
                }
              }
            alert("Total is: ", total);
        })
    </script>
</body>
</html>

Here, once "calculate" button is clicked, the screen freezes and does not allow clicking of "change background" button. This is because the main thread is blocked.

Let us move the calculation portion to a web worker.

Before trying to implement a web worker, make sure you are serving files from a server such as node.

Quick setup:

npm i express

npm i ejs (view engine as you will render an html file)

server.js

const express = require('express')
const app = express();

app.use(express.static('public'));
app.set('view engine', 'ejs');

app.get("/", (req,res) => {
  res.render("index");
});

app.listen('3000', ()=> console.log('listening at 3000'));

Note: Make sure you have renamed the ".html" file to ".ejs". This should be inside "views" folder

the "worker.js" file that will be created next has to go inside "public" folder

1. Create a new webworker 

create a file public -> worker.js. 
Call this file and create a new worker pointing to this file

<script src="../worker.js"></script>
const worker = new Worker("../workder.js");
worker.postMessage("hello from main thread");

And in worker.js file:

In any worker file, the global object is the worker itself. Just like how the glbal object is window in other cases. So you can either use self.onmessage or just onmessage

onmessage = (msg) => {
  console.log("Msg received from main thread", msg.data);
  postMessage("Hi from worker")
}


So the main thread creates a worker and posts a message.

Upon receiving the message, worker responds back

main thread can again catch this message using "onmessage" similar to how the worker thread reads.


Now moving the computation logic to worker file so that our main thread is not blocked and change background button works anytime

worker.js

onmesage = (message) => {
  let total = 0;
  for(let i=0; i<100000000; i++) {
    for(let j=0; j<100; j++) {
      total = total - i + j;
    }
  }
  postMessage(total)
}


main.js

calculateBtnEle.addEventListener("click", (event) => {
    const worker = new Worker("../worker.js");
    worker.postMessage("hi");
    worker.onmessage = (msg) => {
      alert("Total is: ", msg.data);
    }
})











  







Comments

Post a Comment

Popular posts from this blog

Inside the JavaScript Memory Box: Visualizing Variables, References, and Copies

Image
There is a difference in the way JavaScript refences variables based on whether they are primitive or non-primitive Primitive Types: string, number, bigint, Boolean, symbol, null, undefined Non-Primitive: Arrays, Objects Each variable in JS is stored in a memory “box” Assignments: But when another variable tries to assign this value, JS thinks “wait, is this a primitive or non-primitive? Because if it is primitive, I will create a new box for this new variable with the same content. But if it’s not, I will just create a refence to the existing box” PRIMITIVE: Analogy: Let's say you have a note that says 5. You give a copy of this note to your friend.  Friend now updates this copy to 10. But your copy still says 5 let a = 5; let b = a; b = 10; //a remains unchanged NON-PRIMITIVE: Analogy: Let's say you have a note with address "123 Elm Street". In that house lives a cat named "Tom". You give a copy of this note to your friend. Friend now goes t...
Read more

React & State Management: All Concepts

Section 1: Fundamentals 1. Counter with increment, decrement, reset — useState Remember: prev is needed when the new state depends on the old state. When you're setting a hardcoded value like 0, you just pass 0 directly. Why:  reason prev matters — if multiple state updates happen in the same render cycle, React batches them. Using prev guarantees you're working off the latest state, not a stale snapshot. 2. Toggle show/hide paragraph — useState Remember: onClick={toggle} — pass the function reference, not the call. onClick={() => toggle()} — also fine, arrow function that calls toggle when clicked. onClick={toggle()} — calls toggle immediately during render, setVisible triggers re-render, toggle calls again, infinite loop. Why: JSX evaluates expressions inside {} during render. toggle() is an expression that executes immediately. React doesn't get a chance to attach it as a handler — it just runs it right there, state updates, component re-renders, runs again. ...
Read more

React: Communication between components

Parent to Child: Props Child to Parent Callback Props (advanced props) Controlled Components useImperative hook  Nested Tree: useContext Sibling: Lift State Up PARENT TO CHILD: Props App.jsx Users.jsx <User name ={user} /> function User({ name }) {  return <h1> {name} </h1> } CHILD TO PARENT a) Callback Props (Advanced Props) Parent.jsx Child1.jsx export function Parent() {   function sayHello () {     alert(“hello triggered”)   }   <Child1 onSayHello ={ sayHello } /> } function Child1({ onSayHello }) {   return <button onClick={ onSayhello() }>          Click       </button> } b) Controlled Components Usually used in forms. Controlled components mean the parent owns the state, the child renders inputs, and every ch...
Read more