16:09
<ljharb>
Because while a browser can hardly ship a breaking change, runtimes fairly "regularly" do (over a time frame of multiple years, though). Of course, usually those breaking changes only affect their own runtime-related APIs or embedding APIs but there isn't really anything to say that those couldn't also affect some deeper JS APIs.
right, but devs want to run their code in both places, and run web code outside the web. node and friends are moving closer to the web, not farther from it, with things like WinterTC
20:06
<Aapo Alasuutari>
right, but devs want to run their code in both places, and run web code outside the web. node and friends are moving closer to the web, not farther from it, with things like WinterTC
Fair point yeah. I guess my viewpoint is more of a "language evolution" viewpoint: I don't see the benefit of the features but I do see downsides, and I would personally see them removed as both a career TS/JS developer and a JS engine hobbyist developer.
20:13
<ljharb>
that’s not the way JS or the web evolves, generally - nothings ever removed, change is additive.
20:35
<bakkot>
The benefit of the features is existing code continues to work
21:23
<Aapo Alasuutari>
Yeah, hence the thought of making these parts optional legacy or Annex B. But I do see that this idea does garner interest in the slightest, and so that is that :)
21:55
<Aapo Alasuutari>
*doesn't