DEV Community: Wardell Bagby

So you want to know about Web Workers?

Wardell Bagby — Fri, 21 Jan 2022 23:55:31 +0000

Hey! Wardell here! So you've got yourself a website and you're interested in potentially off-loading some of your heavy-hitting computations to another thread?

Sounds like you want a Web Worker!

Hold up, what even is a Web Worker?

Web Workers are a simple means for web content to run scripts in background threads.

Before I tell you how to use a Web Worker, let's first go over things to consider before deciding to use a Web Worker.

You've profiled your website and discovered what you're considering putting in a Web Worker is actually slow.
- Don't bother with a Web Worker if you don't actually need it. Adding an extra thread to communicate with will complicate your code, and if you aren't getting noticeable performance gains from it, it's an unnecessary complication.
The work you want to offload can be done asynchronously.
- This is difficult to define, but if you know, you know.
You don't need window, document, or anything else DOM related.
- Web Workers don't have direct access to the DOM of your site. There are ways around this but it's generally just a good idea not to do it in the first place.

What's something you've used a Web Worker for?

See, I just love your questions!

My app Lyricistant currently has two web workers, but we're going to talk about the easier to understand one: a Web Worker that generates rhymes on demand, totally offline.

I won't get into the nitty-gritty of how it all works, 'cause I mostly wrote it in a tired stupor at 2am one night, but it needs to load a 6 MiB JSON file, iterate through 135,165 words, and compare the syllables of those 135k words to the syllables of an inputted word.

That is to say, if you type "Time" into Lyricistant (make sure to enable the Offline Rhymes in Preferences first!), my web worker will:

Find the pronunciation of "time" (T AY1 M)
Iterate over every single one of the 135k words it has pronunciations for.
Compare the syllables of "time" to the syllables of the word its currently looking at.
Calculate a score based off the comparison in step 3.

It's also worth noting that this all happens on almost every keypress (its debouncing, of course; I'm not a monster), so not only are we finding rhymes for "time", but also "tim" and "ti" if you type slow enough.

This is a very naive way of generating rhymes, and also extremely slow. My excuse is I'm not a linguist! I'm barely a programmer! 😂

Anyway, you can imagine how slow all of that code can be, so a Web Worker was the perfect choice to use! Although, fun fact: my initial implementation had this all run in the browser's main thread, and 60% of the time, it would finish in under 60 milliseconds, meaning Lyricistant could mostly hit 60fps on my 2015 MacBook Pro using Chrome. Browsers are pretty fast!

Alright, enough talking. I wanna make my own Web Worker!

Fair enough; this blog post was starting to look like one of those online recipe intros.

Creating your Web Worker

There are quite a few ways to make a Web Worker, but probably the easiest for most people will be using Webpack for bundling and Comlink for communication.

Assuming you're already using Webpack, making your Web Worker is super easy:

const myWorker = new Worker(new URL("./path/to/my/file.js"), "my-worker-name");

The bit you give to URL should match exactly what it'd look like in an import or require statement. This works with any path mappings or resolve aliases you might have set up as well.

I.e, if you'd normally import the file like import '@my-app/my-file.ts', then you'd do new URL('@my-app/my-file.ts').

If you're not using Webpack, you should probably consult your own module bundler's docs. If you're not using any bundler, omit the new URL and instead do new Worker("./path/to/your/output/file.js");

Communicating with your Web Worker

This is where Comlink comes into play!

Web Workers, at their core, communicate via posting messages back and forth. Your main thread code communicates with your Worker with worker.postMessage, your Worker listens to those messages with self.onmessage, your Worker responds with self.postMessage, and your main thread listens to those responses with window.onmessage.

That's not very easy to follow, is it?

Comlink removes all that hassle and instead gives you a much nicer Promise-based API.

Let's imagine you've got a Web Worker that simply multiples two numbers. With Comlink, you can set that up like this:

// Worker code math-worker.ts
import { expose } from "comlink";

const multiply = (multiplicand: number, multiplier: number): number =>  {
  return multiplicand * multiplier
}

// Every function we "expose" this way will be available in the main thread. Functions that aren't exposed won't be available.
expose({ multiply });

// Main thread code
import { wrap } from "comlink";

const mathWorker = new Worker(new URL("./math-worker.ts"), "math-worker");

const math = wrap(mathWorker);

