I think a good rule for any web API is that the user's needs come before the
author's needs. In this case there is a very large amount of content out
there today that uses XMLHttpRequest to download data, sometimes significant
amounts of data, and that use .responseText exclusively to access that data.
Adding a new feature to the API that causes this use case to be worse for
the user (by requiring it to use twice as much memory) seems like a clear
non-starter to me - that would be putting authors before users. Would you
accept a new DOM feature that required each node to use twice as much
memory? The memory use and heap pressure caused by XHR has been an issue
for Chrome in the past and our current implementation is pretty carefully
tuned to not preserve extra copies of any data, not perform redundant text
decoding operations, and to interact well with the JavaScript engine.
It's true that it might be a convenient API for authors to provide the
response data in all formats at all times. However this would not benefit
any content deployed on the web right now that uses responseText exclusively
and would make the user experience unambiguously worse. Instead we need to
find a way to provide new capabilities in a way that does not negatively
impact what is already out there on the web. Within this space I'm sure
there are several good solutions.
As another general note, I think it's rather unfortunate how many
different responsibilities are currently handled by XMLHttpRequest. It's
the networking primitive of the web, but it also provides text decoding
capabilities and XML parsing (of all things) for historical reasons. It's a
very awkward API and it should be gaining fewer responsibilities over time,
not more. Ideally an author should be able to use XHR just to take care of
networking and for other APIs to provide other new capabilities. For
example, it should be possible to take a sequence of raw bytes off the
network from XHR and interpret some subset of the sequence as UTF-8 text and
the rest as audio data. This would be possible using some form of
.responseArrayBuffer and ArrayBufferViews if text decoding was exposed as
its own API rather than only as a feature of XMLHttpRequest. This is
somewhat pie-in-the-sky right now, but I think it's important to keep in
mind as a longer term goal.
I'm not convinced that we need to worry overly much about legacy libraries
mishandling .responseArrayBuffer. Any code that tries to handle
.responseArrayBuffer will by definition be new code and will have to deal
with the API whatever that ends up being. Code that wants to use
.responseText can continue to do so, but it won't be able to use
.responseArrayBuffer as well. Seems like a pretty simple situation as such
things go.
- James