Sarebbe un vantaggio scrivere codice sincrono usando la sintassi delle promesse

Assolutamente! Per diversi motivi:

• Le promesse forniscono un eccellente sistema di controllo degli errori. Puoi restituire una promessa e lasciare che il chiamante faccia la promessa, tuttavia lui o lei lo desidera (o per niente).
• Molti sostengono che le promesse rendono il tuo codice più pulito e più facile da leggere, il che non è poco. Direi che valgono le promesse se non altro per il fatto che è elegante.
• Ultimo, ma certamente non meno importante, l'implementazione ora è sincrona, ma se dovesse mai cambiare, non è necessario modificare una grande sezione di codice per rendere il lavoro sincrono in modo asincrono, ma solo l'effettiva implementazione.

Ora, per favore non fraintendermi, non penso che dovresti usare le promesse per ogni cosa che fai nel programma, anche se per qualcosa che è anche lievemente intensivo o complicato della CPU, vorrei prendere l'abitudine di usare le promesse per implementare queste operazioni.

Lo svantaggio principale è che le promesse non sono pienamente supportate nei browser più vecchi, quindi se decidi di seguire questa strada, prendi in considerazione l'utilizzo di una libreria di polyfill come bluebird o q per farlo funzionare sia nei browser più recenti che nei browser meno recenti.

Spero che ti aiuti!

Sì e no. Il tuo codice fallirà.

.then(bar.bind(a, b))

Dovresti usare

.then(function() {bar.bind(a,b);})

.. a meno che foo () non risolva () restituisca gli argomenti a, b nel qual caso useresti ..

.then(bar.bind)

In ogni caso, il vero vantaggio di scrivere quel codice in quel modo è che in realtà non è un codice sincrono. È sequenziale, ma non sincrono. È asincrono. L'invocazione foo() potrebbe richiamare qualche attività del file system che richiede un po 'di tempo, se è in esecuzione su node.js / io.js, oppure potrebbe eseguire un background worker in un thread separato se è in esecuzione su un browser moderno, e in entrambi i casi la promessa non resolve() e il prossimo then() non verrebbe eseguito fino al completamento di tale attività, ma nel frattempo il thread principale di Javascript è ancora in esecuzione e sta elaborando altri eventi.

Il lato negativo è che devi avere una strategia promettente e lavorare con esso. Dove Neil ha detto che dovresti usare un polyfill, il che è vero in quanto ECMAScript 6 non è generalmente adottato ancora, anche se dovevi ancora lavorare con la sua strategia di promessa. Quindi la tua maggiore preoccupazione è che foo() e bar() e bam() devono restituire promesse. Queste promesse devono essere oggetti che intercettano resolve() o reject() e li passino a .then() o .done() ea .fail() , e devono concatenare per .fail() . (C'è molto altro da promettere, dovrai fare ulteriori ricerche su questo se fai il tuo.) I framework di promessa esistenti, incluso anche il $.Deferred di jQuery, sono piuttosto eleganti, ma il punto è che stai aggiungendo più lavoro al tuo codice.

Quindi, proprio come Neil ha detto che dovresti scrivere il tuo codice solo nel modo sintattico delle promesse quando senti che stai invocando in sequenza metodi che dovrebbero essere attività a lungo termine. Tuttavia, YAGNI; non farlo se pensi che potrebbero essere compiti a lungo termine in futuro, fallo solo se sai che ora sono compiti a lungo termine. Non ottimizzare in anticipo fino a quando non avrai identificato un collo di bottiglia. Ma devi anche considerare il costo delle promesse. Non scrivere codice asincrono se non puoi gestire il supporto della strategia promessa.