4 ms·

> "The fact that creating a worker requires you to pass a module (file) name makes them extremely unergonomic to use." Can anybody explain how did this ever ma

> "The fact that creating a worker requires you to pass a module (file) name makes them extremely unergonomic to use." Can anybody explain how did this ever make it into the official spec and the default implementation? The browser will make a network call to fetch your Web Worker .js file on every instantiation of your Web Worker. Instantiations of the same Web Worker "module" aren't cached, so in a thread-pool scenario your browser would be fetching the same file over and over again. What were the people designing this even thinking? This is so wasteful and frustrating. The API simply sucks.

dmitriid 5y ago
> Can anybody explain how did this ever make it into the official spec and the default implementation? This and service workers. Both are... weird, to say the least
- csmpltn 5y ago
  When I'm seeing half-arsed APIs like this being introduced into so-called "modern" incarnations of the web, I start doubting the technical chops of the people involved and the process as a whole. Is it truly possible that there wasn't anyone with sufficient experience in building concurrency/multi-threading/parallelism APIs involved in building this? Failing to account for the thread-pool scenario, as an example, is just mind boggling.
TAForObvReasons 5y ago
"best guess": API decisions are opinionated, reflecting the designers' views of how users should write code. For example, FileReader API is async in the main thread. There's an equivalent FileReaderSync for sync operations but that is only available in Web Workers. Why isn't FileReaderSync available on the main thread? Because the designers didn't want people to do things that would block the main thread. The Web Worker argument probably went along the lines of "If we allow users to pass arbitrary function objects, they may try to do something that accesses local variables from the site where the worker is created. That is obviously an error, so we should design the API so that it can't happen. Creating a separate script creates a clear mental separation and avoids that class of error"

dmitriid 5y ago

> Can anybody explain how did this ever make it into the official spec and the default implementation? This and service workers. Both are... weird, to say the least

csmpltn 5y ago
When I'm seeing half-arsed APIs like this being introduced into so-called "modern" incarnations of the web, I start doubting the technical chops of the people involved and the process as a whole. Is it truly possible that there wasn't anyone with sufficient experience in building concurrency/multi-threading/parallelism APIs involved in building this? Failing to account for the thread-pool scenario, as an example, is just mind boggling.

TAForObvReasons 5y ago

"best guess": API decisions are opinionated, reflecting the designers' views of how users should write code. For example, FileReader API is async in the main thread. There's an equivalent FileReaderSync for sync operations but that is only available in Web Workers. Why isn't FileReaderSync available on the main thread? Because the designers didn't want people to do things that would block the main thread. The Web Worker argument probably went along the lines of "If we allow users to pass arbitrary function objects, they may try to do something that accesses local variables from the site where the worker is created. That is obviously an error, so we should design the API so that it can't happen. Creating a separate script creates a clear mental separation and avoids that class of error"