| 02:29 | <sachag> | yeah it's not easy to know what's what… |
| 18:05 | <ljharb> | Intl is sort of in the middle, but it's in browsers and node, so it feels more language than web to me |
| 18:05 | <ljharb> | and i do actually think most devs end up with a mental model of "browser stuff", "node stuff", and "universal/isomorphic stuff", and are pretty aware of the difference |
| 18:05 | <ljharb> | things like setTimeout, that are universal but not in the language spec, muddy the waters a bit, ofc |
| 18:08 | <bakkot> | and URL |
| 18:08 | <bakkot> | someday, fetch |
| 18:09 | <bakkot> | I think the distinction is mostly relevant for IO things |
| 18:09 | <bakkot> | like, fs is node-only, the DOM is browser-only |
| 18:10 | <bakkot> | that doesn't map that cleanly to "tc39 spec vs whatwg spec" |
| 18:11 | <ljharb> | URL true. fetch never, because a compliant fetch isn't possible outside a browser (i'd love a universal abstraction for "make an http request and get a promise", but fetch sadly isn't eligible to be it) |
| 18:11 | <ljharb> | very true tho, it's not a clean mental model around spec boundaries |
| 18:11 | <ljharb> | but it's pretty close |
| 18:13 | <bakkot> | aw I thought they were gonna do that |
| 18:13 | <bakkot> | what makes it not possible outside a browser? |
| 18:55 | <ptomato> | things like setTimeout, that are universal but not in the language spec, muddy the waters a bit, ofc |
| 18:56 | <ljharb> | bakkot: node doesn't have cookies, or a "current URL", and a bunch of other stuff |
| 18:56 | <ljharb> | node could ship a partial fetch but it's either 100% fetch or it's not fetch ¯\_(ツ)_/¯ |
| 18:58 | <TabAtkins> | Just default "current URL" to "https://example.com";, done |
| 19:05 | <ljharb> | then iirc node would have to factor in same-origin restrictions, CORS, local cookies, etc, none of which apply to node |
| 19:06 | <ljharb> | it's just a category error to try to use fetch outside a browser; it (like most web things) just wasn't designed for non-web use |
| 19:08 | <TabAtkins> | (My suggestion was shitposting.) |
| 19:10 | <bakkot> | ehhhhhhhhhh this sounds like one of those distinctions which is unlikely to matter to users in practice |
| 19:10 | <bakkot> | if node has a global named fetch that I can use the way I would use fetch I do not care if the lack of cookies means that in fact they do not "have fetch" |
| 19:18 | <Luca Casonato> | what makes it not possible outside a browser? fetch implementation. Deno only really leaves out two main specification features: cookie jars and CORS. |
| 19:42 | <ljharb> | something that you can use in the ways you would use fetch, but not in all the ways you would use fetch, will cause more harm than good. i'm aware of deno's implementation. |
| 19:43 | <ljharb> | it's the same harm caused by a noncompliant polyfill. if you want less than 100% compliance, then it's better to use something that isn't purporting to match a spec. |
| 19:43 | <Luca Casonato> | Let's chat about it some time. I don't think this is the right venue though :-) |
| 19:44 | <ljharb> | fair enough :-) |
| 20:24 | <bakkot> | if the conversation happens in public, ping me? |