4 ms·

A new standard would need buy-in from browsers to actually be a standard. Browsers likely don't have a lot of incentive to make spec changes only Node is intere

by inglor 5y ago

A new standard would need buy-in from browsers to actually be a standard. Browsers likely don't have a lot of incentive to make spec changes only Node is interested in (like making the whole spec more complicated from their point of view because of Node's (or Deno's) different security model). The level of collaboration and good-faith we've been getting from spec bodies like WHATWG is very high as it is and we really don't want to push or abuse it.

andrewl-hn 5y ago
Does it have to be a buy-in, though? You could agree on server-specific extensions to fetch and codify them in the same spec (so it doesn't get lost otherwise). Browser vendors wouldn't need to implement it but they will still keep an eye on it when working on future browser apis.
- tehbeard 5y ago
  Codifying the redirect behaviour for server/"trusted" envs makes some sense with Deno/node doing the same thing. I'm not versed enough in the standards orginazation politics to say if that's viable though. The rest of your "improvements" aren't that. They're opinions, opinions laser focused on a JSON centric api. I'm sorry to say this, but not all of the web is one big JSON blob. Some of us have to talk to SOAP (xml) services. Sometimes it's weird rpc stuff with protobuf. Or even just pulling down raw binary data and feeding that through an API/library that wasn't built for web streams. Honestly, the amount of code you need to add over the top of a primitive like the Fetch API to get what you wanted (bar the redirect change) is trivial and minimal.
  - Scarbutt 5y ago
    Can you share your setup for talking to SOAP services?
true_religion 5y ago
It would be useful for trusted browser extensions too, as well as probably Electon apps as well. I don’t know if chrome apps are still in existence, but if they are the “server side” fetch spec could apply to them too.
nailer 5y ago
> Browsers likely don't have a lot of incentive to make spec changes only Node is interested in All the existing HTTP clients discussed in the previous post also run in the browser.

by inglor 5y ago

andrewl-hn 5y ago

Does it have to be a buy-in, though? You could agree on server-specific extensions to fetch and codify them in the same spec (so it doesn't get lost otherwise). Browser vendors wouldn't need to implement it but they will still keep an eye on it when working on future browser apis.

tehbeard 5y ago
Codifying the redirect behaviour for server/"trusted" envs makes some sense with Deno/node doing the same thing. I'm not versed enough in the standards orginazation politics to say if that's viable though. The rest of your "improvements" aren't that. They're opinions, opinions laser focused on a JSON centric api. I'm sorry to say this, but not all of the web is one big JSON blob. Some of us have to talk to SOAP (xml) services. Sometimes it's weird rpc stuff with protobuf. Or even just pulling down raw binary data and feeding that through an API/library that wasn't built for web streams. Honestly, the amount of code you need to add over the top of a primitive like the Fetch API to get what you wanted (bar the redirect change) is trivial and minimal.
- Scarbutt 5y ago
  Can you share your setup for talking to SOAP services?

true_religion 5y ago

It would be useful for trusted browser extensions too, as well as probably Electon apps as well. I don’t know if chrome apps are still in existence, but if they are the “server side” fetch spec could apply to them too.

nailer 5y ago

> Browsers likely don't have a lot of incentive to make spec changes only Node is interested in All the existing HTTP clients discussed in the previous post also run in the browser.