// Wrapping mathWorker gives us access to the exposed functions, but now they return Promises!
math.multiply(2, 2)
  .then((product) => {
    console.log(product) // 4
  }

Know anything I should be on the lookout for? Or just general advice?

As I mentioned earlier, your Worker doesn't have access to the DOM or window. That makes sense; you don't actually have a DOM in a Web Worker because you don't have any UI. Outside of that, you can do almost anything you want, including spawning more Workers!

You also can't use this at the root level of your Worker code; use self instead. this still works fine in functions and classes.

Verify that your code is actually running in a Web Worker! This bit me a few times, where I had messed up the setup and had inadvertently ran my worker in the main thread. Super easy to do if you import the file your Worker is supposed to run directly as an import. The easiest way to verify your Web Worker is running is by opening up Dev Tools and going to the "Sources" tab. You should see something like this:

In that image, "top" refers to the main thread, and "platform" and "rhyme-generator" are Web Workers.

If you only see "top", your Web Worker isn't running. This is either because you haven't started it yet (which you do by sending some data to it) or because you've misconfigured it.

Also, remember that concurrency is difficult! Try and keep your Workers as simple and stateless as possible. This'll make your life much easier overall.

One last tip: much like regular threads, there's diminishing returns to having too many Web Workers. A tip that I've heard is the maximum number of Web Workers you should spawn is window.navigator.hardwareConcurrency - 1. We subtract one to save a core for the main thread.

Alright, I think I've got it now! Thanks!

Of course, no problem! Have fun and don't work your workers too hard!

The architecture of an Electron app ported to Web

Wardell Bagby — Mon, 10 Jan 2022 01:27:16 +0000

Hey, y'all! I'm Wardell! In my free time (and when I should be sleeping), I hack on my app, Lyricistant. Buckle up, 'cause this is going to be a long one.

So, what is Lyricisant?

Lyricistant, at face value, is a very simple app. Its own tag line is this:

Lyricistant is a writing app geared toward helping you write lyrics, poetry, or anything else you desire!

I made Lyricistant to help myself write lyrics for my own music, but in true developer fashion, I've kept "just one more feature"-ing it until it ballooned into something much more than what I set out to make.

Going to its website, most of what you see is a big text area, prompting you to type out your lyrics. Typing in some text will show a list of rhymes related to the word near your cursor.

Pretty simple, right? And yet, it'll be reaching its 3rd year of active development in February of 2022. It's also on track to easily surpass 500 commits in 2022. How does something with such a simple purpose still not end up finished after all this time?

To be fair, the length of time a project has been alive and its number of commits isn't a fair measure of the complexity of the project, but still. It's a glorified <textarea> and <ul> with a little bit of Javascript to tie it all together! It's a bit silly, isn't it?

There are a lot of reasons Lyricistant is so complex, but today, we're going to talk about one big one: Lyricistant, which started as an Electron app, now builds both a fully usable offline Electron app and a website from the same codebase. Plus a couple other apps we aren't going to talk about today. The coolest part, though?

The UI code has absolutely no idea... 🤫

Electron is just Chrome + Node. What's the big deal?

I thought the same thing when I first chose Electron for Lyricistant. I'd just write my UI code like how I would for a website, but with the benefit of being able to use Node whenever I want!

That Node pitfall is one of ways that Electron traps ya, though!

Once you start relying on Node, it's definitely not easy to stop. This is doubly true for an app that primarily deals with reading and writing files; there's no easy translation from fs.readFile to <input type="file">.

Outside of Node, there's another big gotcha: Electron has two processes working in tandem, and you communicate between them using only data that is supported by the structured clone algorithm. You can send primitive data, object literals, arrays, and...not much else.

The main process lets you do all your fancy Node stuff; the renderer process runs your UI code.

Communication in a normal Electron app looks something like this:

// in Electron's main process
browserWindow.webContents.send('data-from-main', {hello: 'world'})
ipcMain.on('data-from-renderer', (event, data) => {
  console.log(data.kendrick) // logs 'here'
}

// in Electron's renderer process (i.e., a BrowserWindow)
ipcRenderer.on('data-from-main', (event, data) => {
  console.log(data.hello); // logs 'world'
  ipcRenderer.send('data-from-renderer', {kendrick: 'here'});
});

Imagine you've got a codebase with a ton of those listeners thrown around, and you'll be able to feel the pain I went through when I decided to port Lyricistant to the web.

Alright, I think I'm understanding your struggles. How'd you get rid of all those listeners?

Well....I didn't!

Electron's inter-process communication (aka IPC) is only bad because it's coupled so closely to Electron. The UI code has to know that it's running on Electron so that it knows how to communicate with the main process.

But, there's nothing stopping us from wrapping Electron's IPC with our own, Electron-agnostic logic. Which is exactly what I did.

Enter the Delegate.

export interface Delegate {
  send(channel: string, ...args: any[]): void;
  on(channel: string, listener: (...args: any[]) => void): void;
}

When running on Electron, we provide the UI code with a Delegate that delegates to Electron's ipcMain to communicate between the two processes. Lyricistant calls this object a Platform Delegate.

We also provide the code running in Electron's main process a similar object called the Renderer Delegate. When the UI uses the Platform Delegate to send data, main process code gets that data via its Renderer Delegate. The main process code can also use the Renderer Delegate to send data to the UI.

When running on Web, though...

Wait wait wait. Yes, you can wrap Electron's IPC but browsers still only give you one process... You've got nothing to send data to.

Web Workers would like to talk to you, but that's actually not what I did initially.

Even with a single process, we can emulate Electron's two process model by just calling listeners ourselves!

class WebPlatformDelegate {
  getListeners(channel: string) {
    // return the listeners set on `on`
  }

  send(channel: string, args: any[]) {
    rendererDelegate.getListeners(channel)
      .forEach((listener) => listener(...args));
  }

  on(channel: string, listener: (...args: any[]) => void) {
    addListener(channel, listener);
  }
}

class WebRendererDelegate {
  getListeners(channel: string) {
    // return the listeners set on `on`
  }

  send(channel: string, args: any[]) {
    platformDelegate.getListeners(channel)
      .forEach((listener) => listener(...args));
  }

  on(channel: string, listener: (...args: any[]) => void) {
    addListener(channel, listener);
  }
}

Okay, you've successfully emulated Electron's two processes in a single process. But how do you solve the no-Node problem?

Let's talk about inversion of control. If you're an Android developer like me, think dependency injection, like Dagger. If you're a React developer, think of useContext. If you're a Node developer, think of the service locator pattern.

Regardless of the pattern, the idea is the same; we decouple the platform-specific code from the platform-agnostic code.

Let's use saving a new file as an example. When the user wants to save a new file, Lyricistant needs to do quite a few things!

When running on Electron:

Get the current text that's displayed on the UI.
Show a dialog to let the user pick where to save the file.
Save the data to the file the user picked.
Store the path to the file so that the user won't need to pick it again if they hit save again.

When running on Web:

Get the current text that's displayed on the UI.
Create an <a> tag with a URL to a blob of the current text as its href.
Programmatically click the <a> tag.
Let the browser save the file.

Step 1 is platform-agnostic. It doesn't matter if it's the Electron version or the Web version; the logic for that step is exactly the same. The rest of the steps are platform-specific.

We can use inversion of control to decouple those steps away from the "common" steps. Lyricistant forces its platforms to provide implementations for steps that are platform-specific. For file saving, it looks something like this:

interface FileMetadata {
  /**
   * A unique way of identifying a file, dependent on the platform in question. For instance, against a Desktop
   * platform, we would expect this to be a file path, such as "/Desktop/myfile.txt". On Android, we might expect this
   * to be a content URI, such as "content://documents/1".
   */
  path: string;
  /**
   * A human displayable name that refers to this file in question. If the path can double as a human displayable name,
   * this can be omitted.
   */
  name?: string;
}

interface Files {
  saveFile: (data: ArrayBuffer, path?: string) => Promise<FileMetadata>;
}

Using the Files interface, once Lyricistant has retrieved the text from the UI, it will send that text as an ArrayBuffer to the implementation of Files it had injected, along with any path it might have (remember Electron's step 4?) so that the Files implementation can do the work of saving the file.

By following this pattern, we can do all sorts of stuff without ever knowing for sure what platform we're running on!

Hmm. Okay, but what about those common steps?

Good point.

We also use inversion of control to handle that! Those common steps can be shared across multiple platforms, but the platforms themselves don't really need to know what's handling those steps.

Enter the idea of a Manager. Simple name, I know. Simple interface, too.

interface Manager {
  register(): void;
}

The idea is that we group common functionality into a Manager, and that manager will register listeners on the Renderer Delegate, inject various platform-specific classes to handle platform-specific logic, and send data back to the UI via the Renderer Delegate.

Lyricistant has a few Managers: FileManager, and PreferencesManager to name a couple. Those are core to Lyricistant functionality; you always need to open a file and manage your preferences, no matter the platform.

All platforms need to do is set the list of managers they need and then call register on those managers when the platform starts up. They get all the common code for free. No need to worry about storing the current file, or loading any data the user might not have saved the last time they closed Lyricistant.

However, there's some functionality that only matters to certain platforms. For instance, there's a QuitManager that only Electron uses to manage prompting the user when they attempt to quit the app. It's allowed to use Electron-specific functionality because it's not stored with the rest of the common code. Electron adds the QuitManager to its list of managers, it gets registered with its manager friends, and gets to do its job only for Electron. Web has no idea it exists.

Can I get a tl;dr? That was a lot!

Sure!

There's 3 "types" of code in Lyricistant.

UI code (e.g., the React code that renders the UI)
Platform-specific code (e.g., Electron code that uses Node to save a file, like Files)
Platform-agnostic code (e.g., code that handles coordinating between the UI and the platform-specific code, like the Managers).

In Electron, platform-specific code and platform-agnostic code all run in the main process. UI code runs in the renderer process.

In Web, all code runs in the same process. (At least for now! Be on the lookout for the next Lyricistant release!)

Wow, that's a lot of architecture just to build an Electron app and a website from the same codebase.

You're telling me! It's not perfect by any means, and this isn't even how it is right now; there's a lot of tweaks to this in the repo that haven't been pushed to a new release yet, but the ideas are still very much the same.

I don't think everyone would need to do something as heavy as this; a lot of apps will probably work just fine by doing platform checks in their UI code. Even more would be fine by just solely using browser APIs and not relying on Node at all. Lyricistant is a bit special, mostly because I'm the one who writes it and I like to be more complicated than necessary. 🙃

Even factoring that in, I hope that some of this was interesting, or at least a little helpful to those of you who might be considering creating an Electron app!