On: Ditch React. Ditch Angular. Go Vanilla with Zam

[mark242]

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 → mark242]

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

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

[mark242 → zamjs]

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_ → mark242]

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 → _ZeD_]

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 → fleetfox]

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 → hateduser2]

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

[ec109685 → mark242]

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