[Metasyntactic]

I wrote several of typescript's initial compilers. We didn't use red/green for a few reasons:

• The js engines of the time were not efficient with that design. This was primarily testing v8 and chakra (IE/edge's prior engine).

• Red/green takes advantage of many things .net provides to be extremely efficient. For example structs. These are absent in js, making things much more costly. See the document on red-green trees I wrote here for more detail: https://github.com/dotnet/roslyn/blob/main/docs/compilers/De...

• The problem domains are a bit different. In Roslyn the design is a highly concurrent, multi-threaded feature-set that wants to share immutable data. Ts/JS being single threaded doesn't have the same concerns. So there is less need to efficiently create an immutable data structure. So having it be mutable meant working well with the engines of the time, with sacrificing too much.

• The ts parser is incremental, and operates very similarly to what I describe in for Roslyn in https://github.com/dotnet/roslyn/blob/main/docs/compilers/De.... However, because it operates on the equivalent of a red tree, it does need to do extra work to update positions and parent pointers.

Tldr, different engine performance and different consumption patterns pushed us to a different model.

[conartist6]

I ask because I picked up where the TS and Roslyn teams left off. I actually brought red green trees into JS.

My finding is that the historical reasons against this no longer seem to apply today. With monomorphic code style JS has close enough to structs. Multi threading is now essential for perf.

I don't even think multithreading is the strongest argument for immutability, because it's not only parallelization that immutability unlocks but also safe concurrency, and/or the ability to give trusted data to an untrusted plugin without risking corruption