Thats a good point.

You need a document context to do any sort of Element construction.

Fetch shouldn't have any dependency on a document since its targeting

I'd say asHTML isn't going to work out. But
document.parseHTMLStream(response.body) seems fine to me. A discussion
for another thread.

On Mon, Jun 23, 2014 at 10:41 AM, Adam Barth <> wrote:
> On Mon, Jun 23, 2014 at 8:28 AM, Anne van Kesteren <> wrote:
>> On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth <> wrote:
>>> XMLHttpRequest isn't particularly cleanly layered.  It's sounds like
>>> you're not overly concerned about layering, which is probably fine.
>> I think I see what you mean. If you wanted to implement this in terms
>> of JavaScript then indeed you would end up importing several modules
>> other than the fetch module to implement these methods. E.g. encoding,
>> for asText, filesystem and MIME for asBlob, and encoding and JSON for
>> asJSON. For asHTML you'd need encoding and HTML.
> Yes, exactly.  However, the sadness comes when the HTML module ends up
> depending on the fetch module because that creates a circular
> dependency.  You then need to merge them into one module, which will
> quickly become the "everything" module.
>> This seems fine to me.
> This discussion is about theoretical purity, which is pretty far down
> the list things we should care about.
>> However, I could see it instead has to go the other way around.
>> Instead of having a bunch of methods on stream to convert it into
>> various other pieces. Other pieces could have ways of dealing with
>> streams. That might make coding a bit more awkward though.
> It might be instructive to think about how the Node community would
> structure these APIs.  Node has a much stronger notion of modules and
> dependencies than browsers because Node uses npm.  As Node developer,
> I would be sad if my networking module dragged in an entire HTML
> implementation.
> Adam

Reply via email to