3 ms·

Genuine question: in 2017, why would you create a JS framework that didn't use futures? eg in the documentation, ".fadeIn(selector, time)" - "Returns nothing".

Genuine question: in 2017, why would you create a JS framework that didn't use futures? eg in the documentation, ".fadeIn(selector, time)" - "Returns nothing". Why not return a future that resolves when the fade completes?

zamjs 9y ago
From a performance stand point -- does it really matter? You are right. fadeIn and fadeOut should have some optional callback for completion.
- mark242 9y ago
  Yes, it absolutely does matter. Chaining promises together, running them in parallel with Promise.all, and the abortable-promise pattern, make developing (and especially debugging!) much much easier than having to deal with callback hell. zam.fadeIn(el, duration) .then(zam.ajax(url)) .then(response => response.json()) .then(json => el.innerHTML = json.results[2].message) This code is nearly self-documenting, is easier for a transpiler to handle, and doesn't scream "refactor me!" right after you've deployed your app.
  - _ZeD_ 9y ago
    I saw this "then-heavy" style in many places, but I never really understood: I find perfectly fine to make "fadeIn" return a promise, or an ajax call, and find "the right way" to join them with then / when / Promise.all etc. But what is the meaning to add a lambda function as "response => response.json()" in a then? why a different lambda "json => el.innerHTML = json.results[2].message" ? isn't it a "gratuitous" use of a then-able object? I found more readable to have a (sincronous, debuggable, "old-style") function without the need to split in one thousand one line lambdas. moreover, my python background makes me looks as "ugly" the last one, as it's a lambda function with an assignement, and not a simple expression.
    - fleetfox 9y ago
      Not sure what you mean but response.json() is promise that can fail with parse/read error. It's where error handling should happen making it imperative doesn't solve anything
      - hateduser2 9y ago
        I don’t know why you assert that that’s where error handling should happen because I disagree. My thought was that promises were for values that are calculated asynchronously or anyways aren’t immediately available. They support errors but I don’t think this means that all code which emits errors should use promises to do error handling, that seems like a bastardization of the original idea.
        fleetfox 9y ago
        It is calculated asynchronously. Response body is lazy and calling .json() on it consumes it and returns promise. That is API of WHATWG fetch and many other JS HTTP clients https://fetch.spec.whatwg.org/#body-mixin https://fetch.spec.whatwg.org/#body-mixin
  - ec109685 9y ago
    Wouldn’t you want the fadeIn to be parallel to the Ajax fetch?
joshua4 9y ago
They are called Promises. Stop trying to use different words to sound smart

zamjs 9y ago

From a performance stand point -- does it really matter? You are right. fadeIn and fadeOut should have some optional callback for completion.

mark242 9y ago
Yes, it absolutely does matter. Chaining promises together, running them in parallel with Promise.all, and the abortable-promise pattern, make developing (and especially debugging!) much much easier than having to deal with callback hell. zam.fadeIn(el, duration) .then(zam.ajax(url)) .then(response => response.json()) .then(json => el.innerHTML = json.results[2].message) This code is nearly self-documenting, is easier for a transpiler to handle, and doesn't scream "refactor me!" right after you've deployed your app.
- _ZeD_ 9y ago
  I saw this "then-heavy" style in many places, but I never really understood: I find perfectly fine to make "fadeIn" return a promise, or an ajax call, and find "the right way" to join them with then / when / Promise.all etc. But what is the meaning to add a lambda function as "response => response.json()" in a then? why a different lambda "json => el.innerHTML = json.results[2].message" ? isn't it a "gratuitous" use of a then-able object? I found more readable to have a (sincronous, debuggable, "old-style") function without the need to split in one thousand one line lambdas. moreover, my python background makes me looks as "ugly" the last one, as it's a lambda function with an assignement, and not a simple expression.
  - fleetfox 9y ago
    Not sure what you mean but response.json() is promise that can fail with parse/read error. It's where error handling should happen making it imperative doesn't solve anything
    - hateduser2 9y ago
      I don’t know why you assert that that’s where error handling should happen because I disagree. My thought was that promises were for values that are calculated asynchronously or anyways aren’t immediately available. They support errors but I don’t think this means that all code which emits errors should use promises to do error handling, that seems like a bastardization of the original idea.
      - fleetfox 9y ago
        It is calculated asynchronously. Response body is lazy and calling .json() on it consumes it and returns promise. That is API of WHATWG fetch and many other JS HTTP clients https://fetch.spec.whatwg.org/#body-mixin https://fetch.spec.whatwg.org/#body-mixin
- ec109685 9y ago
  Wouldn’t you want the fadeIn to be parallel to the Ajax fetch?

joshua4 9y ago

They are called Promises. Stop trying to use different words to sound smart