3 ms·

Note that it's really dom centric and doesn't include ajax.

by BiteCode_dev 2y ago

ceejayoz 2y ago
Isn’t AJAX fairly well supported via fetch now?
- jitl 2y ago
  Yeah at this point I’ve totally forgotten $.ajax API but fetch is pretty easy, just a single function call
  - amelius 2y ago
    Now we only need something that makes websockets more resilient against network errors and corporate firewalls.
- BiteCode_dev 2y ago
  In the same way selectors and map replace jquery. It depends how much sugar you want.
- _hyn3 2y ago
  ... unless you want to send a body with your HTTP GET. There is tons of utility value in this! For example, let's say you want to GET some data but also provide some client request statistics along with the request -- happens all the time in the real world. Fetch will reject your GET if it contains a body (a deliberate maintainer decision), even though it's entirely permissible by HTTP and done by many real-world AJAX APIs. Real AJAX will do what it's supposed to. (The HTTP 1.1 2014 Spec says that including a request body in a GET "might cause some implementations to reject the request." Guess which one!) Also, advanced features like progress are completely absent from Fetch as well. However, there are some fantastic libraries like Axios[1], SuperAgent (requires npm), and, yes, jQuery[2], that have really excellent API's (far superior to Fetch), or you could just write your own (or use an LLM) short wrapper around modern AJAX and call it a day. h/t to Claude: const xhr = ['GET','POST','PUT','PATCH','DELETE'].reduce((x,m) => (x[m.toLowerCase()] = (u,d,opt={}) => new Promise((r,j) => { const q = new XMLHttpRequest(); q.open(m,u); q.responseType = opt.responseType || ''; if(opt.headers) Object.entries(opt.headers).forEach(([k,v]) => q.setRequestHeader(k,v)); if(opt.signal) opt.signal.addEventListener('abort', () => q.abort()); q.withCredentials = opt.credentials === 'include'; q.onload = () => r({ ok: q.status >= 200 && q.status < 300, status: q.status, headers: new Headers(q.getAllResponseHeaders()), text: () => Promise.resolve(q.responseText), json: () => Promise.resolve(JSON.parse(q.responseText)), blob: () => Promise.resolve(new Blob([q.response])), response: q }); q.onerror = () => j(new TypeError('Network request failed')); q.send(d instanceof FormData ? d : JSON.stringify(d)); }), x), {}); This gives you xhr methods with a fetch-style API and you can still do all the things that fetch can't (but this won't do real streaming or cache control like Fetch, but it'll do 95% of all common use cases in a tiny bit of code.) Each method listed above returns a Promise that resolves with the XMLHttpRequest object or rejects with the error. So you get both the Promise functionality and full access to the XHR object in the resolution. Usage: xhr.post('/api', { data: 123 }, { headers: { 'Content-Type': 'application/json' }, credentials: 'include', signal: abortController.signal }) .then(res => res.json()) .then(data => console.log(data)); For more advanced AJAX stuff, check out the very powerful and flexible Axios library[1]. And, if you don't need AJAX but do want some of the features from jQuery (like some of the more unusual selectors) that aren't in Cash (to save bytes!), AJAX (and special effects) is excluded from jQuery Slim which brings the code down to only 69KB[3]. 1. Axios https://github.com/axios/axios https://github.com/axios/axios (41kb) 2. jQuery AJAX https://api.jquery.com/jQuery.ajax/ https://api.jquery.com/jQuery.ajax/ (87kb but includes ALL of jquery!) 3. https://code.jquery.com/jquery-3.7.1.slim.min.js https://code.jquery.com/jquery-3.7.1.slim.min.js
  - erik_seaberg 2y ago
    Caching is the most important reason to consider GET for a non-hypertext API. Vary headers tell the server which header diffs should cause cache misses, but there's no way to do that for an encoded body.
  - jdlshore 2y ago
    I believe providing a body with GET is non-standard, which could lead to problems with proxies. IETF is introducing the QUERY method to fill this gap.
    - _hyn3 2y ago
      It's not non-standard; it's actually in the standard: https://www.rfc-editor.org/rfc/rfc7231#page-24 https://www.rfc-editor.org/rfc/rfc7231#page-24 In standard HTTP/1.1, any method can have a request body. In Representational State Transfer (REST) as defined by Dr. Fielding, HTTP doesn't even come up, let alone "methods" per se, so there is no distinction between DELETE, POST, or GET from a REST standpoint, only within HTTP as an engine for hypertext. Further, in HTTP, any of these requests can contain a request body. But, because of this behavior by the WhatWG for Fetch, the IETF has added this paragraph to the specification for HTTP/1.1: "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." "Some existing implementations" really just means fetch. The p*ing contest between two groups resulted in a neutered and prescriptive fetch. In other words, it's fetch that is non-standard, and the actual HTTP standard had to be updated to let you know that.
      - chrismorgan 2y ago
        You've got the chronology and causality wrong. The Fetch API came after the RFC 7230 advice. Due to arguably dubious interpretation of arguably poor wording in RFC 2616 (from 1999) that suggested you SHOULD ignore GET bodies, various caching and proxy servers would ignore or reject GET request bodies, so that it became dangerous to use them. Since then, each iteration of the HTTP specs has strengthened the advice. The most recent 9110 family says you SHOULD NOT use GET request bodies unless you have confirmed in some way that they'll work, because otherwise you can't trust they'll work. Fetch was going along with this consensus, not causing the problem. The pool was muddied; nay, poisoned. And so the solution is the QUERY method. That's how things tend to work in such a space. See also 307 because of 302 being misimplemented.

