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 parser. That said, I don't care particularly strongly either way. / Jonas
