The Use and Misuse of Web Workers

=====================================

Just wait for it, basically that's what you just have a listener that waits for that return back message and do something with it and that's it. I mean very simple and what are the use cases? Yeah this is kind of a topic for itself because if you want to move your unresponsive code to the web worker like don't do it please because it's just going to you know it's just like putting uh trash below how to say the uh the carpet yeah i mean eventually your wife will come and then you're screwed so yeah repacking slash reformatting data sets more or less always lazy backhand so don't do it on the front end please even if you elevate it to some like uh application state redux mobix whatever and then you do this heavy stuff within the worker it's still horrible like you just should not do it and yeah like i said it's going to affect your ux which is like very important and it's i mean the multi trading is not about heavyweight lifting it's just about not blocking your main stack so imagine that you have this e-commerce solution and you have a button that says like add to cart and then you start some heavy calculations no matter what it is one of our colleagues had this use case where he basically they needed to scan the qr code and when you scan the qr code sometimes it can you know just consume a lot of resources if you want to do something with it to process it and stuff so what they did is the they thought to put this in a worker because if you scan this stuff and it needs to to do something which can endanger the the usage of your current execution stack and if you just gets stuck on the stack executing if you click on this button to add to cart something a product that action will need of course to update some state and then to just you know push the changes throughout your application so when you click to this like add to cart button and this stuff is going to continue executing in the background on your stack you will not be able to to do it basically so in this modern age of like e-commerce it's not only about having the like fastest page load time it's also about never ever have this situation when you block your execution stack with anything and yeah at the end basically like if you want to terminate the worker you can do just this simple thing work at your terminate and then you do it uh from the main contact context for your application or you can do like self.close also close to use this method for the same purpose.

Calculating Primes in a Web Worker

------------------------------------

So what we do here is that the only thing that you need to think about is this calculate primes actually i took this uh method from the mdn and what does it do it's just doing basically the random calculations and yeah it's it's very horrible so basically you just want to make your cpu artificially go crazy and yeah here i just did on windows unload i just waited for four seconds because i wanted my web page to be at least to some point like responsive so if you reload the page we can like see how it updates and then it doesn't i mean i'm still tweaking and nothing happens because the heavy calculation started and i can do this and if i'm a user you know i would just say like oh this doesn't work like and i would press like 10 times and then i would just stop and then maybe close the website and then there is no purchase or stuff so how you can fix it is very easy and in this case we can just remove this horrible code and replace it with a worker so you basically instantiate a new worker it this method accepts a path and then you define a message to be posted to the worker that's basically just kind of some kind of object and here you just wait for worker to return you something simple as that.

Elevating API Calls to Web Workers

-------------------------------------

So if we have in mind the limitation of our smartphones especially we should consider elevating something even like the api calls to the worker because it's all about not blocking your uh stack execution and basically nothing else. If you go to our web page and we reload it oh you will see that basically i can click all day long yeah and it works so i'm not going to lie to you like there is not a magical answer on like what what are the use cases for it and that's one of the reasons why people don't use it is that i mean if you if you need to use it you will know or maybe you will be wrong by knowing it because the thing is that most of the time people if they write a good code it will not end up in a situation where you need to solve it by the worker but in some specific scenarios.

