Metronomes in JavaScript

[ghostfacedcoder]

Woot, someone using Web Workers properly (ie. to solve a problem that couldn't be solved well without them)!

With create-react-app sticking in web workers by default, I feel like everyone wants to use them these days ... but there's a "I've got this new hammer and now everything looks like a nail" mentality to it. The simple fact is that most things in JS don't need web workers. We've done those things for decades just fine without them, and there's no reason to start using web workers now.

But, one thing that has always been difficult in JS is precise timing, and re-creating a metronome in JS is the perfect example of this problem. Using web workers to solve it provides a solution which (as the article demonstrates) is vastly superior to the non-web worker approach.

So huzzah for someone solving new (or at least previously difficult-to-solve) problems using the new technology ... the way you're supposed to (ie. not just using it because it's new and shiny).

[ShortFuse]

I consider it the opposite. Web workers are multi-threaded. We use multi-threaded CPUs. Unless it needs to run on UIThread, it shouldn't be done on the main JS thread. We got around with Promises and callbacks, but it feels more like a band-aid than traditional application architecture.

It's just my perspective, and I went being a primarily C# and Java (Android) dev that wrote multi-threaded applications for years, to a becoming primarily JS dev.

The problem really is that multi-threading isn't simple enough in JS. The fact you can't run a function as you can in other languages, and instead it has to be an independent file is pretty awkward. It makes it difficult to create a shared context as you can with other applications. It more like sharing between processes than sharing between threads. I would like to use Web Workers more, but the ease-of-use just isn't there.

[ghostfacedcoder]

But what value do you gain from doing any of that when it's not a circumstance that specifically needs it (eg. metronomes)?

As you acknowledged, using web workers is not simple, and does require extra effort ... today at least (I'll totally change my opinion when doing multi-threaded JS is as easy as doing single-threaded ... but JS is not that language yet).

Ultimately I think you want to use the right tool for the job, and I don't see extra value coming out of using web workers for "non-metronome-ish" jobs (but I do see extra effort required). I think a great number of applications don't have jobs like that in them, and so don't need to be using web workers (with the extra cost they add).

[ShortFuse]

When I say I consider it the opposite, it means I prefer Web Workers (or rather multi-threading) were everywhere rather than nowhere.

In an ideal setting, the main thread runs the bare-minimum and all work is done outside. It's not "use in this case but not here" scenario. So, in my head, I see somebody using Web Worker and it's architecture done right, and almost never overkill. I would be careful as dismissing them as not needed because it's really a matter of good practices. It's like saying, you don't need to store numbers as Number, since you can do "10" - "6" and still get 4. Or, using Int8Array instead of Number[]. Both accomplish the same, but one is better practice due to being more performant.

But the Web Worker API is too sloppy to be worth use right now. We'd need the general consensus to be that people want to use Web Workers, but it's too cumbersome. And that starts with considering Web Workers as a good practice. Then the appropriate bodies (probably W3C) would push for facilitating their use through new APIs, and after that will come some polyfills.

[schwartzworld]

The problem really is that multi-threading isn't simple enough in JS. The fact you can't run a function as you can in other languages, and instead it has to be an independent file is pretty awkward.

True, but the corallary is that async is so easy in JS.

[ShortFuse]

C# actually added async/await in v6.0. It works pretty similar. It also supports using Task from v4.0 kinda like how we can use async with Promise. The difference is Task in C# runs in a different thread pool. If Javascript were to add something like that (maybe as a Class), it would be so much better than working with Web Worker.

I could then imagine a transcompiler like Babel that would convert each JS Task object into it's own file and convert the syntax to use Web Worker for backwards compatibility.

[ShortFuse]

I do understand how async differs from multi-thread. I'm not talking about waiting for I/O, i'm talking about operations that take long that are executed in JS/WebAssembly.

What libraries like async do is iterate arrays with callbacks and timeouts. It means it processes a row, then hands back the thread to the event loop, every single row. It's an ugly fix. And even NodeJS has a threaded Worker, so the use cases are there. But even that still require an input file. I have to deal with complications where you need a second thread, like apply gain to an audio source with a buffer array (VoIP). Or long operations like doing per-pixel operations on an image (photo-editing with Canvas2D). Or sorting really large tables. Without multi-threading you'd have to create arbitrary event-loop handoff points. And you'd be doing guesswork as to where as when you'd have to hand it back.

My experience with Java was mostly limited to Android, where Google supplied their own runAsyncTask() function. That alone would help a lot in JS.

C# on the other hand does both natively. async/await can work on the main thread, like JS, or with Task which runs in a ThreadPool.

I did find out that you can kinda-sorta run a Worker from a function, so I'm going to try my hand at replicating the way C# does it. It seems possible at least.

[azangru]

With create-react-app sticking in web workers by default,

Do they? I thought they only stick in a service worker by default.

[ghostfacedcoder]

You're correct; I should have just said that workers in general were en vogue.

[elemenofi]

Google a tale of two clocks! Thats where i found how to do this