4 ms·

It’s only simpler because you know how to use it. For most use cases fetch and async/await is just easier.

by lakpan 3y ago

dylan604 3y ago
I mean, duh? Of course doing something that I've done for a long time is going to be more simple to me than me fumbling/stumbling through something I haven't done much. What new insight are you providing me here?
- umvi 3y ago
  Async await fetch lets you flatten your nested callback functions into simple procedural programming. It makes everything much easier to reason about, no more closures and such.
  - dylan604 3y ago
    see, this is where i'm not cool with this newness. i've spent years getting away from procedural, and switching to functions, classes/methods. now, we want to get away from that and go back to procedural? that's all fine and dandy, but you're trying to have a new trick conversation with an old dog that just doesn't care. you're bringing some sort of logic to a conversation where it's not needed. it works for me. i don't get paid to make UI apps or write heavy code nonsense with server side JS. i use a proper back end language. JS can stay in the browser and manipulate the DOM thank you very much. i get paid to make heavy processing code that sometimes is helpful to have UI dashboards. i can whip up a JQuery front end faster for my needs than most can even figure out what NPM librar[y|ies] they need to use
    - boredtofears 3y ago
      surely you still use procedural code within your functions and classes. the point of await/async is you break down the callback nesting into a single set of procedural code. it doesn't mean all your code is procedural. just that what used to have to be a series of indented anonymous functions or spread all over the place named functions can now be an easy to read concise few lines of code all at the same indentation in a single spot. its an obvious net-win for readability and code maintainability. you are doing yourself no favors by not understanding/embracing it.
      - deleted 3y ago
        [deleted]
    - marcosdumay 3y ago
      > now, we want to get away from that and go back to procedural? AFAIK, we are all still programming browser UI with Javascript. It is an imperative language, about as stateful as you can get. Now, if you managed to do your frontends with Haskell or Prolog, I'd be interested on learning how.
      - zdkl 3y ago
        LISP in the browser! You end up having to ship a large runtime with your app but it all transpiles to vanilla JS. https://clojurescript.org/ https://clojurescript.org/
  - deleted 3y ago
    [deleted]
  - peebeebee 3y ago
    JQUERY: await $.post({ url: '/my/url', data: data }).then(() => {}); VANILLA: await fetch('/my/url', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(data) }).then(() => {}); I know which one I still prefer.
    - hoten 3y ago
      You don't need that then in the fetch example. I don't know about ajax.
    - lakpan 3y ago
      You dropped about 250000 characters from the first example. Of course if you load a bunch of code beforehand your code will be marginally better. The fact is that you probably don’t need to send JSON anymore because fetch accepts the whole form as an object: await fetch('/my/url', { method: 'POST', body: new FormData(form) })
      - peebeebee 3y ago
        > Of course if you load a bunch of code beforehand your code will be marginally better. That's exactly the point though. We use jQuery because it has an incredible easy and consistent interface that makes writing for the web so much more enjoyable. Selectors, events, chaining,... are all just nicer to work with than the vanilla counterparts. Same goes for all libraries and frameworks. :) BTW: Your example is sending a "multipart/form-data". Not all API's will understand this, and will need JSON anyway.
        lakpan 3y ago
        > Not all API's will understand this Who’s talking about APIs? Most jQuery users I know just use jQuery to submit forms and load some JSON, both of which are covered by fetch without altering the headers manually. What I’m saying is that it’s not fair to judge a tool for something you don’t have to do with it, namely sending JSON for everything. Fetch also supports native binary uploads, whereas most people base64 data when using $.ajax > makes writing for the web so much more enjoyable Writing? I agree. Actually making it work? No way. $('forn').hide() doesn’t work, but the browser will never tell you why (hint: wrong selector). jQuery errors are often silent, and that’s good enough reason to abandon it.

It’s only simpler because you know how to use it. For most use cases fetch and async/await is just easier.

by lakpan 3y ago

It’s only simpler because you know how to use it. For most use cases fetch and async/await is just easier.

I mean, duh? Of course doing something that I've done for a long time is going to be more simple to me than me fumbling/stumbling through something I haven't done much. What new insight are you providing me here?

umvi 3y ago
Async await fetch lets you flatten your nested callback functions into simple procedural programming. It makes everything much easier to reason about, no more closures and such.
- dylan604 3y ago
  see, this is where i'm not cool with this newness. i've spent years getting away from procedural, and switching to functions, classes/methods. now, we want to get away from that and go back to procedural? that's all fine and dandy, but you're trying to have a new trick conversation with an old dog that just doesn't care. you're bringing some sort of logic to a conversation where it's not needed. it works for me. i don't get paid to make UI apps or write heavy code nonsense with server side JS. i use a proper back end language. JS can stay in the browser and manipulate the DOM thank you very much. i get paid to make heavy processing code that sometimes is helpful to have UI dashboards. i can whip up a JQuery front end faster for my needs than most can even figure out what NPM librar[y|ies] they need to use
  - boredtofears 3y ago
    surely you still use procedural code within your functions and classes. the point of await/async is you break down the callback nesting into a single set of procedural code. it doesn't mean all your code is procedural. just that what used to have to be a series of indented anonymous functions or spread all over the place named functions can now be an easy to read concise few lines of code all at the same indentation in a single spot. its an obvious net-win for readability and code maintainability. you are doing yourself no favors by not understanding/embracing it.
    - deleted 3y ago
      [deleted]
  - marcosdumay 3y ago
    > now, we want to get away from that and go back to procedural? AFAIK, we are all still programming browser UI with Javascript. It is an imperative language, about as stateful as you can get. Now, if you managed to do your frontends with Haskell or Prolog, I'd be interested on learning how.
    - zdkl 3y ago
      LISP in the browser! You end up having to ship a large runtime with your app but it all transpiles to vanilla JS. https://clojurescript.org/ https://clojurescript.org/
- deleted 3y ago
  [deleted]
- peebeebee 3y ago
  JQUERY: await $.post({ url: '/my/url', data: data }).then(() => {}); VANILLA: await fetch('/my/url', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(data) }).then(() => {}); I know which one I still prefer.
  - hoten 3y ago
    You don't need that then in the fetch example. I don't know about ajax.
  - lakpan 3y ago
    You dropped about 250000 characters from the first example. Of course if you load a bunch of code beforehand your code will be marginally better. The fact is that you probably don’t need to send JSON anymore because fetch accepts the whole form as an object: await fetch('/my/url', { method: 'POST', body: new FormData(form) })
    - peebeebee 3y ago
      > Of course if you load a bunch of code beforehand your code will be marginally better. That's exactly the point though. We use jQuery because it has an incredible easy and consistent interface that makes writing for the web so much more enjoyable. Selectors, events, chaining,... are all just nicer to work with than the vanilla counterparts. Same goes for all libraries and frameworks. :) BTW: Your example is sending a "multipart/form-data". Not all API's will understand this, and will need JSON anyway.
      - lakpan 3y ago
        > Not all API's will understand this Who’s talking about APIs? Most jQuery users I know just use jQuery to submit forms and load some JSON, both of which are covered by fetch without altering the headers manually. What I’m saying is that it’s not fair to judge a tool for something you don’t have to do with it, namely sending JSON for everything. Fetch also supports native binary uploads, whereas most people base64 data when using $.ajax > makes writing for the web so much more enjoyable Writing? I agree. Actually making it work? No way. $('forn').hide() doesn’t work, but the browser will never tell you why (hint: wrong selector). jQuery errors are often silent, and that’s good enough reason to abandon it.