Check out a free preview of the full Progressive Web Applications and Offline course:
The "Limitations & Features" Lesson is part of the full, Progressive Web Applications and Offline course featured in this preview video. Here's what you'd learn in this lesson:

To avoid potential problems coding workers such as deadlocks, Mike reviews the limitations of web workers.

Get Unlimited Access Now

Transcript from the "Limitations & Features" Lesson

>> Mike: As we start working with these things, and as we move on and talk about the third type of service workers, you'll notice that there are lots of things that we can't do. And this is in order to make it so that we are set up for success when building programs that do multiple things in parallel.

[00:00:19] And my background, the first programming language I learnt was C, and I brought a lot of parallel programming in C++. And the idea there was you could share state between things, but there are many places where you'd basically have to slam on the brakes, wait for any stragglers to catch up.

[00:00:38] Then sync across all of the processes that are running, and then you can sort of allow everyone to push forward. So if it were a game it would be like all of the players must finish level 3 before any can proceed to level 4. And if those players are responsible for say, allowing you to scroll smoothly through a webpage, that is now halted and it's prevented from doing anything.

[00:01:03] So that won't work for JavaScript, and part of what happens here is we have limitations in terms of what we can do. So that the majority of the code that we write will kind of just work the way we expect it to work, and you're not set up to the point where you can cause deadlocks, for example.

[00:01:23] So the first thing you're gonna notice is anything that has a synchronized API, like a local storage, where you can just got an item and then in the next line of code you have the value of that item in local stores. Anything synchronous is off the table. You cannot touch the DOM, because that has a synchronous API, and you cannot touch cookies.

[00:01:42] Now, you could use that post message on message dance to ask the application to read something out of the cookie and then send it back. So there are workarounds, but you have to ultimately let the main application thread do the work. You'll notice that we have properties available called location and navigator.

[00:02:07] And while there are a location and navigator property on the window object, these are slightly different. They're sort of whittled down so that they only do what you're allowed to do in service workers. We do have setInterval and setTimeout, which are really important, and we're gonna end up using them.

[00:02:23] We have fetch and Promise, also really important. And then three things that facilitate offline support, realtime pushing of data from server to client, and IndexedDB, which we will get to at the end of tomorrow. That is a no SQL database that lives in the browser. If you've ever used MongoDB, you have something like MongoDB in browsers since IE10.

[00:02:52] It sends IE11 polyfillable in IE10, which is pretty amazing. And the reason indexedDB works and local storage does not is indexedDB has an asynchronous API. So you ask it for data and provide it a call back which it will invoke once the data is retrieved. And that can be managed with multiple things happening at once.

[00:03:13] Basically you can wait for a function to run to completion and then eventually get around to invoking that callback. So you can think of it almost like local Ajax, right? You ask for something, and then shortly after, he will get something back.