Language evolves and changes over time. I don't know whether the popular/common usage for the intended meaning (provide an alternative implementation of a function or method) has begun using "overwritten," but I'd argue that the underlying runtime implementation matters.
Typically, one's own implementations doesn't have the ability to literally overwrite the original - the original exists in some place and continues to exist in that place. You can point original symbols at a new implementation, but that old implementation isn't "overwritten" in memory. In OO runtimes, you can override in a subclass (but not overwrite), and the super class implementation is still right there, available as needed.
In the discussed case, if anything is truly "overwritten," it's the value (pointer?) at the symbol "requestAnimationFrame," but I'm doubting that's even that case - I'd wager (without being a deep JS expert) that the original is available in another scope.
Even given all that, if popular usage wants to go with "overwritten," fine - I'm not a linguistic purist.
Typically, one's own implementations doesn't have the ability to literally overwrite the original - the original exists in some place and continues to exist in that place. You can point original symbols at a new implementation, but that old implementation isn't "overwritten" in memory. In OO runtimes, you can override in a subclass (but not overwrite), and the super class implementation is still right there, available as needed.
In the discussed case, if anything is truly "overwritten," it's the value (pointer?) at the symbol "requestAnimationFrame," but I'm doubting that's even that case - I'd wager (without being a deep JS expert) that the original is available in another scope.
Even given all that, if popular usage wants to go with "overwritten," fine - I'm not a linguistic purist.