"WEBVTTKind: captionsLanguage: ennext up we have developer and web workers uh give it up round of applause for developer hello everybody my name is divelgar or as my mother gave me name dusan yeah but they're always welcome i guess and i come from serbia i'm in berlin for one month and i work for this company it's called smaller and we do online loans as so i never thought that working with money is going to be any kind of fun until i came here so it is kind of so today we talk about the web workers um it's kind of a tricky topic and a weird one as well because it's already 2018 and can you show hands who is using this stuff yeah it is like that so i'm seeing front engineer and technical product owner it's mava as i said i blog at www.develoger.com and the same i use the same how to say the two twitter handle so let's start this is a bit of a history already i mean you know i grew up in the 90s and for me like 10 years ago is always like 1999 you know so so yeah i mean but 10 years ago was like almost this and before before we had this kind of uh react angular and all sorts of like mambo jumbo on the front end we needed something in order to support it and in 2009 actually happened this revolution that people don't uh know so much or they know but that i'm not aware of and it's called jit or better say like just in time compiler and on many um job interviews you will hear this question like is javascript compile or interpret it and yeah it is both so then when some nice people introduced the justin tank compiler the whole like um performance of executing javascript really elevated and then in 2013 the react came as a result of that and also the result of facebook's try to basically elevate some of the heavyweight lifting to the user devices which was very nice from them uh okay so let's move on so why were brokers um i mean if in this 2009 something somebody introduced a thing which can uh which open the door for like um clean t reach applications and then as we all know likely uh clinton's application need to be executed in a browser that means like single stack of execution and that's basically you know when they say like javascript is a single thread i mean it's not javascript that is single thread it's just the browser that are single threads kind of so even though that you just a few people lifted hands and saying that they used the webworkers today web workers as a web workers not service worker are introduced long time ago and basically what does that mean is that the browser support is super it's you can easily use it from internet 411 and above but also yeah even though it introduced this like multi-thread support and it kind of fixes the single threads on the front end it's still not twice widely used for a number of reasons so no matter of the async i can see asynchronous nature of the web apis which was also like a part of muhammad's stock and i like you know all this web api like set timeout xml http request and so on and so on like there are many of them that work asynchronously but that's not multi-thread it's just not blocking what that means is that some functionality is like elevated to the web api and then once it's finished it's still going to going to like return to the um to the main thread or the this single stack of execution so yeah this is about the browser and a node.js because of this cool times that we live in we can run the javascript on both ends the front end and the back end and as you can see like in this visualization it can give you the information that the web workers are very well supported in the browser and as they are part of the web apis they're not supported in node.js like at least not natively that means that yeah because essentially that's called web workers and the node.js as itself is like built so that it's is going to be a work in it as a kind of ecosystem on this single thread as well i'm just yeah i'm not going to go deep and and talk about the c libraries that node.js consumes and yeah they can have like the multithread stuff but it's not not js not to javascript so the synchronous code blocks the browser i mean sometimes it can actually block your browser like literally your ui as well not just the execution of the javascript and yeah it's obvious everybody knows but even if you post execution some calculation that will not solve your problem it will just um delay the inevitable you know because if you do some async actions and then whatever is returned you will still for example this is the usual uh api call stuff you get your json and then you need to parse it i mean this parse thing is synchronous it was always synchronous and still asynchronous and in if you have like some huge data set uh yeah you can imagine and i had a lot sadly a lot of bad architecture styled projects that ended up doing the weird things so most of the time what happens is that people on the back end for any reason don't want to send you the appropriate format so you get the data and what happens is that you need to parse it sometimes it's huge so that parsing is going to block your execution of course and then you need to re reorder it or to reformat it and do also incredibly horrible stuff that i don't accept anymore luckily and if you want to use your web workers for that i mean please don't just come by to your back end guys and and fix this stuff don't just patch it up so we came to the taboo and when the when web workers are in question the taboo topics are basically done window object more than less or the parent object so in the web workers scope of execution you cannot success dom directly i mean you can still like pass to the worker whatever you like but you cannot access it directly and you shouldn't that's not that's not the reason why they started to exist of course there is this like green stuff so that's the thing that you should do so in the web worker you can access the navigator object of course which can be useful i intentionally um read like colored in red this user agent because even if you go to the mdn website you will see like thumbs down for user agent which is super you know because i really hope that now in 2018 people stopped detecting their devices by user agent and kind of continued yeah not started continuing to detect the features of the environment and use whatever is available so in the web worker you can access the html xml http request that's important to know and of course by then you can you can do all sorts of like data fetching if needed but the web worker is not a standalone thing and basically within the one web worker you can load as many as the sub workers you need thus in like theory you can go nuts with the this like horizontal scaling of your resources and like doing things in like million threads but you don't do it please because if you there is one misconception about this you can use your web workers in order to elevate the heavy weight lifting but even though it's not going to block your main stack of execution it's still going to affect your device uh performance because at the end it's just one cpu that does does all of this stuff so the web worker or the worker and service worker are not the same oh that's fine so the worker resides in the global scope that means that you can instantiate it from within any place and just by using the new worker uh new new keyboard on this worker object or our method you can have as many workers per tab as you as you want this is very key difference between the service worker and worker and it's very well supported and for the service workers they need to be registered i mean the service worker one service worker needs to be registered via the navigator service worker register and that means that you can just have one service worker per the domain and that was the whole idea yeah it's just like having one service worker that handles all this stuff which is more than less just i mean not just but kind of a proxy for your data and with heavyweight lifting in terms of like uh caching and stuff and yeah you cannot use the xml http request within the service worker you can use fetch i mean i don't know the reasoning what i think that it is it's basically that fetch is like better because with hd xmlht xmlhttprequest you will need to write a lot of custom logic or to consume some libraries in order to do some simple stuff which just comes shipped with a fetch and the support is limited so yeah this is basically like one kind kind of a phone call because between the uh web main context of execution your application and the web broker and on the first iteration of like this changing the messages i mean before i start just to say that web workers are all about communication and that's basically just what they do the api is very simple and and all the things that you need to do is to instantiate the object as you see the the statute of the worker to post some message to worker like to provide some data to it and then on this blue stuff when it says like webworker this this is actually part which is written within the worker itself within this webworker.js file you actually just wait for a message and then you do whatever you like with it in this case you just return some method which process the data and then on the main context you just wait for it for uh you just have a listener basically that waits for uh for that return back message and do something with it and that's it i mean very simple and what are the use cases yeah this is kind of a topic for itself because if you want to move your unresponsive code to the web worker like don't do it please because it's just going to you know it's just like putting uh trash below how to say the uh the carpet yeah i mean eventually your wife will come and then you're screwed so yeah repacking slash reformatting data sets more or less always lazy backhand so don't do it on the front end please even if you elevate it to some like uh application state redux mobix whatever and then you do this heavy stuff within the worker it's still horrible like you just should not do it and yeah like i said it's going to affect your ux which is like very important and it's i mean the multi trading is not about heavyweight lifting it's just about not blocking your main stack so imagine that you have this e-commerce solution and you have a button that says like add to cart and then you start some heavy calculations no matter what it is one of our colleagues had this use case where he basically they needed to scan the qr code and when you scan the qr code sometimes it can you know just consume a lot of resources if you want to do something with it to process it and stuff so what they did is the they thought to put this in a worker because if you scan this stuff and it needs to to do something which can endanger the the usage of your current execution stack and if you just gets stuck on the stack executing if you click on this button to add to cart something a product that action will need of course to update some state and then to just you know push the changes throughout your application so when you click to this like add to cart button and this stuff is going to continue executing in the background on your stack you will not be able to to do it basically so in this modern age of like e-commerce it's not only about having the like fastest page load time it's also about never ever have this situation when you block your execution stack with anything and yeah at the end basically like if you want to terminate the worker you can do just this simple thing work at your terminate and then you do it uh from the main contact context for your application or you can do like self.close also close to use this method for the same purpose okay so this is like the the very simple you like a very simple example it's not fancy in some like react framework or stuff it's just like pure javascript nothing special so what do we do here is that the only thing that you need to think about is this calculate primes actually i took this uh method from the mdn and what does it do it's just doing some horrible stuff like like doing basically the random calculations and yeah it's it's very horrible so basically you just want to make your cpu artificially go crazy and yeah here i just did on windows unload i just waited for four seconds because i wanted my web page to be at least to some point like responsive so if you reload the page we can like see how it updates and then it doesn't i mean i'm still tweaking and nothing happens because the heavy calculation started and i can do this and if i'm a user you know i would just say like oh this doesn't work like and i would press like 10 times and then i would just stop and then maybe close the website and then there is no purchase or stuff so how you can fix it is very easy and in this case we can just remove this horrible code and replace it with a worker so you basically instantiate a new worker it this method accepts a path and then you define a message to be posted to the worker that's basically just kind of some kind of object and here you just wait for worker to return you something simple as that so if you go to our web page and we reload it oh you will see that basically i can click all day long yeah and it works so i'm not going to lie to you like there is not a magical answer on like what what are the use cases for it and that's one of the reasons why people don't use it is that i mean if you if you need to use it you will know or maybe you will be wrong by knowing it because the thing is that most of the time people if they write a good code it will not end up in a situation where you need to solve it by the worker but in some specific scenarios if we have in mind the limitation of our smartphones especially we should consider elevating something even like the api calls to the worker because it's all about not blocking your uh stack execution and basically nothing else thank you younext up we have developer and web workers uh give it up round of applause for developer hello everybody my name is divelgar or as my mother gave me name dusan yeah but they're always welcome i guess and i come from serbia i'm in berlin for one month and i work for this company it's called smaller and we do online loans as so i never thought that working with money is going to be any kind of fun until i came here so it is kind of so today we talk about the web workers um it's kind of a tricky topic and a weird one as well because it's already 2018 and can you show hands who is using this stuff yeah it is like that so i'm seeing front engineer and technical product owner it's mava as i said i blog at www.develoger.com and the same i use the same how to say the two twitter handle so let's start this is a bit of a history already i mean you know i grew up in the 90s and for me like 10 years ago is always like 1999 you know so so yeah i mean but 10 years ago was like almost this and before before we had this kind of uh react angular and all sorts of like mambo jumbo on the front end we needed something in order to support it and in 2009 actually happened this revolution that people don't uh know so much or they know but that i'm not aware of and it's called jit or better say like just in time compiler and on many um job interviews you will hear this question like is javascript compile or interpret it and yeah it is both so then when some nice people introduced the justin tank compiler the whole like um performance of executing javascript really elevated and then in 2013 the react came as a result of that and also the result of facebook's try to basically elevate some of the heavyweight lifting to the user devices which was very nice from them uh okay so let's move on so why were brokers um i mean if in this 2009 something somebody introduced a thing which can uh which open the door for like um clean t reach applications and then as we all know likely uh clinton's application need to be executed in a browser that means like single stack of execution and that's basically you know when they say like javascript is a single thread i mean it's not javascript that is single thread it's just the browser that are single threads kind of so even though that you just a few people lifted hands and saying that they used the webworkers today web workers as a web workers not service worker are introduced long time ago and basically what does that mean is that the browser support is super it's you can easily use it from internet 411 and above but also yeah even though it introduced this like multi-thread support and it kind of fixes the single threads on the front end it's still not twice widely used for a number of reasons so no matter of the async i can see asynchronous nature of the web apis which was also like a part of muhammad's stock and i like you know all this web api like set timeout xml http request and so on and so on like there are many of them that work asynchronously but that's not multi-thread it's just not blocking what that means is that some functionality is like elevated to the web api and then once it's finished it's still going to going to like return to the um to the main thread or the this single stack of execution so yeah this is about the browser and a node.js because of this cool times that we live in we can run the javascript on both ends the front end and the back end and as you can see like in this visualization it can give you the information that the web workers are very well supported in the browser and as they are part of the web apis they're not supported in node.js like at least not natively that means that yeah because essentially that's called web workers and the node.js as itself is like built so that it's is going to be a work in it as a kind of ecosystem on this single thread as well i'm just yeah i'm not going to go deep and and talk about the c libraries that node.js consumes and yeah they can have like the multithread stuff but it's not not js not to javascript so the synchronous code blocks the browser i mean sometimes it can actually block your browser like literally your ui as well not just the execution of the javascript and yeah it's obvious everybody knows but even if you post execution some calculation that will not solve your problem it will just um delay the inevitable you know because if you do some async actions and then whatever is returned you will still for example this is the usual uh api call stuff you get your json and then you need to parse it i mean this parse thing is synchronous it was always synchronous and still asynchronous and in if you have like some huge data set uh yeah you can imagine and i had a lot sadly a lot of bad architecture styled projects that ended up doing the weird things so most of the time what happens is that people on the back end for any reason don't want to send you the appropriate format so you get the data and what happens is that you need to parse it sometimes it's huge so that parsing is going to block your execution of course and then you need to re reorder it or to reformat it and do also incredibly horrible stuff that i don't accept anymore luckily and if you want to use your web workers for that i mean please don't just come by to your back end guys and and fix this stuff don't just patch it up so we came to the taboo and when the when web workers are in question the taboo topics are basically done window object more than less or the parent object so in the web workers scope of execution you cannot success dom directly i mean you can still like pass to the worker whatever you like but you cannot access it directly and you shouldn't that's not that's not the reason why they started to exist of course there is this like green stuff so that's the thing that you should do so in the web worker you can access the navigator object of course which can be useful i intentionally um read like colored in red this user agent because even if you go to the mdn website you will see like thumbs down for user agent which is super you know because i really hope that now in 2018 people stopped detecting their devices by user agent and kind of continued yeah not started continuing to detect the features of the environment and use whatever is available so in the web worker you can access the html xml http request that's important to know and of course by then you can you can do all sorts of like data fetching if needed but the web worker is not a standalone thing and basically within the one web worker you can load as many as the sub workers you need thus in like theory you can go nuts with the this like horizontal scaling of your resources and like doing things in like million threads but you don't do it please because if you there is one misconception about this you can use your web workers in order to elevate the heavy weight lifting but even though it's not going to block your main stack of execution it's still going to affect your device uh performance because at the end it's just one cpu that does does all of this stuff so the web worker or the worker and service worker are not the same oh that's fine so the worker resides in the global scope that means that you can instantiate it from within any place and just by using the new worker uh new new keyboard on this worker object or our method you can have as many workers per tab as you as you want this is very key difference between the service worker and worker and it's very well supported and for the service workers they need to be registered i mean the service worker one service worker needs to be registered via the navigator service worker register and that means that you can just have one service worker per the domain and that was the whole idea yeah it's just like having one service worker that handles all this stuff which is more than less just i mean not just but kind of a proxy for your data and with heavyweight lifting in terms of like uh caching and stuff and yeah you cannot use the xml http request within the service worker you can use fetch i mean i don't know the reasoning what i think that it is it's basically that fetch is like better because with hd xmlht xmlhttprequest you will need to write a lot of custom logic or to consume some libraries in order to do some simple stuff which just comes shipped with a fetch and the support is limited so yeah this is basically like one kind kind of a phone call because between the uh web main context of execution your application and the web broker and on the first iteration of like this changing the messages i mean before i start just to say that web workers are all about communication and that's basically just what they do the api is very simple and and all the things that you need to do is to instantiate the object as you see the the statute of the worker to post some message to worker like to provide some data to it and then on this blue stuff when it says like webworker this this is actually part which is written within the worker itself within this webworker.js file you actually just wait for a message and then you do whatever you like with it in this case you just return some method which process the data and then on the main context you just wait for it for uh you just have a listener basically that waits for uh for that return back message and do something with it and that's it i mean very simple and what are the use cases yeah this is kind of a topic for itself because if you want to move your unresponsive code to the web worker like don't do it please because it's just going to you know it's just like putting uh trash below how to say the uh the carpet yeah i mean eventually your wife will come and then you're screwed so yeah repacking slash reformatting data sets more or less always lazy backhand so don't do it on the front end please even if you elevate it to some like uh application state redux mobix whatever and then you do this heavy stuff within the worker it's still horrible like you just should not do it and yeah like i said it's going to affect your ux which is like very important and it's i mean the multi trading is not about heavyweight lifting it's just about not blocking your main stack so imagine that you have this e-commerce solution and you have a button that says like add to cart and then you start some heavy calculations no matter what it is one of our colleagues had this use case where he basically they needed to scan the qr code and when you scan the qr code sometimes it can you know just consume a lot of resources if you want to do something with it to process it and stuff so what they did is the they thought to put this in a worker because if you scan this stuff and it needs to to do something which can endanger the the usage of your current execution stack and if you just gets stuck on the stack executing if you click on this button to add to cart something a product that action will need of course to update some state and then to just you know push the changes throughout your application so when you click to this like add to cart button and this stuff is going to continue executing in the background on your stack you will not be able to to do it basically so in this modern age of like e-commerce it's not only about having the like fastest page load time it's also about never ever have this situation when you block your execution stack with anything and yeah at the end basically like if you want to terminate the worker you can do just this simple thing work at your terminate and then you do it uh from the main contact context for your application or you can do like self.close also close to use this method for the same purpose okay so this is like the the very simple you like a very simple example it's not fancy in some like react framework or stuff it's just like pure javascript nothing special so what do we do here is that the only thing that you need to think about is this calculate primes actually i took this uh method from the mdn and what does it do it's just doing some horrible stuff like like doing basically the random calculations and yeah it's it's very horrible so basically you just want to make your cpu artificially go crazy and yeah here i just did on windows unload i just waited for four seconds because i wanted my web page to be at least to some point like responsive so if you reload the page we can like see how it updates and then it doesn't i mean i'm still tweaking and nothing happens because the heavy calculation started and i can do this and if i'm a user you know i would just say like oh this doesn't work like and i would press like 10 times and then i would just stop and then maybe close the website and then there is no purchase or stuff so how you can fix it is very easy and in this case we can just remove this horrible code and replace it with a worker so you basically instantiate a new worker it this method accepts a path and then you define a message to be posted to the worker that's basically just kind of some kind of object and here you just wait for worker to return you something simple as that so if you go to our web page and we reload it oh you will see that basically i can click all day long yeah and it works so i'm not going to lie to you like there is not a magical answer on like what what are the use cases for it and that's one of the reasons why people don't use it is that i mean if you if you need to use it you will know or maybe you will be wrong by knowing it because the thing is that most of the time people if they write a good code it will not end up in a situation where you need to solve it by the worker but in some specific scenarios if we have in mind the limitation of our smartphones especially we should consider elevating something even like the api calls to the worker because it's all about not blocking your uh stack execution and basically nothing else thank you you\n"