| 00:12 | <Mathieu Hofman> | That's much better indeed |
| 07:10 | <sirisian> | I just checked the logs to see, and you guys did see that pull request. We were talking about that in here ages ago. Seeing the amount of work it takes to get that actually setup, I can see why others were hesitant on the concept despite it being so much better for developers. |
| 16:02 | <ljharb> | "better for developers" isn't even a given imo |
| 18:59 | <sirisian> | Is there a better design? My biggest pain point with workers has always been the setup. Old setup I pasted to someone a few years ago: https://gist.github.com/sirisian/df6666349b1fd4eaf831834169052c6f In my ad-hoc examples where I need threads it's always the most awkward code. I did a PPO project last week with Claude and it used the same basic setup for 24 threads. I have a multithreaded noise library I used sometimes that filled with this kind of code and the function passing stringifying is awkward. Even the URL.createObjectURL approach some use has the same awkward export string wrapping. Fine if one has everything separated in files though, but that it was never designed for a single file use has always been strange as no other language has this approach. |
| 19:03 | <nicolo-ribaudo> | https://github.com/tc39/proposal-module-expressions tries to solve the multi file problem |
| 19:04 | <nicolo-ribaudo> | And then there would be to be some promise-based library that abstracts away postMessaging to call functions in the worker |
| 20:39 | <bakkot> | or, ideally, carefully designed shared-memory objects which could avoid the overhead of copying things back and forth https://github.com/tc39/proposal-structs |