| 01:53 | <Justin Ridgewell> | ^^ That's how I do it with prettier and eslint |
| 01:53 | <Justin Ridgewell> | I've never seen a good CST system yet |
| 01:55 | <Justin Ridgewell> | Rome is apparently trying with Red/Green Trees: https://rome.tools/blog/2021/09/21/rome-will-be-rewritten-in-rust |
| 03:51 | <rickbutton> | oh interesting, thanks for the link |
| 10:00 | <vrafaeli> | Can someone help me understand how "browser's built-in API callbacks" work? For example when I define websocket's onmessage, or fetch callback. For example with fetch. this is basically a promise which when resolved needs to process the then callback with the result. The callback closure is defined at the time of "then" method invocation. Does the set up callback closures go in some separate JS-closures-memory-space and gets assigned some reference? This reference is used by the task in the task queue, and when it's its time to run, the task says to the engine to put the referenced closure on the main thread? |
| 12:56 | <Ashley Claymore> | I think your understanding is correct. Though there isn’t necessarily a need for a “separate JS-closures-memory-space”. Closures can be objects that live on the same JS heap as the other JS objects. And host-integrations can keep references to JS objects that will be compatible with the JS garbage collector. |
| 13:03 | <vrafaeli> | I think your understanding is correct. Though there isn’t necessarily a need for a “separate JS-closures-memory-space”. Closures can be objects that live on the same JS heap as the other JS objects. And host-integrations can keep references to JS objects that will be compatible with the JS garbage collector. |
| 13:04 | <vrafaeli> | The only difference is that these objects are not referenced from JS "context" but from outside of the context |