Date: Thu, 19 Sep 2019 10:00:00 +0000
<div class="trix-content"> <div><strong>Episode Summary</strong></div><div><strong>Surma is an open web advocate for Google currently working with WebAssembly team. He was invited on the show today to talk about using web workers and how to move work away from the browser’s main thread. His primary platform is bringing multithreading out of the fringes and into the web. </strong></div><div><strong>The panel talks about their past experience with web workers, and many of them found them isolated and difficult to use. Surma believes that web workers should pretty much always be sued because the main thread is an inherently bad place to run your code because it has to do so much. Surma details the differences between web workers, service workers, and worklets and explains what the compositer is. </strong></div><div><strong>The panel discusses what parts should be moved off the main thread and how to move the logic over. Surma notes that the additional cost of using a worker is basically nonexistent, changes almost nothing in your workflow, and takes up only one kilobyte of memory. Therefore, the cost/benefit ratio of using web workers gets very large. They discuss debugging in a web worker and Surma details how debugging is better in web workers. </strong></div><div><strong>Surma wants to see people use workers not because it will make it faster, but because it will make your app more resilient across all devices. Every piece of JavaScript you run could be the straw that breaks the camel’s back. There’s so much to do on the main thread for the browser, especially when it has a weaker processor, that the more stuff you can move away, the better.</strong></div><div><strong>The web is tailored for the most powerful phones, but a large portion of the population does not have the most powerful phone available, and moving things over to a web worker will benefit the average phone. Surma talks about his experience using the Nokia 2, on which simple apps run very slow because they are not being frugal with the user’s resources. Moving things to another thread will help phones like this run faster. </strong></div><div><strong>The panel discusses the benefit of using web workers from a business standpoint. The argument is similar to that for accessibility. Though a user may not need that accessibility all the time, they could become in need of it. Making the app run better on low end devices will also increase the target audience, which is helpful is user acquisition is your principle metric for success. </strong></div><div><strong>Surma wants businesses to understand that while this is beneficial for people in countries like India, there is also a very wide spectrum of phone performance in America. He wants to help all of these people and wants companies acknowledge this spectrum and to look at the benefits of using web workers to improve performance.</strong></div><div><strong>Panelists</strong></div><ul> <li><strong>Charles Max Wood</strong></li> <li><strong>Christopher Buecheler</strong></li> <li><strong>Aimee Knight</strong></li> <li><strong>AJ O’Neal</strong></li> </ul><div><strong>With special guest: Surma</strong></div><div><strong>Sponsors</strong></div><ul> <li><a href="https://devchat.tv/adventures-in-devops/"><strong>Adventures in DevOps</strong></a></li> <li> <a href="http://sentry.io/"><strong>Sentry</strong></a><strong> use the code “devchat” for 2 months free on Sentry’s small plan</strong> </li> <li><a href="https://devchat.tv/adv-in-angular/"><strong>Adventures in Angular</strong></a></li> </ul><div><strong>Links</strong></div><ul> <li><a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers"><strong>Web workers</strong></a></li> <li><a href="https://developer.mozilla.org/en/docs/Web/API/Service_Worker_API"><strong>Service workers</strong></a></li> <li> <a href="https://developer.mozilla.org/en-US/docs/Web/API/Worklet"><strong>Workl... Support this podcast at — https://redcircle.com/javascript-jabber/donations Advertising Inquiries: https://redcircle.com/brands Privacy & Opt-Out: https://redcircle.com/privacy
