Is new Worker(module { ... },) a bad idea?

[surma]

If I understand @domenic correctly, he is concerned that making the Worker constructor accept a Module Block removes too much friction from creating Workers and creates a risk of developers creating one-off workers for single tasks which would be counter-productive for performance.

---

Here’s how I plan to address that concern:

Making the worker constructor (and worklet constructors!) accept module blocks is a core feature of this proposal. It is one of the most frequently cited issues around Workers and Worklets. Without this, I don’t think there is a point in moving forward with this proposal (unless we want to encourage workarounds like @nicolo-ribaudo showed).

Workers are currently barely used at all (apart from ReCAPTCHA driving up the usage stats), so I don’t share the concern that people will start spam-creating workers. The Blink worker team and the scheduler team don’t have strong opinions on this, either.

That being said, in the long-term, developers being irresponsible with Worker creation is worth thinking about. If we want to mitigate worker abuse, however, it should not just address worker abuse done via Module Blocks. There are libraries (like Greenlet) that make it ergonomic and easy to spam-create workers today, without module blocks. Any mitigations we come up with should cover those patterns as well.

---

@domenic have I captured your concern accurately? If not, where am I misunderstanding you? If yes, can you help me understand why my proposed solution is insufficient? Considering that I believe that allowing people spin up workers without a separate file is essential, can we find a way forward here?

[nicolo-ribaudo]

For reference to future readers, the workaround I showed is #21 (comment).

[leobalter]

@surma @domenic I wonder if the context from #45 has some weight on these concerns.