The new API is smaller and simpler. Less to implement and less for web developers to understand. If it can meet all our use-cases without significant performance problems, then it's a win and we should do it.
For line-endings, you could have the Blob constructor also take an optional endings argument: new Blob(String|Array|Blob|ArrayBuffer data, [optional] String contentType, [optional] String endings); On Tue, Oct 25, 2011 at 11:57 AM, Michael Nordman <micha...@google.com>wrote: > This ultimately amounts to syntactic sugar compared to the existing api. > It's tasty, but adds no new functionality. Also there's still the issue of > how this new api would provide the existing functionality around line > endings, so less functionality at the moment. I'm not opposed to > additions/enhancements, just want to put it in perspective and to question > whether the api churn is worth it. > > On Mon, Oct 24, 2011 at 10:19 PM, Erik Arvidsson <a...@chromium.org> wrote: > >> On Mon, Oct 24, 2011 at 19:54, Jonas Sicking <jo...@sicking.cc> wrote: >> > Sure. Though you could also just do >> > >> > var b = new Blob(); >> > b = new Blob([b, data]); >> > b = new Blob([b, moreData]); >> >> That works for me. >> > I'm happy with this. In theory, vendors could implement this using copy-on-write or something similar so that this pattern is roughly as efficient as BlobBuilder, right?