Note that it's really dom centric and doesn't include ajax.

ceejayoz 2y ago

Isn’t AJAX fairly well supported via fetch now?

jitl 2y ago
Yeah at this point I’ve totally forgotten $.ajax API but fetch is pretty easy, just a single function call
- amelius 2y ago
  Now we only need something that makes websockets more resilient against network errors and corporate firewalls.
BiteCode_dev 2y ago
In the same way selectors and map replace jquery. It depends how much sugar you want.
_hyn3 2y ago
... unless you want to send a body with your HTTP GET. There is tons of utility value in this! For example, let's say you want to GET some data but also provide some client request statistics along with the request -- happens all the time in the real world. Fetch will reject your GET if it contains a body (a deliberate maintainer decision), even though it's entirely permissible by HTTP and done by many real-world AJAX APIs. Real AJAX will do what it's supposed to. (The HTTP 1.1 2014 Spec says that including a request body in a GET "might cause some implementations to reject the request." Guess which one!) Also, advanced features like progress are completely absent from Fetch as well. However, there are some fantastic libraries like Axios[1], SuperAgent (requires npm), and, yes, jQuery[2], that have really excellent API's (far superior to Fetch), or you could just write your own (or use an LLM) short wrapper around modern AJAX and call it a day. h/t to Claude: const xhr = ['GET','POST','PUT','PATCH','DELETE'].reduce((x,m) => (x[m.toLowerCase()] = (u,d,opt={}) => new Promise((r,j) => { const q = new XMLHttpRequest(); q.open(m,u); q.responseType = opt.responseType || ''; if(opt.headers) Object.entries(opt.headers).forEach(([k,v]) => q.setRequestHeader(k,v)); if(opt.signal) opt.signal.addEventListener('abort', () => q.abort()); q.withCredentials = opt.credentials === 'include'; q.onload = () => r({ ok: q.status >= 200 && q.status < 300, status: q.status, headers: new Headers(q.getAllResponseHeaders()), text: () => Promise.resolve(q.responseText), json: () => Promise.resolve(JSON.parse(q.responseText)), blob: () => Promise.resolve(new Blob([q.response])), response: q }); q.onerror = () => j(new TypeError('Network request failed')); q.send(d instanceof FormData ? d : JSON.stringify(d)); }), x), {}); This gives you xhr methods with a fetch-style API and you can still do all the things that fetch can't (but this won't do real streaming or cache control like Fetch, but it'll do 95% of all common use cases in a tiny bit of code.) Each method listed above returns a Promise that resolves with the XMLHttpRequest object or rejects with the error. So you get both the Promise functionality and full access to the XHR object in the resolution. Usage: xhr.post('/api', { data: 123 }, { headers: { 'Content-Type': 'application/json' }, credentials: 'include', signal: abortController.signal }) .then(res => res.json()) .then(data => console.log(data)); For more advanced AJAX stuff, check out the very powerful and flexible Axios library[1]. And, if you don't need AJAX but do want some of the features from jQuery (like some of the more unusual selectors) that aren't in Cash (to save bytes!), AJAX (and special effects) is excluded from jQuery Slim which brings the code down to only 69KB[3]. 1. Axios https://github.com/axios/axios https://github.com/axios/axios (41kb) 2. jQuery AJAX https://api.jquery.com/jQuery.ajax/ https://api.jquery.com/jQuery.ajax/ (87kb but includes ALL of jquery!) 3. https://code.jquery.com/jquery-3.7.1.slim.min.js https://code.jquery.com/jquery-3.7.1.slim.min.js
- erik_seaberg 2y ago
  Caching is the most important reason to consider GET for a non-hypertext API. Vary headers tell the server which header diffs should cause cache misses, but there's no way to do that for an encoded body.
- jdlshore 2y ago
  I believe providing a body with GET is non-standard, which could lead to problems with proxies. IETF is introducing the QUERY method to fill this gap.
  - _hyn3 2y ago
    It's not non-standard; it's actually in the standard: https://www.rfc-editor.org/rfc/rfc7231#page-24 https://www.rfc-editor.org/rfc/rfc7231#page-24 In standard HTTP/1.1, any method can have a request body. In Representational State Transfer (REST) as defined by Dr. Fielding, HTTP doesn't even come up, let alone "methods" per se, so there is no distinction between DELETE, POST, or GET from a REST standpoint, only within HTTP as an engine for hypertext. Further, in HTTP, any of these requests can contain a request body. But, because of this behavior by the WhatWG for Fetch, the IETF has added this paragraph to the specification for HTTP/1.1: "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." "Some existing implementations" really just means fetch. The p*ing contest between two groups resulted in a neutered and prescriptive fetch. In other words, it's fetch that is non-standard, and the actual HTTP standard had to be updated to let you know that.
    - chrismorgan 2y ago
      You've got the chronology and causality wrong. The Fetch API came after the RFC 7230 advice. Due to arguably dubious interpretation of arguably poor wording in RFC 2616 (from 1999) that suggested you SHOULD ignore GET bodies, various caching and proxy servers would ignore or reject GET request bodies, so that it became dangerous to use them. Since then, each iteration of the HTTP specs has strengthened the advice. The most recent 9110 family says you SHOULD NOT use GET request bodies unless you have confirmed in some way that they'll work, because otherwise you can't trust they'll work. Fetch was going along with this consensus, not causing the problem. The pool was muddied; nay, poisoned. And so the solution is the QUERY method. That's how things tend to work in such a space. See also 307 because of 302 being misimplemented.