Hacker News Reader

Comment by dpcan | Hacker News Reader

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.

View on HN

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.

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)

    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.

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.

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.

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.

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…

You don't need to check readyState; onload is only called when the readyState switches to 4.

At least fetch is a viable replacement for jQuery.ajax and the syntax is quite similar.

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.

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.

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).

Reply on news.ycombinator.com