Modules make passing data back and forth much harder than functions

[domenic]

When trying to offload work into another thread, IMO the syntactic overhead of importing/exporting is too high compared to other languages, or the blöcks proposal, or existing libraries.

Consider wanting to fetch a file at a computed-at-runtime URL, transform its contents, and return the result to the main thread. With this proposal, the best I can come up with is

const endpoint = ...;

const result = await worker([endpoint], module {
  const endpoint = await new Promise(resolve => {
    self.onmessage = ({ data }) => resolve(data[0]);
  });
  
  const res = await fetch(endpoint);
  const json = await res.json();

  export default json[2].firstName;
});

where worker() is a helper function somewhat similar to what is shown in https://github.com/tc39/proposal-js-module-blocks#use-with-workers , although I think it would have to spawn a Worker per invocation in order to allow reliable message passing and translation of default exports into return values. Which is itself not great.

This is worse than other languages, where you can do something equivalent to

const endpoint = ...;

const result = await worker(() => {
  const res = await fetch(endpoint); // closures in other languages can cross thread boundaries
  const json = await res.json();
  return json[2].firstName;
});

or the blöcks proposal, which requires explicit variable capture

const endpoint = ...;

const result = await worker{|
  const res = await fetch(${endpoint}); // special syntax to capture the variable from the outer scope
  const json = await res.json();
  return json[2].firstName;
|};

or something like greenlet which uses IIAFEs:

const endpoint = ...;

const result = await greenlet(endpoint => {
  const res = await fetch(endpoint);
  const json = await res.json();
  return json[2].firstName;
})(endpoint);

Is there a way to use this proposal to get something simpler? Otherwise I am worried that the benefits over libraries like greenlet are not enough to justify the extra overhead one has to incur.

[nicolo-ribaudo]

I think that with the current proposal it would be possible to write something like this:

const result = await worker({ endpoint }, module {
  const { endpoint } = self.workerInput;
  
  const res = await fetch(endpoint);
  const json = await res.json();

  export default json[2].firstName;
});

However, it's still less ideal than automatic captures, and it requires a small library to wrap the Worker constructor.

`worker` implementation

function worker(data, module) {
  const w = new Worker(module {
      let mod;
      self.workerInput = await new Promise(resolve => {
        self.onmessage = ({ data: { data, module } }) => (mod = module, resolve(data));
      });
      export function then() {
        return import(mod);
      }
  }, { type: "module" });

  w.postMessage({ data, module });

  return w;
}

[domenic]

Nice, that's not so bad at all, syntactically. However, the fact that it requires one Worker per invocation, instead of allowing use of a worker pool, seems pretty bad. Can you think of a way to work around that? The fact that there's no per-module data channel, but instead only a per-global data channel, seems problematic.

[surma]

I think there are multiple ergonomic problems around workers and Module Blocks addresses some of them. It focuses mostly on the ability to share code between realms, which should hopefully pave the way to scheduler-like libraries and APIs.

For example, I thought about using Module Blocks something like this to build an OMT task runner:

const taskRunnerWorker = new Worker(module {
  onmessage = ({data} => {
    const {taskModule, parameters} = data;
    const {default: task} = await import(taskModule);
    postMessage(await task(...parameters));
  }
});

taskRunnerWorker.postMessage({
  taskModule: module {
    export default async function(a, b) {
      return Promise.resolve(a) + b;
	}
  },
  parameters: [40, 2]
});
taskRunnerWorker.onmessage = ({data}) => { ... };

(I do realize this is not that different from what @nicolo-ribaudo wrote, but I started writing this before he posted so I figured I’d post it anyway for completeness’ sake.)

You could augment this pattern to re-use the worker for multiple tasks, but then you’d have to keep track of in-flight tasks with ids. That’s one of the ergonomic issues that Module Blocks explicitly does not solve (but is fairly easy to solve in userland).

[domenic]

It focuses mostly on the ability to share code between realms, which should hopefully pave the way to scheduler-like libraries and APIs.

It's the "hopefully" I'm worried about here. By introducing new syntax, you largely close off other explorations in that direction, unless they are direct extensions of the proposed syntax. So I'd like to see a more concrete plan to make sure this feature is usable, before moving it too far forward. IMO a feature which requires a Worker-per-code-block is not really usable.

You could augment this pattern to re-use the worker for multiple tasks, but then you’d have to keep track of in-flight tasks with ids. That’s one of the ergonomic issues that Module Blocks explicitly does not solve (but is fairly easy to solve in userland).

Could you show how that would look, solved in userland? In particular, if it's too heavyweight, then I worry that module blocks is not a good direction, compared to the other three alternatives discussed in the OP.

[nicolo-ribaudo]

This is a mix of my example and Surma's, that allows re-using the same worker for multiple module blocks, adding support for tracking tasks with ids:

import { Runner } from "./runner.js";

const runner = new Runner();

runner.run([1, 2], module {
  export default function(a, b) {
    return a + b;
  }
});

Implementation of Runner

export class Runner {
  #worker = new Worker(workerModule, { type: "module" });
  #finalizers = new Map(); // id -> { resolve, reject }
  #nextId = 0;

  constructor() {
    this.#worker.onmessage = ({ data }) => {
      const { id, action, value } = data;
      this.#finalizers.get(id)[action](value);
      this.#finalizers.delete(id);
    };
  }

  run(params, module) {
    const id = this.#nextId++;
    this.#worker.postMessage({ id, module, params });

    return new Promise((resolve, reject) => {
      this.#finalizers.set(id, { resolve, reject });
    });
  }
}

