- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 23 Jun 2014 12:35:34 -0700
- To: Domenic Denicola <domenic@domenicdenicola.com>
- Cc: Joshua Peek <josh@joshpeek.com>, Adam Barth <w3c@adambarth.com>, WHATWG <whatwg@whatwg.org>
On Mon, Jun 23, 2014 at 8:46 AM, Domenic Denicola <domenic@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
Received on Monday, 23 June 2014 19:36:30 UTC