Cea mai mare valoare individuală este timpul. Una din preocupările constante ale programatorului este aceea a gestionării timpilor de execuție printr-o succesiune eficientă a operațiunilor. Dincolo de aceste considerente abstracte, pentru moment, cel mai valoros lucru, atunci când scrii cod, este să poți întocmi o hartă mentală a execuției, care să jaloneze declarații, medii lexicale, apeluri și timpi de execuție. Această hartă este strâns legată de algoritmica programului, dar pe măsura complexității realizate, apar necunoscute care trebuie gestionate. Aceste necunoscute sunt legate de timpul necesar rezolvării anumitor evaluări care depind de alte resurse, unele aflate la distanță, iar altele poate necesitând computare. Vă mai aduceți aminte de faptul că o funcție are nevoie de valorile din mediul lexical sau obiectul context pentru a putea să-și execute codul din corp? Ce se întâmplă atunci când o resursă este la distanță sau în corpul funcției este apelată o alta care aparține unui API extern, așa cum sunt cele puse la dispoziție de browser. Cea mai prost scenariu ar implica blocarea firului de execuție al programului pentru a satisface toate condițiile necesare efectuării propriilor evaluări. Dar ce-ar fi dacă am proceda la trimiterea în fundal (runtime-ul de execuție) a acestor operațiuni care necesită timp și/sau efort pentru a fi soluționate. O astfel de funcție, ar ieși de pe scenă precum un actor care promite să revină după ce va lua din culise recuzita necesară. Publicul va rămâne în așteptare urmărind jocul celorlalți actori rămași.
Această operațiune de anticipare a unor rezultate în anumite cazuri este în strânsă legătură cu momentul în care se execută o anumită operațiune. Uneori, când soliciți niște date dintr-o sursă locală sau la distanță, serviciul responsabil poate să nu funcționeze. Sau datele să nu se fi generat dintr-o altă operațiune de prelucrare. În acest caz, vorbim de aspectele asincrone ale rulării codului. Toate aceste necunoscute, mici sincope, lucruri care nu pot fi stăpânite printr-o gândire pur algoritmică, au nevoie să fie gestionate cumva. Pot fi asemuite previziunii meteorologice prin care se încearcă anticiparea vremii. Cum în cazul programării este nevoie de un rezultat concret, aceste aprecieri ale posibilității obținerii sau nu a unui rezultat, poartă numele de promisiuni. O promisiune este o valoare care poate fi disponibilă acum, în viitor sau niciodată. Ceea ce se promite este faptul că vei primi un răspuns, fie acesta unul pozitiv, fie unul negativ.
Mulți practicieni apelează la comparația promisiunilor cu IOU -urile. Un IOU este o sintagmă în limba engleză: I owe you (îți sunt dator am traduce în română), care reglementează o realitate tranzacțională asemănătoare unor chitanțe sau AWB în cazul efectelor poștale. AWB-ul este un jeton pe care îl primești în urma achitării unui produs care urmează să-ți fie livrat. Produsul poate să-ți fie livrat după o perioadă (înregistrăm un succes) sau poți primi o explicație pentru problemele apărute la livrare (înregistrăm o eroare) însoțită de o posibilă rezolvare pentru problema apărută. În cazul AWB-urilor, poți urmări comanda și pentru o vreme vei vedea mesajul în curs de livrare - în engleză ar fi pending.
JavaScript folosește un singur fir de execuție, bazându-se pe evenimente, cu mențiunea că respectă un model ce nu blochează input-urile și output-urile. Fiecare browser va rula API-urile în fire de execuție separate, dar un program JavaScript va avea mereu un singur fir de execuție. Mai există un termen care trebuie lămurit pentru că ne vom lovi de el adesea: concurrency, care s-ar traduce în limba română concurență, dar în contextul acestui limbaj de programare cu nuanța de concomitent. Kyle Simpson spune despre acest fenomen că două operațiuni în JavaScript se pot desfășura în aceeași fereastră de timp, dar asta nu înseamnă că se întâmplă în paralel. În JavaScript nimic nu se petrece în paralel pentru că avem un singur fir de execuție. La ce se reduce acest lucru? La prioritizarea execuției diverselor părți ale codului. Reiterăm faptul că JavaScript are un singur fir de execuție, care implică o anumită secvențialitate. Ce te faci când în lucrul curent, cu evenimente, multiple funcții pot să-și înceapă evaluarea, dar unele au nevoie de valorile returnate de altele ș.a.m.d. În acest mediu înalt concurențial, avem cele două mecanisme care reglează controlul programului: stiva apelărilor și bucla evenimentelor. Pentru a negocia acest mediu concurențial, s-a introdus paradigma de lucru asincron.
Pentru a rezolva mai elegant problema asincronicității dincolo de ceea ce pot oferi callback-urile, ES6 a introdus oficial conceptul de promises (promisiuni) în standard.
Standardul spune:
O promisiune este un obiect care este folosit ca locțiitor pentru rezultatele care ar putea apărea în urma unei computații întârziate (posibil asincronă).().
Moment ZEN: O promisiune este un obiect care împachetează o operațiune asincronă cu specificația că va returna un rezultat sau o eroare la un moment viitor.