Celem mechanizmu obietnic (ang. promises) w języku JavaScript jest
Mechanizm obietnic (promises) w JavaScript to, moim zdaniem, jedno z najważniejszych udogodnień, które pojawiły się w języku, żeby ogarnąć cały ten chaos wokół asynchroniczności. Typowa sytuacja kiedyś wyglądała tak, że w kodzie robiło się „callback hell” – zagnieżdżone funkcje wywołujące się nawzajem, co mocno utrudniało życie. Promise pozwala na o wiele czytelniejsze i wygodniejsze zarządzanie operacjami, które kończą się „kiedyś”, np. pobieraniem danych z API, zapisem do pliku, czy czekaniem na odpowiedź użytkownika. Z mojego doświadczenia wynika, że dzięki promises jest dużo łatwiej obsłużyć zarówno sukces, jak i błędy – możesz skorzystać z then(), catch(), a nawet łańcuchować kilka asynchronicznych zadań bez gubienia się w kodzie. Szczególnie przydatne jest to w pracy z fetch(), gdzie bez promises cała obsługa sieci wyglądałaby strasznie topornie. Dodatkowo promises są w pełni zgodne ze standardem ECMAScript 2015 (ES6) i stanowią podstawę dla nowocześniejszych rozwiązań, takich jak async/await. Praktycznie każdy zawodowy frontendowiec czy backendowiec pracujący z Node.js powinien je znać, bo to już nie fanaberia, a codzienność. Dobra praktyka to właśnie korzystanie z promises tam, gdzie tylko mamy do czynienia z nieblokującymi operacjami. Takie podejście nie tylko poprawia czytelność kodu, ale znacząco ułatwia jego utrzymanie i debugowanie.
Często można się pogubić, czym dokładnie są promises w JavaScript, zwłaszcza jeśli ktoś kojarzy je luźno z innymi mechanizmami programowania obiektowego czy obsługą błędów. Promises mają swoje korzenie w potrzebie efektywnego zarządzania asynchronicznością, czyli wykonywaniem operacji, które nie kończą się od razu, na przykład pobieraniem danych z sieci czy operacjami wejścia-wyjścia. To, że promises jakoś „ulepszają czytelność kodu synchronicznego”, jest trochę nadinterpretacją – bo one nie poprawiają kodu synchronicznego, tylko asynchroniczny czynią bardziej czytelnym. Dziedziczenie w programowaniu obiektowym, zarówno prototypowe, jak i klasyczne, to zupełnie inna para kaloszy – promises nie mają nic wspólnego z zastępowaniem tych mechanizmów, bo ich zadaniem nie jest kształtowanie struktury obiektów, a raczej kontrolowanie przepływu kodu w czasie. Zarządzanie przechwytywaniem błędów też nie jest głównym celem promises – choć rzeczywiście pozwalają na łatwiejszą obsługę błędów w kodzie asynchronicznym poprzez catch(), to jednak nie są uniwersalnym systemem zarządzania wyjątkami. Typowym błędem myślowym jest też mylenie promises z callbackami lub myślenie, że rozwiązują one wszystkie problemy związane z błędami – a to nie do końca prawda, bo promise jedynie porządkuje asynchroniczność i pozwala na prostsze reakcji na sukcesy i porażki asynchronicznych operacji. W praktyce promises to nie magiczna broń na wszystko, tylko bardzo sprytne narzędzie do ogarnięcia operacji nieblokujących w sposób czytelny, przewidywalny i zgodny ze współczesnymi standardami branżowymi.