5 ms·

Who decides what is “cleaner” and “simpler”? It’s such a strange take in the coding world. I don’t know why other developers get to decide what is clean, simpl

by dpcan 4y ago

Who decides what is “cleaner” and “simpler”? It’s such a strange take in the coding world. I don’t know why other developers get to decide what is clean, simple, easier to understand, etc, when it comes to my code or the way I write code. I’ve been using xmlhttprequest for YEARS and honestly, it’s pretty dang simple. It’s pretty darn clean. And when we see it, we know what it’s doing and how it works. I’m not sure of the motivation behind changes and new API’s like this that keep trying to fix what really isn’t broken for most uses.

melolife 4y ago
Ignoring the fact that XMLHttpRequest is a hideously unlovely API, it's a huge problem when your primary asynchronous abstraction is not implemented by your primary API for async IO.
- iostream24 4y ago
  That’s an opinion, not a fact, re: hideous etc. Please explain the latter bit again. I too see no need to switch suddenly to this fetch api when older browser support is important to my daily driver web app. I found the tone of this article condescending when browser apis have mega committee-ware battlescars all over them and likely implement both of xyz with the same call to epoll anyway, (joke about systems programming)
ARandomerDude 4y ago
if (xhr.readyState !== 4) return; is gross and stateful. Certainly you can learn it and use it but .then((res) => res.json()) is much more declarative.
- mmis1000 4y ago
  And if you forgot to call xhr.send() at the end. You screw up and your callback is never called. fetch doesn't even allow you to make this kind of mistakes.
  - Beltalowda 4y ago
    It allows you take make other mistakes, such as using the wrong type for POST data resulting in "[object Object]" and similar gibberish being sent to the server. Not saying XMLHttpRequest API's is brilliant, but fetch's API also doesn't exactly fill me with joy.
    - ARandomerDude 4y ago
      I think the key is the comparative "-er" in "cleaner" and "simpler." Fetch may not be the cleanest or simplest possible solution, but in my opinion it is cleaner and simpler. XMLHttpRequest is good. Fetch is better.
  - iostream24 4y ago
    And I have the entirety of an XMLHttpRequest in my head anyway, that xhr.send(fd); is where you included your form data… These strange notions of burden and beauty…
- Jasper_ 4y ago
  You don't need to check readyState; onload is only called when the readyState switches to 4.
- petre 4y ago
  At least fetch is a viable replacement for jQuery.ajax and the syntax is quite similar.
karmakaze 4y ago
I had a web app that was making perhaps an unreasonable number of concurrent requests. Every now and then, pretty regularly like 1 in every 20 full page reloads it would fail somewhere along the line. I switched from the lib I was using to XMLHttpRequest directly and it worked reliably with little in the way of cluttering the code as I made my own minimal wrapper without the features I didn't need from the lib. That was quite a long time ago and the lib has likely had whatever the problem was resolved.
gwbas1c 4y ago
Generally if you can write your code in a way that uses scopes and returned values, it's cleaner and easier to maintain. IE, this is why async / await was added to JavaScript: The code is significantly easier to read (cleaner) than promises.
phendrenad2 4y ago
I like that people are trying to show you examples of fetch vs xhr as though you haven't seen them. "If you just look at them, you'll clearly transform yourself to have the same aesthetic preferences I do!" They're all missing the point, frankly. The point is, we're stuck in this vicious cycle where we all get selective amnesia and forget why someone was invented, and we decide that it's old/ugly/unergonomic/ungraceful/unclean/unsimple/etc./etc. and invent something new. Woe to them that love the fetch API, and fall into a time warp to 2005 when everyone was singing the praises of "AJAX". You'd be bowled over by the sheer culture shock. (Likewise, I can't wait for 2035, when we'll have invented some emoji-based way to represent fetches, and those still using fetch() or axios() will be seen as hipsters/clueless).

by dpcan 4y ago

melolife 4y ago

Ignoring the fact that XMLHttpRequest is a hideously unlovely API, it's a huge problem when your primary asynchronous abstraction is not implemented by your primary API for async IO.

iostream24 4y ago
That’s an opinion, not a fact, re: hideous etc. Please explain the latter bit again. I too see no need to switch suddenly to this fetch api when older browser support is important to my daily driver web app. I found the tone of this article condescending when browser apis have mega committee-ware battlescars all over them and likely implement both of xyz with the same call to epoll anyway, (joke about systems programming)

ARandomerDude 4y ago

if (xhr.readyState !== 4) return; is gross and stateful. Certainly you can learn it and use it but .then((res) => res.json()) is much more declarative.

mmis1000 4y ago
And if you forgot to call xhr.send() at the end. You screw up and your callback is never called. fetch doesn't even allow you to make this kind of mistakes.
- Beltalowda 4y ago
  It allows you take make other mistakes, such as using the wrong type for POST data resulting in "[object Object]" and similar gibberish being sent to the server. Not saying XMLHttpRequest API's is brilliant, but fetch's API also doesn't exactly fill me with joy.
  - ARandomerDude 4y ago
    I think the key is the comparative "-er" in "cleaner" and "simpler." Fetch may not be the cleanest or simplest possible solution, but in my opinion it is cleaner and simpler. XMLHttpRequest is good. Fetch is better.
- iostream24 4y ago
  And I have the entirety of an XMLHttpRequest in my head anyway, that xhr.send(fd); is where you included your form data… These strange notions of burden and beauty…
Jasper_ 4y ago
You don't need to check readyState; onload is only called when the readyState switches to 4.
petre 4y ago
At least fetch is a viable replacement for jQuery.ajax and the syntax is quite similar.

karmakaze 4y ago

I had a web app that was making perhaps an unreasonable number of concurrent requests. Every now and then, pretty regularly like 1 in every 20 full page reloads it would fail somewhere along the line. I switched from the lib I was using to XMLHttpRequest directly and it worked reliably with little in the way of cluttering the code as I made my own minimal wrapper without the features I didn't need from the lib. That was quite a long time ago and the lib has likely had whatever the problem was resolved.

gwbas1c 4y ago

Generally if you can write your code in a way that uses scopes and returned values, it's cleaner and easier to maintain. IE, this is why async / await was added to JavaScript: The code is significantly easier to read (cleaner) than promises.

phendrenad2 4y ago

I like that people are trying to show you examples of fetch vs xhr as though you haven't seen them. "If you just look at them, you'll clearly transform yourself to have the same aesthetic preferences I do!" They're all missing the point, frankly. The point is, we're stuck in this vicious cycle where we all get selective amnesia and forget why someone was invented, and we decide that it's old/ugly/unergonomic/ungraceful/unclean/unsimple/etc./etc. and invent something new. Woe to them that love the fetch API, and fall into a time warp to 2005 when everyone was singing the praises of "AJAX". You'd be bowled over by the sheer culture shock. (Likewise, I can't wait for 2035, when we'll have invented some emoji-based way to represent fetches, and those still using fetch() or axios() will be seen as hipsters/clueless).