There's one specific case I'd like to point out where XMLHttpRequest could be preferred, and is regarding cancellations.
When you abort a fetch call, you are aborting the network call, but the Promise itself is not canceled because Promises don't support cancelation. As you can see, the actual behavior is that the promise throws.
This is fine for most cases and practically all product development, but in very specific and extreme circumstances this might not be desired because Promise ticks are actually expensive and can clog the stack, which can end up having a consequence in the execution flow of the program.
A callback-oriented API that doesn't rely on Promises doesn't have this drawback, and that just wouldn't be possible to do with fetch, but is possible to do with XMLHttpRequest.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There's one specific case I'd like to point out where XMLHttpRequest could be preferred, and is regarding cancellations.
When you abort a fetch call, you are aborting the network call, but the Promise itself is not canceled because Promises don't support cancelation. As you can see, the actual behavior is that the promise throws.
This is fine for most cases and practically all product development, but in very specific and extreme circumstances this might not be desired because Promise ticks are actually expensive and can clog the stack, which can end up having a consequence in the execution flow of the program.
A callback-oriented API that doesn't rely on Promises doesn't have this drawback, and that just wouldn't be possible to do with fetch, but is possible to do with XMLHttpRequest.