On Mon, Jun 23, 2014 at 8:46 AM, Domenic Denicola
<dome...@domenicdenicola.com> wrote:
>> 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.
> This is a great point. From this perspective, JSON is fine since it's part of 
> the JS language. Encoding is a bit on the edge; it's a judgement call based 
> on whether your "networking module" wants to recognize the fact that networks 
> often transport text, or whether it should stay purely on the bytes level. 
> The convenience argument pushes me toward saying encoding is OK, especially 
> since that's a unidirectional dependency. But HTML is definitely out.

Note that you can't do JSON decoding without first doing binary->text
decoding. So by having a "asJSON" function we are automatically
pulling in charset conversion.

I think I was one of the original proponents of adding "json" as a
native type to XHR. I'm not sure that this was a good idea. Especially
not now given that we are so close to having a real Stream primitive,
and that we will surely need an API for piping a Stream into a JSON

That said, I don't care particularly strongly either way.

/ Jonas

Reply via email to