I don’t have a dog in the fight. I also don't see yet any mainstream support behind the proposal. So I don’t get why it has to be so heated? The main benefit i

I don’t have a dog in the fight. I also don't see yet any mainstream support behind the proposal. So I don’t get why it has to be so heated? The main benefit is interop. Same with promises. You can implement all of promises with custom callbacks - in fact it’s trivial. But competing implementations don’t typically land on API compatibility simply because they’re solving the same problem. That causes a fractured ecosystem. Maybe interop could be important with signals? I think they should argue that, if so! > Users will still need to use libraries for that, just like they do today. Yes? But you reduce the lifting by the libs - ideally enabling a class of vanilla use-cases which can be made demonstrably improved. You could say querySelector was unnecessary because you can do it in lib. Or filter, or map. Standardization can cover std-lib like features too no? Doesn’t mean I am in favor. I think you should always default to no unless strong and consistent proven benefits. But why not have good faith arguments for what problems this will or won’t solve. For instance, if hypothetically let’s say react or svelte has a different model that cannot possibly use these signals, then that’s probably a sign it’s not good. My philosophy with proposals is balancing the curiosity and honest inquiry with a grumpy defensive inquisition before saying aye. Flaming though is really not helpful. > You're basically saying that we should add signals to JS because we've added (much simpler or more needed) things to JS before > saving bundle size Yes, I agree these are weak arguments.