[domenicd]

I agree this page hasn't aged well, but that's because it's stuck on IE10 as the support level it's targeting. If you don't need to target IE at all (only Edge), then everything becomes simpler. That's not always safe, but that's why you might not need jQuery...

For reference:

  // JSON
  const data = await (await fetch('/my-url')).json();

  // Post
  await fetch('/my-url', { method: 'POST', body: data });

  // Request
  try {
    const resp = await fetch('/my-url');
    // ...
  } catch (e) {
    // ...
  }

  // Fade In
  el.animate({ opacity: 1 }, 400);

  // Fade Out
  el.animate({ opacity: 0 }, 400);

  // Hide
  el.hidden = true;

  // Show
  el.hidden = false;

  // After
  target.after(el);

  // Append
  target.append(el);

  // Before
  target.before(el);

  // Each
  for (const el of document.querySelectorAll(selector)) {
    // ...
  }

  // Empty
  el.replaceChildren(); // or el.textContent = '', depending on which you find clearer

  // Filter
  [...document.querySelectorAll(selector)].filter(filterFn);

  // Get Height
  el.clientHeight;

  // Get Width
  el.clientWidth;

  // Matches
  el.matches('.my-class');

  // Remove
  el.remove();

  // Delegate
  document.addEventListener(eventName, e => {
    const match = e.target.closest(elementSelector);
    if (match) {
      handler.call(match, e);
    }
  });

  // Trigger Custom
  el.dispatchEvent(new CustomEvent('my-event', { detail: { some: 'data' } }));

  // Trigger Native
  el.dispatchEvent(new Event('change'));

  // Extend
  Object.assign({}, objA, objB);

  // Parse HTML
  (new DOMParser()).parseFromString(htmlString);

  // Type
  obj[Symbol.toStringTag];

[inbx0]

Your fetch examples don't reject the promise if the server responds with error status code, like 404, which is probably not what you'd want. You'd need to handle that separately with something like

    const resp = await fetch('/my-url')
    if (!resp.ok) throw new Error(await resp.text())
    const data = await resp.json()

From MDN (https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API):

> The Promise returned from fetch() won’t reject on HTTP error status even if the response is an HTTP 404 or 500. Instead, it will resolve normally (with ok status set to false), and it will only reject on network failure or if anything prevented the request from completing.

[Wintamute]

I know this pattern and have used it myself. The problem is though, that generally you should only throw an error when you reach an exception - it's like saying "I don't know what to do next", and you defer that decision up the stack.

Is a request that technically succeeds (the response has come back), but has a status code where the server has indicated something didn't work always an _exception_ in your client code? I'd argue it isn't, and should just be handled in the normal control flow of your client code via conditionals.

[unilynx]

The answer probably depends a lot on what you're used to from other languages.

Java users might want to make 404 an exception (FileNotFoundException), C++ users probably wouldn't throw an exception for that

[jamiesonbecker]

Nice, thanks for this!

[mdtrooper]

Really thanks, but Android Chromium has support "fetch" too late (2020). Well, I can wait.

[simon04]

You can use a polyfill such as https://github.com/developit/unfetch (500 bytes).

[GlitchMr]

You can use a polyfill such as https://github.com/github/fetch.