Repository navigation
Implement window.fetch into core #19393
Description
Activity
this has come up from time to time but has not had much traction just yet. Let's see what folks think tho :-)
bradley and i were discussing this in a roundabout way on the subject of
importing from urls. if that feature was introduced (and i think in general we do want it) we would need to implement this: https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-single-module-script which uses the fetch spec. as another note if this was added in core i would want to pull in an existing c++ implementation from one of the browsers. however at a bare minimum node will definitely be addingRequestandResponseobjects, it just might not add a function calledfetchReacted by Jonathan Neal, Lonnie Best, ExE Boss and bl-ue-1 this kind of higher-level functionality is best left to userland
Reacted by Mike MacCana, Nick K., Pooya Parsa, Mathias Buus, Vladimir Kurchatkin, Sérgio Ramos, Jason Palmer, Anna Henningsen, Benjamin Gruenbaum, Francisco Brito and 9 moreReacted by Benjamin Atkin, Thibault Maekelbergh, Jon Abrams, Axel Rauschmayer, Ari Porad, Eric McCormick, Stefan Duberg, Sindre Sorhus, thecodingdude, le0nik and 157 moreReacted by Stan Mots, Jeff Hansen, Daniel Ennis and Lonnie BestReacted by Mike MacCana, Nick K., Denis Elistratov and bl-ueReacted by bl-ue and Prakash SellathuraiThis would definitely be useful in simple cross-platform APIs and I think is what a lot of people use node-fetch for already. Also it would be nice if HTTP/1 v HTTP/2 negotiation can be handled automatically like in browsers as well.
Reacted by Steven, Attila Oláh, Felix Becker, Ryan Zimmerman, snek, Oliver Turner, Axel Rauschmayer, Thomas Parisot, Eric McCormick, Wildan M and 61 moreReacted by Daniel Moeller, josephrocca and MartinI would love this! ❤️
Isomorphic JS is one of the big reasons people who start with JS on the front end, eventually pick up Node.js on the backend.
You get to run the exact same function in the browser and the server and the one place of contention I keep finding is window.fetch.
Some of the code that runs on the server and client needs to make HTTP requests to another server (think microservices with server side rendering and client side rendering).
One case for bringing it into core is that making HTTP requests (client) is closely tied to responding to HTTP requests (server).
And we now have isomorphic URL parsing so now all we need is fetch! Let’s make fetch happen!
Reacted by Jakob Guddas, Jayden Seric, Mallory Allen, Scott MacLellan, Moritz Mahringer, Jimmy Wärting, Szymon Marczak, Yariv Gilad, Erik van de Pol, Stan Mots and 32 moreReacted by Flora Moon and Randall LeedsFetch is 'low level' according to it's author and major supporter hence missing a bunch of features like support for content types, JSON not being default, no query string encoding. Apps that need a high level quality HTTP client available in all JavaScript environments can continue using superagent.
Reacted by Francis GulottaReacted by Coco R, Sigurd Fosseng, Mohamed Benr, Alex, Igor Bari, Alex Regan, Jinesh Shah, Dallas, Juha Karttunen, Jack5079 and 17 moreReacted by snek, GP, Moritz Mahringer and Juha Karttunen@mikemaccana the fetch we are talking about is https://fetch.spec.whatwg.org/ and i don't think its appropriate to be plugging other http libraries
Reacted by Nikita Skovoroda, James Browning, Scott MacLellan, Ryan Guild, Huxulm, Sigurd Fosseng, Alex, Igor Bari, Maximilian Berkmann, Jinesh Shah and 10 moreReacted by Mike MacCana@devsnek Yes I know, that's the one I was specifically referring to. I don't have any particular enjoyment of superagent asides from it being:
- a full featured HTTP client
- available in node and the browser
- more popular than fetch
- has JSON as a default
- encodes query strings
- uses content types to determine response body
- uses HTTP verbs as method names, so you can happily
.get()and.post()things rather than 'fetching with method POST' which is a somewhat odd mental model
If fetch supported these I'd suggest it be included in node. To repeat: I've asked fetch's author and main proponent, Jake Archibald, why it doesn't support these things and it's stated that fetch is designed to be a low level API and things like sensible defaults can/should be added by higher level APIs. As a result I see no reason to use fetch in node, or in the browser.
Reacted by Hendy IrawanReacted by Coco R, Yury, Sigurd Fosseng, Alex, Krasimir Nedelchev, Igor Bari, Maximilian Berkmann, Jinesh Shah, Goran Gajic, Jack5079 and 18 moreThese are actually desirable properties for the argument of including fetch in Node.js core, if we want to keep the core low-level and small. I believe we will need to eventually provide a promisified API for http/http2 anyway, and fetch as an existing spec for a similar set of low-level functionality as our http is something worth considering. In my experience the missing pieces in fetch feels pretty similar to the missing pieces in Node.js's http, the major difference is that you have a spec'ed API to count on.
Also I kind of doubt the "more popular than fetch" part, I don't think there are as many people using super-agent in the browser as in Node, given that fetch simply exists in the browser (modulo situations needing polyfills)?
Although, before we start implementing fetch, I believe we will need to introduce the stream API in the browser? Is introducing yet another stream in Node.js on the table?
The one time I've been forced to resort to XHR in the browser was when I needed progress, although I think with the browser's ReadableStreams it's possible to do the same thing with an API that's a bit awkward (
res.body.read().byteLength)- if I'd implement progress in Node.js I think I'll need to usechunk.byteLengthfrom the chunk being emitted in thedataevent, which is where the difference between the two streams start to matter.Also, the fetch spec does not seem to include timeout or agents (yet?) at the moment, there might be more functionalities missing compared to our existing http API. For reference, node-fetch seems to implement these non-standard options. Again, not sure if our implementation should implement non-standard functionalities even if they supply the missing pieces compared to the old API.
Reacted by Aria Buckles, kumavis, Maximilian Berkmann, Nico, Lukas, ExE Boss, Daniel Moeller, Ivo Janssen, stefnotch, Odin Hørthe-Omdal Urdland and 2 moreReacted by Mallory Allenalso cc @TimothyGu you might be interested?
Reacted by Stevenentirely disagree; Node uses v8, and by extension, should implement as many as v8 features as possible that make sense. fetch is one of those where developers wouldn't need to npm install request or node-fetch which are very popular libraries so this functionality warrants being in core.
Technically fetch is not a v8 feature though, it's an API spec'ed by WHATWG, whereas v8 implements ECMA-262, a spec by ECMA TC39 - if v8 implemented fetch then there would not be this feature request, because we basically just expose what v8 exposes.
BTW: I don't think we are talking about pulling npm packages into the core? Rather, we are talking about implementing the spec on our own and pulling in the WPT to test compliance, possibly with a bunch of code written in C++, much like what we did for WHATWG URL.
Reacted by Michaël Zasso, snek, Mike MacCana, Adam L Barrett, István Szmozsánszky, F. Hinkelmann, Mallory Allen, linarnan, kumavis, armando magalhaes and 10 more@thecodingdude the continued popularity of non-fetch libraries isn't a personal opinion, it is a fact - superagent had 1.6 million downloads this week . Nor is the lack of reasonable high-level defaults in fetch: again (again) that is acknowledged by fetch's author. Please don't reframe verifiable objective technical facts as irrelevant subjective opinions because you do not like them.
please don't plug other libraries here, they are irrelevant to our discussion.
developers wouldn't need to npm install request or node-fetch
😂👍
Reacted by bl-ueReacted by Mallory Allen, Carlos Araya, Leon Aves, kumavis, Coco R, Sigurd Fosseng, Alex, Alexandr Yushkov, Krasimir Nedelchev, Igor Bari and 22 more249 remaining items
If the conclusion here is that when/if
window.fetchis going to be implemented in core, then it's going to be throughundici, then I guess this issue can be closed in favor of #38533 as that one is discussing how to move forward with the future of the Node HTTP Client and howundicifits into that and how it can be the way forward.It in turn depends on nodejs/TSC#1041 / https://github.com/nodejs/node/discussions/39779 which discusses the principles around what belongs in core or not.
Anyone of a different conclusion?
Reacted by Tom Sherman, Ethan Arrowood, Robert Nagy, Jordan Harband, Amio Jin, ExE Boss and Théo LUDWIGI never thought to see the day. Thank you! ❤️
Reacted by Anton Bessonov, Mark, Karl Kristian Lockert, Yordis Prieto, Steven, okmttdhr, tada, Sundeep Joseph Machado and max-hkReacted by silverwind, Madeline Gurriarán, Ali Kadir Bagcioglu, Felix Hungenberg, Karl Horky, Daniel Plakinger, Jason Williams, ritchie, Thomas Gauges, Yordis Prieto and 10 moreReacted by Jordan Harband and Yordis PrietoReacted by Matteo Collina, Michaël Zasso, Benjamin Gruenbaum, Théo LUDWIG, Madeline Gurriarán, Ali Kadir Bagcioglu, Valentin Semirulnik, Karl Horky, Sigurd Øines, Daniel Plakinger and 10 moreReacted by Karl Horky, ritchie, Yordis Prieto, Steven, Martin Heidegger, Yann イーベス Eves, Miloš Paunović, Gabriel Delépine, Kelly Milligan, Binit Ghimire and 1 moreIs there still time to rename it? In electron we suddenly have two different fetches right next to one another. If nobody else, i know i'll be confused one day.
Reacted by ScriptKitty, Bogdan Chadkin, Alex Moon, Sukka, Serhii Mamedov, Alyx, max-hk, Alan Orozco, silverwind and Al JohriReacted by Jan PotomsWe all know it takes effort to make things work and not break anything.
You had to overcome pressure from a lot of ungrateful people not seeing the full picture.
So thank you, guys. We all appreciate your hard work.
Keep it up!Reacted by Anton Bessonov and MikeReacted by Michaël Zasso and Martin HeideggerWe all know it takes effort to make things work and not break anything.
You had to overcome pressure from a lot of ungrateful people not seeing the full picture.
So thank you, guys. We all appreciate your hard work.
Keep it up!Sign that!
Thx for all your hard work, to keep Node going. Thx a lot!
Edit: Fetch is available through the
--experimental-fetchflag in Node. This is still very new :]Edit: please note that this issue is pretty old and a lot of the information in the first few comments isn't up to date - for current status please see #19393 (comment) .
https://github.com/bitinn/node-fetch
It would make sense if window.fetch was implemented into core. it seems to be a stable enough API that would make a good candidate for inclusion. Not sure what the process is from here but thought I'd raise an issue :)