Hacker News Reader

Comment by mark242 | Hacker News Reader

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?

View on HN

From a performance stand point -- does it really matter?

You are right. fadeIn and fadeOut should have some optional callback for completion.

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.

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.

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

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.

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

Wouldn’t you want the fadeIn to be parallel to the Ajax fetch?

Reply on news.ycombinator.com