#stackathon

So the problem is that if we want our web worker file, that we named worker.js to be able to compute fibonacci numbers, it must have access to the fibonacci function. How do we do this? Well, we have to put the fibonacci function inside the worker.js file. 

This kind of sucks, because we need it outside as well for regular javascript to use in our comparison. Sure this works, and it shows web workers are faster, but it isn’t applicable or easy to use at all. Are you telling me that for every different type of computation I want to make, I have to manually put it into the worker.js file? 

The first thing we tried as Blobs. Have you ever opened up your dev tools on Vine or Facebook and noticed that those videos aren’t just html video elements. They say :blob or :data. Something like that. Well blobs are ways to run separate javascript files - in the same file. Thinking that this might allow our blob to have closure over the same fibonacci function, we moved everything out of worker.js into our new Blob, all into one file. 

It didn’t work. 

The next thing we thought might be worth trying was passing in the function itself as data using postMessage. That way, on the other side, we could unravel the function and just use it again. 

Sounded good. But another limitation of workers is that you cannot just postMessage objects. You can only send pure data. So what now?

We ended up stringifying the object and function, passing it through as a string, and using JSON.parse to turn it back into an object. However, the function was still stringified, and to turn the string back into a working function, we had to use the Function constructor. I bet you didn’t see that coming.

Yes apparently there really is a Function constructor that takes in the arguments, and also the guts of the function you want to make. 

The next hurdle was actually grabbing that required information from a stringifed function, and we ended up writing a nasty regex expression. However, it worked, and we were able to finally port the complete function over. 

- The senior assessment is much harder than any assessment or checkpoint you have taken so far. If you have been struggling, it will be a good idea to take a little more time to prepare for this beforehand. For some of the class, simply the practice you get during stack-store will be enough. If you don’t feel like this is you, then I highly suggest you review Sequelize from the past assessments. If you have been doing well so far, you’ll be fine.

- For stackathon, you will have the option of working yourself or with one other person. I can’t say for sure which is better, but I think it is best to try to come up with an idea earlier rather than later since you want to spend most of your time actually working on it. 

- The rest of this post will be pretty technical while I try to explain my stackathon project. 

Web Workers and Concurrency in JavaScript

Jon Rim had told me his idea. He wanted to show how multithreading was faster than single threading. It’s very easy to understand why this would be true. Single threaded languages like JavaScript must do things one after another. You can imagine it like a queue, where tasks are lined up to be executed one after another as your code executes. With multithreading, however, there is not just a single queue, but several that can run concurrently. 

I thought this was a great idea, especially if executed properly. On one hand, it could be extremely boring to everyone if it was too technical and there wasn’t enough effort spent on helping the audience appreciate why this was important. But if the presentation was done well, I thought the idea could thrive. Still, I was preoccupied with my own ideas. I had been thinking about potential ideas for this Stackathon for a long time. Here is a short list:

- Virtual piano that allowed user to use any flat surface as a piano; would use webcam and motion detection

- instant speech translation

- facial recognition tool so you would never forget anyone’s name

Yeah, I know. What am I thinking. 

Well, I’m glad I realized the idea paralysis wasn’t productive, and as I asked Jon more about his idea, I started to like it more and more. Because he likes to code in C++, I assumed he was going to do a comparison between C++ and Javascript. However, he was looking into something called Web Workers, which was a new feature of HTML 5. I was hooked.

Web workers allowed you to delegate tasks out of your main javascript file into another file. The work could be completed there, and the worker would send a message back to the main file, which would receive the message. 

Ideally, this would allow your computer’s processing power to be better utilized by the browser. Rather than have one long line, there could be several broken up lines that all move simultaneously. 

However, there are some limitations to web workers. Most notably, they cannot directly influence the DOM. You cannot use postMessage to send DOM elements back to the main file, and inside the Worker file, you cannot modify the window element. What you have to do is send a message back, then in the main file, change the DOM by setting the element’s innerText to that returned value. 

First, we wanted to find a way to compare the speed of using web workers vs regular javascript. Our first test incorporated a search for the nth fibonacci number. We set up an array of numbers that would take fairly long to find the nth fibonacci number of, e.g. around 40. For regular javaScript, we would just try to map that array, returning fib(elem). 

For our web worker example, we had to create a new worker for each element in the array, and use each of those web workers to find the nth fibonacci number simultaneously. This meant that if there were 10 elements in the array, the worker version of the test would ideally be 10 times as fast. I say ideally because creating web workers and passing large chunks of data back and forth has a lot of overhead which would slow down the time. This is why web worker usage is only recommended for heavy computational work. 

So we see that it is faster, a lot faster, especially when he make it find things like the 40th fibonacci number. Recursion is a b for fibonacci, anyhow. But we want to think bigger. How can we make it so anyone can use this functionality not just to find fibonacci numbers, but also the result of any sort of heavy computation in any function they please?

Sniff, sniff, this is starting to smell like open source contributions!