const workerModule = module {
  self.onmessage = ({ data }) => {
    const { id, module, params } = data;
    
    const { default: run } = await import(module);

    run(...params).then(
      value => self.postMessage({ id, value, action: "resolve" }),
      value => self.postMessage({ id, value, action: "reject" })
    );
  };
};

Note that this isn't as nice as my original example because you have to export a default function, and then that function is called with the input parameters, but it could be solved with #6.

[domenic]

Nice! Yes, that indicates to me that something like #6, or some other mechanism for making it easy to pass per-module data without the extra ceremony of [...args], module { export default function (...args) { /* actual important code */ } } is important for this proposal to become usable in realistic scenarios.

Ideally that something would be shorter than [...args], module function (...args) { /* actual important code */ }. Remember, your competition is

• (...args) => { /* actual important code */ } (...args) (from Greenlet) or
• () => { /* actual important code */ } (from other languages where closures can cross threads).

But module function is probably acceptable.

[littledan]

It seems like what we are coming around to on this thread is: improving ergonomics for transferring data to be sent to the worker can be done separately, in the library (e.g. the Web platform) from this feature, which adds the underlying syntax for the code itself.

[domenic]

I would not characterize my concern that way. I would instead say that providing an ergonomic way of sending per-module (instead of per-global) data needs to be done as part of this proposal, otherwise this proposal is harmful as it encourages patterns like worker-per-block instead of worker pools.

[littledan]

It seems to me that this concern unavoidably spans multiple standards venues: new syntax needs to be added in TC39, but new ways of running worker pools or passing values around between workers needs to be a host API. I'd be in favor of this ergonomic improvement on the Web side, but I don't see how they can be part of the same proposal. I also think the Web side here is a bit riskier--there are many more decision-points, and it's easier to get wrong, whereas there's really only a couple superficial things to decide about module blocks. For these reasons reason, I don't think we should consider web ergonomics a dependency for module blocks.

[domenic]

Ok. I guess we just fundamentally disagree then. I'll channel my concerns to my TC39 rep.

[syg]

I'm confused by the disagreement in the last few comments, specifically:

otherwise this proposal is harmful as it encourages patterns like worker-per-block instead of worker pools.

The expressivity is definitely there already, as demonstrated nicely by @nicolo-ribaudo. Is the harm point that without syntax affordances on top (as part of this proposal), developers will reach for a pattern that spawns too many workers, which is too heavyweight? Wouldn't the heavyweight-ness be readily apparent when the program runs? That is, it doesn't seem like something that'll get ingrained in web apps. The opposite, actually, in that it'll be quickly discovered to be the wrong thing.

While it's not great that it could be easy to reach for, non-performant constructs that are easy to reach for abound, and I expect features that have to do with application architecture like Workers would usually be thought through.

[domenic]

Is the harm point that without syntax affordances on top (as part of this proposal), developers will reach for a pattern that spawns too many workers, which is too heavyweight?

Yes. The proposal in fact tries to make it very easy to spawn too many workers, e.g. with the blob URL integration and the proposed integration with the Worker constructor.

Wouldn't the heavyweight-ness be readily apparent when the program runs?

Usually developer machines are significantly more powerful than end-user machines; we've seen this problem before, and we try to avoid designing new APIs with such footguns. (In particular, I don't really agree with "non-performant constructs that are easy to reach for abound" with regards to recently-shipped web APIs.)

We also have data (I'll try to get it published) that show this problem in action for workers specifically, where attempting to convert an application to use more workers causes bad performance overhead on non-developer devices (e.g., phones). This is part of what is behind the Chrome team's current investment in main-thread scheduling APIs, instead of worker-focused APIs.

[domenic]

Another important aspect of this discussion is the comparison with techniques like greenlet, which do use a worker pool under the hood:

• Greenlet: concise, performant (because worker pool)
• This proposal currently: concise = non-performant (because worker per module); long-winded is required for performance.

Given this comparison, the proposal seems like it would have negative impact on the ecosystem, as people try to use it like they use greenlet, and regress their application's performance.

[nicolo-ribaudo]

I was checking greenlet's source code, and I don't think it's true that this proposal encourages spawning multiple workers more than greenlet does. Greenlet even has an ":bangbang: Important" warning in their readme because it's really easy to spawn multiple workers rather than always re-using the same one.

A greenlet-like API would also work for this proposal (this example is from greenlet's readme):

import greenlet from 'greenlet'

let getName = greenlet(module {
    export default async username => {
      let url = `https://api.github.com/users/${username}`
      let res = await fetch(url)
      let profile = await res.json()
      return profile.name
    }
})

console.log(await getName('developit'))

I cannot think of a more coincise version of it that "accidentally" spawns more than one worker. (obviously module async function (username) {} or module async username => {} are more coincise, but that's just syntax sugar)

However, this proposal will never be more coincise than greenlet for the single-function usecase, but it makes it easier to create more complex workers (e.g. workers with state, or with dependencies).